You are cruising along on your current project engagement and life seems great. After all, you and your team thought of everything, right? And what the customer came to you with at the beginning of the project – well, that just saved your teamwork and saved the project time and money so the schedule and budget are in good health.

Then, BAM! Things start to go wrong and you can’t seem to get a handle on where it all went south…or why. Has this ever happened to you? If not…great…you’re one of the lucky ones. But most of us – in PM roles – have witnessed this first hand on our projects or watch a colleague’s project go up in flames before and often it’s due to one of the five potential project killers that I will be discussing during this five part series.

The first potential project killer I’d like to discuss is the concept of starting the project off too fast. And by that I don’t mean hitting the ground running and moving along swiftly and efficiently. No, that’s just good project management work. What I mean is, kicking off the project and moving on to the next phases before the project is properly defined or before requirements are properly documented.

Start before you’re ready

I've always said, “Requirements are the lifeblood of the project.” You get a project, you have the statement of work (SOW) in hand, and you've drafted a project schedule and you’re kicking off the project with the project client. What may start to become apparent is that either there are not enough requirements in place or well enough defined to really start the project, or the customer doesn't yet fully understand the solution and how they will use it. The requirements issue may jump out at you quickly – especially during kickoff discussions. The understanding of the solution and how to use it – that one is going to take some discernment and help from your delivery team to recognize.

Watch for the signs because the deeper you get into the engagement the more apparent this is going to be and when you go to implement that final working solution, the customer is going to think you’re talking a different language if the gap in understanding has continued to widen throughout the implementation.

You are the expert – you and your project team. Plan enough time in the project schedule to thoroughly run through any form of requirements – high-level or detailed – that the project client has provided you with and ask tough questions to make sure you know what they need and want. If you recognize that there are requirements issues early or that the customer is barking up the wrong tree in terms of what the real need is or what the real project should be, then you can circumvent utter project failure by stopping, putting more time into discover and requirements definition, and restarting with a clear picture of where the project needs to go and what the solution needs to be. A couple of extra weeks spent early on and a few thousand dollars expended on this effort may stop a project failure or a $200,000 overrun later in the project. Trust me, I've taken over a troubled project in this very same situation and it’s painful to watch and even more painful to actually be a part of.

Summary

Many projects survive issues that would kill lesser projects and lesser project teams and PMs. But the act of starting a project off with bad requirements or a poor understanding of the business processes of the client environment often leads to disaster. If not outright project failure, it at least leads to a final solution that doesn't meet the client’s real needs and they are left with their own end user base that can’t use a solution that they just paid good money for. They’ll never turn into a satisfied customer that way…and that does not equal success in anyone’s book.

In the next installment, we’ll look at a second potential project killer…the non-existent or vague budget. Sounds like it would be a dream come true, but it’s far from that.

Choosing the right tool is crucial for the success of your project. Telerik TeamPulse allows you to expressively define and effectively manage requirements. The product enables you to easily capture ‘user stories’ (high-level informal statements of requirements), associate them to personas (end-user profiles), create relationships between stories and much more.


Brad Egeland
About the Author

Brad Egeland

A Business Solution Designer and IT/PM consultant and author with over 25 years of software development, management, and project management experience leading initiatives in Manufacturing, Government Contracting, Gaming and Hospitality, Retail Operations, Aviation and Airline, Pharmaceutical, Start-ups, Healthcare, Higher Education, Non-profit, High-Tech, Engineering and general IT. Brad is married, a father of 9, and living in sunny Las Vegas, NV.

Comments

Comments are disabled in preview mode.