HomeServicesTechnologyAnalyticsOur ClientsAbout PCAContact Us

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 rubble.

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 database 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.
Over-reliance on 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.

PCA Recommendation

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.