Hi everyone,
I have a question. I'm trying to get my users to properly prioritise their requirements so the PM has something to work with. My predecessor on this project tried printing out all of the requirements and getting the users to place them on a long table - one end being 'must haves', the other for 'nice to have' features. Of course, when she came back in the room, they had put every single bit of paper in a pile at the 'must have' end of the table (!).
So, in an effort to force the issue, I want to impose a percentage split of categories: e.g. only 50% can be p1, 30% p2, etc. However, I've got no clue what the percentage splits should be.
Any ideas? Anyone tried this approach before?
Cheers,
Tom
BA, London
Rather than have them classify them into categories try getting your stakeholders to rank them from 1 to x. 1 is the most important and 2 is the second etc.
Either that or you as an analyst should do the work yourself and tell them what is most important.
Tom:
What is obvisous is that your users are lost. Saying that everything is important is being done out of cover-your-behind fear. What they are doing is crying out for leadership.
Chances are is that none of them have a comprehensive, integrated understanding of the essential business functionality. Such an understanding is prerequiste to effective prioritization. Simular to what Craig has said, come up with that understanding yourself; determine priorites from that understanding; get their OK on your priorities.
Tony
Friends,
I sincerely hope that the BA does not independently set priorities. Asking the SME is a recipe for disaster; their priority is whatever makes their job easier. Therefore, its sometimes good to refocus on strategy. Why are we doing this? What are the benefits etc. Most of the time users and SMEs just do not have this strategic knowledge. That is when you ask the senior manager as well as check the project brief with the project sponsor. It is important to link the ESSENTIAL requirements to the CSF (Critical Success factors) of the strategy. I stress the ESSENTIAL requirement; not “the how we do things now” requirement.
So, if you have a proper traceability matrix that links requirements to strategy, you would know which requirement needs priority. You MoSCoW from the strategy and CSFs. Words the BA should never hear are: “thanks for the requirements. This is exactly what we wanted; but not what we need right now”. The BA’s job is to provide management with what they NEED right now to support the strategy! The rest is mere embroidery.
Warm regards,
K
I would agree with that. The Traceability Matrix provides the key driver to link requirements to the strategy and assign priorities. Often we would use the MoSCow Rules Technique to prioritise a list of requirements based on the relative merits of each or their value to the business.
Time and cost play a key role in project delivery, so it is important to understand at the outset which features are essential to the delivery of benefits and the business needs most. "MoSCoW Rules" is a well established technique which is used to assign priority to requirements: This is complementary to Pareto's Law, often referred to in IT development as the "80/20 rule", which states that 80% of the objectives should be achievable with 20% of the resources. Once benefits have been identified and attributed to the requirements then time boxing can be exercised effectively. If a project has clearly prioritised its requirements it is better able to react to changing circumstances, e.g. a new "Must Have" requirement can replace a lesser priority one without affecting scope.
Using such a technique as MOSCOW will go a long way to producing an ordered list of requirements. With this technique in in conjunction with the users or business specialists assigned to your project assess each item on the list against the criteria set out below and allocate it to a category.
Must have
These are requirements that are fundamental to the successful delivery of the project's objectives, i.e. the minimum usable subset. Without them the system or service is unusable. It is essential to be critical of all "Must Have" requirements and when assigning this priority the business should be told that the significance lies in the statement "Without them the system or service is unusable."
A good measure of the quality of the prioritisation process is manifested by the proportion of requirements in this category. Ideally no more than 40% and certainly no more than 60% of requirements should be classified as "Must Have".
Should have
This category covers important requirements that deliver significant value to the business but can be omitted if time constraints threaten delivery, i.e. the delivered solution will still be usable and meet its critical objectives without them.
Could have
These are requirements that enhance the capability of the required solution but can be left out of the current increment.
Want to have
"Wants" are those requirements of limited value or applicable to a limited group of users that can wait until later development takes place.
You will really need to guide them your users on this. Ideally no more than 40% and certainly no more than 60% of requirements should be classified as "Must Have.
Traceability in turn simplifies the process of reviewing the impact of proposed requirements changes. Projects must demonstrate the bi-directional traceability of their requirements as this is mandatory action to comply with both Sarbanes-Oxley (S-Ox) and CMMI (Capability Maturity Model Integration) and to ensure your Requirements are linked to the Business Strategy and can be prioritised effectively. Regards K
brought to you by enabling practitioners & organizations to achieve their goals using: