Why Most I/T Projects Get Off Track
Apart from whether your project is managed by internal I/T staff or outside consultants,
several factors are common to why many I/T projects get off track, or fail completely.
In our experience, the reasons why we are most
frequently called upon to “takeover”
a project include: the wrong people, the wrong process,
unrealistic expectations, or an overly ambitious project scope. Take your pick: any one of
these factors can derail the best of intentions, and leave your project by the side of the road in
Betting On the Wrong Horse (People)
This is probably the most important factor that influences the quality of a custom
development initiative. Who you engage to lead and manage your project is the most risky decision you will make. It can be very difficult to know whether you are 'on the right horse' until you are half way thru
the race, and anyone will tell you that it is hard to switch horses in the middle of a race!
To the lay business person, most programmers appear to be very knowledgeable, and problems only
become apparent (i.e. obvious to anyone) after considerable time and money is invested.
Many freelance software consultants do not have the business savvy necessary to
challenge ill-informed assumptions, or the real-world project management rigor to
drive critical business decisions and keep projects focused and on track. And because
many developers tend to recommend only what they know, it is hit or miss on very
important platform and design decisions that are made early in the project. Getting
platform and design decisions wrong is like flying to the moon with the rocket off
just 1 degree at takeoff — be prepared for very lonely journey and no spot to land.
Over reliance on internal I/T personnel is also a common cause of project failure.
While most I/T professionals are skilled in properly maintaining desktop applications,
keeping networks running smoothly, maintaining back-ups of critical data, etc. these
common I/T responsibilities and priorities are frequently at odds with line-of-business
needs and priorities. Network security is a great example: I/T is motivated to keep
the boat securely tethered to the dock, since nothing bad can happen if the boat
stays in port. Business personnel on the other hand are highly motivated to sail
the boat, since that’s their job! As a result, conflict and tension between I/T
staff and business professionals is quite common.
In addition, less tech-savvy business professionals can often confuse I/T networking,
security and DBA skill sets with the custom development skills and business acumen
necessary to drive solutions to complex business needs. Network I/T staff and professional
application design engineers are completely different skill sets... don't
confuse the two!
Lastly, it is also not uncommon for centralized I/T departments to have a stranglehold
on the I/T budget allocation — a situation that can completely stifle line-of-business
needs and priorities. Empowering an I/T organization with control over business
application budget decisions is akin to letting Washington DC decide how you should
spend your local Town’s tax receipts. Let line-of-business managers compete for
I/T dollars… and leave the all-too-important decisions on business priority and
budget allocation to the executive team.
Riding on the Wrong Track (Process)
Static requirements often kill projects. The practice (and the art!) of custom application
development is much more similar to a horse race thru the woods with no clearly
marked track — where the best
informed decisions are made in the moment and in the
full context of a focused business discussion — not the result of a pre-defined course. This is “big idea” behind the Agile Development Methodology which is rapidly
supplanting more static software development practices. In our experience,
the best ideas can be (and often are) unforeseeable at the outset
of a project, and thus the best results are often achieved thru an agile process, not a rigid plan.
words vs. pictures is also a common recipe for failure. Request for Proposals (RFPs) and "detailed project specification" documents,
while sometimes helpful in defining high-level project success criteria, are notorious at failing to
define what ends up mattering the most once a project is complete: What is the application going to look like? Is the application intuitive and easy-to-use? How are the all the individual
functions going to tie together within a cohesive workflow? Answers to these critical
questions can only be addressed by a highly-visual prototype
to drive discussion and consensus. Absence of visual prototype only serves to defer the best answers to late in the development
process – when fundamental changes to the application flow and functionality are the most expensive!
Unrealistic Expectations (Mindset)
It is human nature to want to look at things optimistically. When it comes to custom application projects however, you can rarely go wrong with a healthy dose of skepticism!
Our advice: get 2 or 3 estimates from different developers, average them, and then ask yourself: "If this project cost
me half again as much, took half again as long to complete, and I ended up with half the functionality I
needed, would the project still be successful?" Never mind the numbers here — they vary depending upon
the nature of the project and people involved — but if you're thinking this way, you are on the right track!
In our experience, the only answers to "How much is this going to cost?" and "How long is
this going to take?" that are even remotely reliable require a Prototype
Design phase. Be very wary of setting cost and schedule
expectations before a Prototype
is vetted and approved, because it is very difficult
to un-ring that bell!
Overly Ambitious Scope
One lesson on project scope: don't bite off more than you can chew. It is software after all, not a cake that you are baking
in the oven – with only one shot at getting it right. Keep the initial project scope limited to the minimum essential
features, and defer any nice-to-haves or issues with no consensus. You can
always address these items at a later time. Avoid the temptation to over-emphasize new, additional features at the expense
of simplicity, stability, cost, and the schedules. And don't be afraid to say no for the right reason.
Take a close look at your situation for the above risks. Are you looking for a cost-effective,
short-term solution where one or more of these risks are manageable? Or, will you (and others) need to live with the results for quite some time. The wrong choices
often results in much higher costs over time, not to mention the unnecessary (and avoidable)
frustration and wasted time.