By TonyC_UK on Dec 04, 2011
Everything is urgent. How many times have you heard that? The business needs this functionality to launch a new product, we have to have that piece of functionality to comply with new legislation, our current software licence is expiring. There are a myriad of factors influencing priority how do you deal with them in a way that recognises and mitigates for risk. Yes, risk. How often have you been tempted to put off dealing with difficult or risky functionality? How often has your decision to take the low hanging fruit turned sour?
In OUM we have an approach to prioritisation that is comprehensive and realistic, in other words fit for purpose.
Before you start the list of Use Cases should be reviewed and approved by the key stakeholders to ensure expectations are managed.
When that is done we can start evaluating use cases based on four perspectives.
Customer priority - Importance of the use case to the business, and the urgency to have its functionality.
Risk- you need to recognize risk early. This needs to managed closely.
Complexity – a measure of difficulty (requirements and development). This also needs to managed closely.
Dependencies – you need to know the connections.
Now let us drill down a little on each one.
Identify whether functionality is highest priority and is the focus of the system, or borders on being out-of-scope with a real potential to be postponed.
When it’s a challenge to get your customer to commit to prioritizing Use Cases, a 2 x 2 Urgency/Importance Matrix can be helpful.
This gives you a way of seeing what the Importance of the use case to the business, and the urgency to have the functionality available .Used in combination they help to determine priority.
The premise is that Importance is a measure of value to the business and Urgency is a measure of how quickly they need this functionality, so these can be used to differentiate priority.
Risk is a measure of uncertainty and for each Use Case you should identify the things that could occur and the impact to the project if it did
A Risk Portfolio Chart can be used to plot each Use Case profile based on its probability of occurrence and the degree of impact if the risk(s) occurs.
There are generally four categories of Risk. These four (4) categories should be used as a checklist by you to ensure all risks are identified.
Each risk that is forgotten or mismanaged may cause schedule slips, implementation problems, or worse.
It is important that people understand what gets elevated to management vs. what can be handled at project level - e.g., management risks often cannot be handled at the project level.
Technological risks are the risk that project result will not comply with performance, functional, inter-operability, or quality requirements
Project management risks are risks to cost or schedule. What is the risk that the project cost will exceed the budget or schedule
Organizational risks are attributed to organizational changes at the client site
External risks are those risks imposed by external factors such as Labour unions or trading community partner organizations
· Sometimes it is useful to graphically plot the Use Cases on a Risk Portfolio Chart. Each use case is assessed and then plotted on a risk profile chart to show the probability that the risk(s) will occur and the degree of impact if it does.
The higher the probability and the impact, the more emphasis a project manager should place on that Use Case to ensure the proper mitigation strategy is applied to eliminate or reduce the risks.
You need to assess whether functionality contains simplistic input and output algorithms or intricate critical methods. Typical complexity factors to consider are:
Number of Actor Profiles
Number of proposed scenarios
Kind of System
Simplicity of the User System
It is common for one Use Case to “depend upon’ one or more other Use Cases and/or external interfaces. Often the pre- and post- conditions of a Use Case will hint at these dependencies.
Dependencies between Use Cases and/or external interfaces often will drive the sequence regarding how the Use Cases will need to be written and/or implemented.
These perspectives provide input into the planning process. Use cases do not have to be prioritized this way, there could be other factors.
For example once you know the business delivery priorities, you can then plan the development priorities.
However one best practice is to address the highest risk early in the project. This minimizes the possibility of working on the least important things first, and then not having time. When the more complex or architecturally significant use cases are considered too late in the project lifecycle, you are at risk of missing requirements, which will severely impact the usefulness of the system to the end users.
So, everything is urgent. Correct??