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 4th 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 4th 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?
Fast forward to the 4th 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
That would definitely work using the SCRUM software PM methodology. SCRUM does not really address how to manage risks to the same extent as waterfall or another traditional (read: mature) methodology. Since this risk came to fruition, we will likely be implementing a formal risk register and incorporate risk status in our SCRUM meetings to avoid similar obstacles on future sprints and other projects.
ReplyDeleteThanks for the input!