Dear PM Advisor. Jun 16, 2014

Dear PM Advisor,

We are documenting our assumptions as we plan but we’re concerned. A lot of the assumptions we are making won’t be proven true or false until we are halfway through the project. Management has challenged these and told us they won’t approve the project unless we have answers to all these questions.

What can we do?

Nervous in New York

Dear Nervous,

Project Planning is the process of predicting the future. But management typically wants our predictions to be 100% accurate while we are dealing mostly in hopes and dreams. We can never be 100% accurate in our predictions so we use past data to try and improve our predictions.

Along the way we need to make assumptions to continue planning. Since we don’t know which of two or more paths will prove to be correct, we assume the most likely path to be true, treat that as a fact and continue planning accordingly. This allows us to complete a project plan, along with all the assumptions that got us to that point.  It is extremely important that management buys off on all these assumptions when they approve the project plan. If they disagree with an assumption, they need to let us know. We’ll pick one of the other paths as true and adjust the plan accordingly.

Some of these assumptions will not be proven to be correct until the project is underway. That is a reality of life. Your management needs to accept this reality and move on. The only way you can determine the validity of this assumption is to proceed to the point where it will be proven. So they need to either allow you to proceed or, if they are too unsure about the project, they need to reject the project’s progress to the implementation phase.

Good luck,

PM Advisor

Send your questions to Bruce@RoundTablePM.com

Dear PM Advisor December 31, 2012

Dear PM Advisor,

We use a modified SCRUM methodology at work and it requires us to have continuous contact with our end users. After the 4^th prototype the users made a major change to the infrastructure of the product. This new requirement almost changed the entire use case and affected the way every user would interface with the software. We anticipated this “new” scenario while conducting our initial interviews, but the users were adamant that it was never going to happen. 

Fast forward to the 4^th prototype, the users decided that we needed to support that situation.  Note that there are not a limited number of prototypes, but we are moving to production in just a couple of months. How do I get users to identify these changes earlier in the project and should we have accommodated the late request? 

Scrumster in Dallas

Dear Scrumster,

I don't claim to be an expert in Agile or Prince II but your problem seems to be something that goes across PM methodologies. You start a project with a set of user requirements and plan accordingly, only to have the customer change those requirements significantly near the end of the project. You were even a little ahead of the game and identified the change early on, only to have that risk come true when it was a little late. 

Here's how I would have handled it using my methodology. Let me know via a comment if this works in the scrum methodology you use. 

When a member of my team identifies a risk, we analyze it for probability and severity and then determine how we are going to deal with it in case the risk event becomes reality. This risk would have rated high on both probability and severity and should have been addressed. Since the entity who had the most impact on whether or not this risk occurred was the customer, you would have discussed it with them. Sounds like you did that. Perhaps you needed to emphasize the impact this change would have on the project in terms of time and money required to implement it at each prototype. 

You could have had them look at this impact and agree that, after the second prototype, the train had left the station and this change would not be allowed to occur on this version of the software. It's been my experience that users, when faced with the reality of the impact their changes have on the project, behave responsibly. They either agree to extend the production deadline or decide not to implement the change. 

Good luck,

PM Advisor

Send me your questions at bfieggen@gmail.com