Delivering a software project on time and on budget is easy but it rarely happens.
| Failed Project |
Successful Project |
| Requirements are high level and contradictory in places. For example “the application will be 100% customizable” or “the site will be appealing to all users”. The customer representatives and Business Analysts did not do the hard work to identify true requirements yet no risk premium was added to the price. |
Requirements are low level and clear but not so detailed that they dictate design. The Business Analysts politely pushed the customer to identify the true requirements. Even the rainy day scenarios are listed. eg. “What if there are no videos available at all?” “What happens if they hit Cancel?” |
| Requirements for a single task are spread across many documents and emails. There is no single source where a developer can obtain the information they need to do their job. |
Requirements for one task can be found in just one or two documents. A task tracking system was used to summarise information about a piece of work. The development team maintained a project wiki as they discovered new information. |
| When the project was quoted, integration interfaces were just bullet points on a requirements document. Most of the integration third parties were not ready - yet no risk premium had been added to the price of the job. |
Quoting and development did not occur until the integration points were clearly defined and third parties were ready on time. Developers wasted no effort. |
| All requirements and API documentation is in various people's inboxes. |
All project documentation is managed in a source code control system. |
| All development knowledge is in the heads of the developers and various email inboxes. |
All development information is captured on a wiki, so any mildly competent developer can support the application. |
| One month before “go live” the customer is still having trouble deciding scope of the project. |
Since it was a waterfall project, the project did not begin until the customer was clear on scope. |
| The project plan is five years long. |
Although the budget is for five years worth of development, the initial project plan is one year long, with a review and reevaluation of the long term vision at the end of the first year. |
| In addition to the technologies forced upon the project by integration points, the developers also used eight new bleeding-edge JAR libraries and frameworks that the developers did not have expertise in, because they wanted to try them. |
In addition to the technologies forced upon the project by integration points, the developers wanted to use eight new bleeding-edge JAR libraries and frameworks that the developers did not have expertise in, but the Technical Lead's Kung Fu was good. He said the new jars were risks and permitted only two. One of the two didn't make the grade and it was removed. |
| Integration with the back-end system was done last, and to the surprise of the developers, it wasn't ready. |
Integration was a planned activity, and built first on the project. Stakeholders were prepared to accept software with fewer screens early in the project. |
| Everyone arrived on the project on day one and developers started coding their tasks furiously. Everything just evolved. |
A handful of experienced developers arrived a couple of weeks earlier to start the project, set up build servers, build scripts and code-by-examples. |
| Development team and Project Manager did not trust each other. |
Project Manager and Technical Lead sat down at the beginning of the project to manage expectations. The Project Manager protected the developers and the Technical Lead provided the manager with enough information to keep adequate track of the project. |
There are many other reasons why projects fail, but the successful projects all seem to have the same characteristics.
“The project had one month to go before the deadline that is in the contract. The customer was still having trouble deciding the scope they wanted delivered. The developers were scrambling daily to change the software to meet wild requirements.”
Sound familiar? The solution of course is not to get in this situation to begin with, but usually this is the result of poor project management in the scope definition phase. If this kind of thing happens on the majority of projects, discuss with your technical leads who may be able to influence the process.
However, there are a few things that can manage these kind of problems once they appear:
Get the business analysts and project manager to define scope, policed by the Technical Lead. Unpleasant for the customer and project manager, but it is their job.
Follow an Agile, phased approach and place the tasks in a priority list. Enforce the “no changes during an iteration” regime, even if you need to reduce the length of an iteration to get buy-in from the customer.
Embed a customer representative in the project team to attend standups every day. The representative must have enough authority to make decisions on behalf of the customer stakeholders (or at least get approval rapidly). They will be responsible for prioritising the tasks to be completed during subsequent iterations. This will help lock down scope.
Alternatively, move the development team into the customer office - with a dedicated internet connection so they can still function without firewall restrictions.
If there is enough time, build a simple XHTML prototype of what is to be delivered and get it signed off.
