As a part of my project and portfolio management consulting practice I frequently get involved in advising various companies on how to run their real-life projects. In my previous article "How Not to Handle Project Negotiations" I shared a discussion that took place between three project stakeholders and invited the readers to find the mistakes that happened in that conversation. Today I am providing my proverbial two cents on the situation at hand ...
Sheila: You know about the problems we had with the release 4.0 of this product. You guys were late by 3 months, went almost 50% over budget and delivered way less features that we expected. Besides even the stuff you did deliver had serious quality issues.
Aha! So the previous similar project has been a failure on all three fronts: late, over budget and delivered less scope than expected. I wonder if optimistic estimation had anything to do with that?
Dan: Yes, and because of all these problems we lost two of our customers and several others warned us not to contact them until we have e-Merchant 5.0 ready with all the necessary features …
And these failures are beginning to have a strategic impact on the company's well-being ...
John: Yes, I understand your concerns and that is why we decided to invest a bit more time in scope definition in order to be able to better estimate project size, risks and duration.
Sounds like a very smart move to me. After all it is impossible to come up with any meaningful estimates until one knows the scope of work.
Dan: How much time are you planning to spend on requirements gathering?
John: We estimated that we would need about four weeks to elicit and document all the requirements and another week to for the team to conduct document inspections and generate estimates.
Again, sounds very reasonable.
Sheila: This is unacceptable! I understand the process but we can’t afford to spend five weeks on scope definition. Can we somehow speed up the process? Besides I thought the scope has already been defined by our Marketing team.
Requirements have been defined by the marketing team??!! Since when does marketing people acquired the capabilities to elicit, analyze and document requirements? They can provide you with high-level features required to be included in the project, but, as a rule, they are not very likely to break it down into functional requirements, use cases or user stories.
Dan: Yes, and we also generated some preliminary forecasts based on our previous estimates on similar projects, so you probably don’t have to worry too much about that …
The devil is in the details! "Preliminary forecasts based on our previous estimates". Historical estimates, not the actual historical data! And we already know (see above) how well those estimates "performed".
John: Well, I guess if we can’t wait that long the team will have to work with these inputs.
John's capitulation #1...
Dan: Also, keep in mind we have promised to our customers that e-Merchant 5.0 will be ready in six months
John: What?! Six months? But you know very well that our past release (e-Merchant 4.0) took us 10 months to deliver and release 5.0 is even larger … Why would you commit to six months?
What he said!
Sheila: Look. John this is not really the time to argue about things. The customers are expecting a great quality product in six months. We all must roll up our sleeves and work harder to deliver it!
John: Well, we will see what can be done …
John's capitulation #2...
What should have happened instead? All the stakeholders should have waited until John and his team gathers, analyzes and validates all of the project requirements. Then the project team should have generated its estimates for all scope features (use cases, user stories, etc.).Then all of the scope components would have to be prioritized.
Once the team and the stakeholders knew (1) project scope, (2) team size and (3) effort required for each feature it would be very easy to calculate the total duration of the project. If the actual duration of the project was longer than the desired six months (a very likely scenario in this situation), then the project stakeholders would have to try to "obtain additional degrees of freedom" by asking the following questions:
- Scope and Quality:
- “Can we move some of the desired functionality into the next phase?”
- “Can we cut some scope items altogether?”
- “Can we polish some features less?”
- “Can we relax the detailed requirements for each scope item?”
- “Do all the scope items have to be of the highest quality possible?”
- Resources
- “Can we add more technical resources?”
- “Can we add more experienced resources?”
- “Can we provide our resources with proper training?”
- “Can we add more administrative support?”
- “Can we increase the degree of technical resource support?”
- “Can we eliminate company red-tape?”
- “Can we increase the level of customer involvement?”
- “Can we increase the level of executive involvement?”
- Schedule:
- “Can we set a schedule goal but not an ultimate deadline?”
- “Can we set a project goal of short schedule, and look for ways to reduce time planning and execution stages?”
- “Can we use estimation ranges, and agree to refine them as the project progresses?”
Please contact me directly via email at jamal@thinktankconsulting.ca or by phone +1-778-995-4396 if you have any project or portfolio management-related questions.
About the Author
Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East. Read Jamal’s Blog @ www.thinktankconsulting.ca
- Please follow me on Twitter:
- Like our page on Facebook:
- Connect with me on LinkedIn:
- Subscribe to my RSS feed:
Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.