Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  How to make users prioritise requirements usefully
Previous Previous
 
Next Next
New Post 8/10/2009 3:43 AM
Unresolved
User is offline thommeread
1 posts
No Ranking


How to make users prioritise requirements usefully 

 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

 

 
New Post 8/12/2009 4:20 PM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: How to make users prioritise requirements usefully 
Modified By Craig Brown  on 8/12/2009 6:23:01 PM)

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.

 
New Post 8/13/2009 7:19 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: How to make users prioritise requirements usefully 

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

 

 

 

 

 
New Post 8/13/2009 9:32 PM
User is offline KJ
243 posts
6th Level Poster


Re: How to make users prioritise requirements usefully 

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

 

 
New Post 9/1/2009 3:38 AM
User is offline KIERANC
22 posts
9th Level Poster




Re: How to make users prioritise requirements usefully 
Modified By KIERANC  on 9/1/2009 5:50:00 AM)

 

 

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

but will not have this time round

"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.

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  How to make users prioritise requirements usefully

Community Blog - Latest Posts

The CEO/CIO's Guide to Architecting AI: Vision to Value in Minutes Introduction to Architected AI Artificial intelligence (AI) is becoming part of our life at an unprecedented pace. As CEOs and CIOs grapple with how to leverage this powerful technology to drive strategy and enhance operations, the concept of Architected AI becomes importa...
In today's dynamic business environment, mastering effective business analysis techniques is crucial for organizations aiming to achieve sustainable growth and competitive advantage. Business analysis involves the systematic evaluation of business processes, requirements, and strategies to uncover insights that drive informed decision-making. T...
For many years now, a lot of people have found it difficult to identify the difference between Sankey diagrams and parallel sets. The two have made headlines, given that most people find it challenging to note what makes them different from each other. What remains to be undeniable is the fact that the Sankey diagram is among the top data visualiza...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC