Friday, 20 September 2013

Prioritizing Requirements for the Project – Part 2

In Part 1, we began to look at a workable five step scenario for setting up a requirements prioritization process, prioritizing project requirements and then managing those requirements with the help of the assigned priorities throughout the course of the project engagement.  We examined the first two steps in the five-step process.  In Part 2 we’ll examine the final three steps and I welcome your thoughts and feedback on if you find prioritization helpful or necessary and how you go about prioritizing requirements if you do incorporate that as part of your process. 


Resolve inconsistencies.  Once everyone has had a chance to do their prioritization, resolve the differences.  Start by throwing all of the requirements that everyone has ranked the same into the appropriate bucket.  That is, if everyone prioritizes requirement A as a 1, it’s definitely a 1.  Then, move to building a consensus on the requirements that different people prioritize differently.  Get the stakeholders together, and show them the requirements that they agreed on and then the ones that they ranked differently.  Often, people will find agreement after some informal discussion.  If not, note who is disagreeing.  When you are managing development of a product for a particular customer, that customer’s prioritization should usually carry the most weight in the discussion.

If a strong disagreement continues over a particular requirement’s priority, put the requirement in the higher class to stop the debate.  If you have a single holdout insisting that requirement D is a 1 while everyone else thinks it’s a 2, go ahead and put it in class 1, with a note to put it behind the other priority 1’s in the schedule.  Keep the process simple and speedy.  At this stage of your product, you don’t know enough to find a perfectly optimized solution anyway.

Create a priority-based project schedule.  After you have a set of priorities, use them to create priority-based development schedules.  Show everyone where work begins and ends on each requirement.  This information helps you define intermediate products or “releases” containing the high-priority requirement implementations.  These schedules will also help your developers synchronize work on particular requirements.

Maintain the priorities throughout the engagement. Throughout the development effort, you must maintain the priorities.  You don’t finish with prioritization until you finish the last version of the product or implement the last phase of the project.  Revisit them as the team – with the customer as needed.  Go back to what you laid out in your mind mapping software and see where adjustments may need to be made along the way.  You may find that tradeoffs will have to be made along the way during design and development of the solution to make sure that the priorities are still driving the effort on a realistic overall project schedule for the solution.  When the customer brings new requirements (and they always do) that require deferring some old requirements, you will need to work with the team and customer to review and re-assess the priorities given to key requirements to be sure that the most important requirements are kept on the critical path and the lesser prioritized functionalities are the ones pushed out or potentially discarded altogether.  

Summary

That’s my five-step process for prioritizing project requirements.  I admit that I don’t use it on every project – just the ones where I feel…and the team feels…that it will be helpful.  Any lengthy project really needs this type of process incorporated and complex projects that run the risk of several change orders, potential scope issues, or very tight budgets that are going to be difficult to keep on track are all candidates for this type of oversight.

How about our readers – do you use a process to prioritize requirements?  Do you do it for all projects or just a select few?  Please share your thoughts and experiences.



Brad Egeland is an IT veteran of 27 years having worked as an application developer, manager, project & program manager, consultant and business strategist and is the author of BradEgeland.com

No comments:

Post a Comment