Mistake #1 - Not involving the business users

The project was pretty much run by the technical manager and an engineer from the client side. From time to time, an architect would be brought in to check the direction. To be fair to the architect, he did a reasonably good design of the original system about two years ago. The spec document was fairly clear.

The missing piece in whole story was - the business stakeholders were nowhere to be seen. Almost six months after the project was signed off by the technical folks, the business users realized that the existing system can't be replaced by the new piece of software. They took it up with the head of technology, who brings in the CxOs into picture. From the vendor organization, what appeared to be a closed project that entered the maintenance mode now looks like a failed project.

For a consulting organization, it is important that business stake holders are involved possibly in every phase of the project.

• Know who the business users are.
• If the requirements were done by a client side stakeholder, ensure that it was discussed with the business users and signed off.
• Get access to the existing system to understand how it works and what more needs to be built.
• Determine the data migration that's needed and review it for every feature addition.

An Introduction

I wanted to write about a failed project about a year ago. Problems in that project continue to resurface forcing me to write about the things that can go wrong in a software project.

When I took over the project, was already by about a year. The original estimate for the project was about 5 months. My role is to work with a Project Manager / Architect / Technical Lead to ensure closure for this project. In the process of ensuring closure we come across numerous instances of things done wrong. These range from lack of clear communication, documentation to escalation. These are typical problems of a typical failed project.

The only good thing going for this project at this stage is everyone is interested in getting a closure. The client wants a closure to move the software to production or semi-production. The vendor wants a closure to free up resources for another project - hopefully a new contract to maintain this.

To begin with let me list the people's roles. Going forward we will list on who went wrong where.

Client Side
Product Manager - The business side owner who sponsors for this project.
Technical Contact - A multi-tasking person who knows the existing system and has some idea on how it should behave in the new version.
Architect - A shared resource who is available only to address technical issues and validate design decisions if asked.

Vendor Side
Project Manager - The person who is supposed to be most accountable from the client side. He ensures the schedules and deliverables are met in every phase of the project.
Technical Lead - The person responsible for the quality of the solution, involved in every design decisions and performs code reviews.
Software Engineers - The people who write code and do unit testing before committing the code to the version control system.
QA Engineers - People who understood the requirements well and are responsible for ensuring that the application behaves as expected.
CxOs - The people who are brought into the context of the project when things go wrong.