Have you ever worked on a big project that went well beyond it's planned timeline or blasted through it's allotted budget? What went wrong? I have my own personal experience with a recently failed project that caused me to ask some hard questions. Many of them are still unanswered but I have my theories. I think we went through several cycles of a variety of failure points. The most critical failure, I believe, was that the people with "the vision" wanted the software built based on an "I know what the client wants" premise, rather than actually discussing the requirements with the client. Kind of a "Build it and they will come" mentality, if you will. There were many problems along the way, though, that I'd like to cover so that maybe it can help someone else down the road.
- Lack of understanding by those in charge of completing the project:
- Stakeholders not really knowing the market, even though they may believe they do, and designing a product that nobody really wants or needs. Not understanding the business user and not including or including incorrectly the functionality that is really needed.
- Not understanding the technology limitations (this was a big one for us on several levels).
- Underestimating the impact of change. Every time we neared some milestone some management-level individual would think up some feature that the product absolutely must have by this timeline, "otherwise it won't be useful to anyone!". Scope creep is a killer, people.
- The individual or entity asking for a change has no idea what they are really asking for. In my experience this one happens more than you would think.
- Ineffective communication:
- Stakeholders basically throw the idea over the wall and wait for the results. This, my friend, is the road to nowhere. Want your team to flounder for a couple of months? This is the perfect approach, trust me.
- Not providing sufficient documentation. I can see where this works sometimes with very small teams but I'm guessing this would only work if all team members posses an intimate knowledge of the space they are addressing. If the hired engineering team does not posses the same intimate knowledge of the industry as the stakeholders then well-documented requirements are a must. An engineer that doesn't understand the market and has no real requirements is doomed.
- Unrealistic expectations from the beginning
- Setting timelines and project costing arbitrarily based on when they want it done rather than based on what is involved or the amount of work needed to get it done. My company currently lives by the get it done by a certain date mentality, which really sucks (especially sucks because this mentality comes from the very top). They often provide less than half the time and budget needed and they simply will not be bothered by the reasons why it is impossible. This little problem reaches epic failure when the stakeholders set timelines before they've even defined the project.
- Not making adjustments to expectations as the project progresses and requirements evolve.
- Planning for time (see above) rather than planning for effort.
- Not staffing appropriately. Make sure you have the right skill sets for the right tasks. Not the right priced employee.
- Not equipping staff with the tools they need. We did not even have the equipment specified as the minimum operating requirements (an arbitrary set of requirements, mind you) until well after we had passed our release deadline.
- Change Control
- Scope creep. This often stems from a project that has no true definition and/or a mentality where managers pander to every whim of the end user, rather than filtering out those requests that don't make much sense.
- Not understanding that even small changes take time, add cost, and entail a certain amount of risk.
I'm sure I've missed several points but the picture should still be fairly clear. This is really just a reflection of my own recent experiences and does not reflect the fact that the company I work for is definitely trying to improve their processes to avoid repeat failures. They've had many successful projects in the past but they were often relatively small projects and one or two people, that had intimate industry knowledge, doing all the work. Now that we have a larger team of people involved and projects on a much larger scale we absolutely must implement measurable and enforceable process, plan, and document requirements.
I feel it was a general lack of understanding of the marketplace, of the technologies, of the capabilities of those involved, of the impact of change, etc. that led to the many levels of failures we experienced. This project completed but it was 1.5 years past due.
I think it's also important to stress that if you're going to outsource a project you make damned sure that the company you're outsourcing to has the resources and is completely qualified to complete the project. I can't even begin to describe how insanely difficult it was to work with the team we had outsourced our project to initially.
Good luck!