The ability to plan, analyze, and mitigate product, project, and program obstacles to success and take advantage of opportunities is key to innovation and to delivering highly successful products and services that customers will buy.
The 2015 CHAOS Report from the Standish Group, has redefined project success as on time, on budget, and with a satisfactory result. This shifted focus on providing value has shown a marked decrease in the number of projects that are considered successful when tracked over the last five years (2011–2015). This shift means the organizations can no longer simply default to using the traditional project triple constraints as success criteria and must use other performance metrics to prove success.
Key to providing value is baked into the six steps of project risk management process from A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (PMI, 2013), which can be integrated within the Business Analysis planning activities and deliverables. Additionally, the use of a risk-based approach to requirements planning and management that can be used in any project, whether using a traditional or agile approach, will be discussed.
value, risk, agile, requirements, success
Once upon a time, there were three project constraints: time, cost, and scope. Over time, these constraints have become the de facto standard of project success criteria for organizations. Just because a project is on time, on budget, and on target (scope), does that automatically guarantee stakeholders are happy with the outcome? The truth is that many projects that have met the triple constraints’ success criteria did not return value to the stakeholders and the organization, and the sponsor was not happy. When I was working at Motorola, we built a US$1 million solution that got implemented, but not used, by the target end-users. Not using a system means it can never provide a return on investment (ROI) even though we did all the right project management activities.
In order to increase the probability of project success, we need updated project success criteria that more accurately reflects how business looks at projects as business investments.
REDEFINING PROJECT SUCCESS
The CHAOS Report from the Standish Group (2015), has summarized software development outcomes of 50,000 IT projects around the world, which ranged from small software development enhancements to massive system implementations. In 1994, the Standish Group reported that 16% of IT projects were considered a success, 53% of the projects were challenged, and 31% failed outright. By 2006, we thought we were making progress with our projects when 35% of projects were successful, 46% were considered challenged and only 19% failed. Then in 2009, the percentage of successful projects dropped by 3%, and failed projects jumped up by 5% (Van Hese, 2010). We seem to have a problem here. Are we using the most informative project success criteria?
After much research, the 2015 CHAOS Report (Standish Group, 2015) redefined project success as on time, on budget, with a satisfactory result. Furthermore, the Standish Group believes that organizations should forget about the triple constraints to measure individual projects and focus on the value of their project portfolio (http://www.standishgroup.com/service).
They believe this will free organizations to:
- Increase ROI
- Increase innovation
- Improve stakeholder satisfaction
- Decrease project overhead
- Reduce management frustration
Exhibit 1 shows that, with this updated project success definition, on average, only 29% of projects were considered successful between 2011–2015, a marked decrease in percentage of successful projects since 2006 (Hastie, 2015).
No matter what definition you choose for project success (the traditional triple constraints or the updated version), organizations are still struggling to deliver successful projects and make their stakeholders happy. So what can you do to dramatically raise an organization's confidence that if you build it, stakeholders will buy it?
SIX STEPS TO PLAN AND MANAGE REQUIREMENTS PROBLEMS BEFORE THEY HAPPEN
I have seen many organizations plan and manage requirements differently by various roles in the organization. Sometimes, the product owners are assuming the responsibility to define the requirements. If the requirements are handed to the business analysts (if there are any) and/or project managers, then these roles just become order-takers. A better scenario is to involve the key project team members early in the workflow to elicit the requirements from the business to produce better requirements which produces more successful projects.
Ideally, any role can learn more about the science and, more so, the art of eliciting high-quality user requirements to make projects more successful. Getting users involved in project decision making and information gathering is cited as one of the top three factors that make projects successful (Hastie, 2015).
To plan and manage requirements, a product owner, business analyst, project manager, and any other project team members need to understand that there is a difference between the requirements life cycle and the project life cycle. According to the Business Analysis for Practitioners Guide, the requirements life cycle (Exhibit 2) is “the flow or life of a requirement throughout a project or program” (PMI, 2015).
While this flow is continuous when eliciting stated requirements, it is just the tip of the iceberg in the requirements life cycle. Every requirement brings with it, a certain degree of risk. Risk has a positive or negative effect on one or more project objectives. Therefore, combining the good practices of eliciting requirements along with risk planning and management can significantly improve satisfactory results.
Often times, I hear that risk management seems so hard and people avoid doing it. The rest of this article provides ideas for how to make it easier to plan and manage your requirements-related risks. There are six process steps (Exhibit 3) that should be done for every project and the most critical step is to plan for HOW you will do risk planning for requirements.
I was brought into a major beer manufacturer in St. Louis, MO to teach project management essentials to sales people in two hours. At first, I wasn't clear as to the underlying reasoning for wanting this class to be taught at a sales meeting. I quickly realized that this topic was part of the sales management team's secret plan to illustrate to their vice president of sales about the value of spending more time on planning, rather than just hitting the sales numbers. The directors knew their mainstream beer customers (who are not happy with their beer), proved they will easily jump to microbrews. It became clear that if the sales team spent more time on planning to prevent known issues with the product and delivery before they happened, it could help the sales numbers from declining.
The most successful projects and programs have a detailed plan. “When you fail to plan, you plan to fail.” With the trend in using agile approaches, organizations assume that less time in planning means more doing. However, they have failed to calculate the cost of poor customer satisfaction, poor brand image, and increased competition in deciding how much time should be spent in planning.
According to Business Analysis for Practitioners: A Practice Guide, creating a requirements management plan which is part of the project management plan “describes how the overall requirements of the project will be elicited, analyzed, documented and managed across the project” (2015, p. 46).
For example, how do you know whether items should be risks, issues, or requirements? Use the concept of probability to define what activities should go into each of these three buckets. If the probability is 100% of something happening, it's a problem and should go into the issue bucket. If conflict is going on right now and it is getting in the way of project success, that conflict is an issue and should be documented on the issue log. If the probability of an activity is less than 80% that it may happen, then it is considered a risk. If the probability of an activity happening is greater than 80%, then it is considered a requirement and it goes into the plan. If you determine that the probability is greater than 80% of having defective requirements, then you should create a requirements management plan.
As you are identifying requirements in initiation of the project, business analysts and project managers should also identify the risks related to the stakeholders providing the requirements. For example, user involvement has been identified as a factor for making a project successful. Therefore, a business analyst or project manager might do persona analysis for anyone who will touch the end product(s) and has a need or want fulfilled. A product may delight a customer, but might be hell for those who have to repair and maintain it. By gaining continuous feedback from persona as the product is developed, we avoid unpleasant surprises later.
The difference between a persona and a stakeholder is that the persona focuses on defining types of stakeholders such as “Peter the Purchaser.” Persona includes a detailed story about how “Peter the Purchaser” will interact with a product, his specific preferences, his frequency of doing certain actions, etc. A persona may even be a user who has no influence on the outcome of the product. In stakeholder analysis, individual stakeholders are identified which have interest and influence in the outcome of the project. (PMI, 2015, p. 45).
My assumption is that for 90% of projects, subjectively analyzing requirements risks is good enough. However, I often see that the process for analysis is flawed and becomes a frustrating exercise that provides little value to the stakeholders.
For example, the commonly used process of using High, Medium, and Low for assessing probability and impact is not clearly defined as part of the requirements management plan, and thus each stakeholder has a different definition of High.
The key to doing this step is to it make it quick and easy. Micheal Lant, founder of projectyap.com, describes how to quickly analyze and prioritize user stories by using one of the most frequent finite resources, time (also thought of as Urgency), multiplied by Business Value (see Exhibit 4).
First, as part of your requirement management plan, define Urgency and Business Value by creating guidelines for analysis.
For Urgency, use a scale of for 1 – 5, such as 1 = not time constrained, and 5 = extremely time constrained.
For Business Value, use a scale of for 1 – 5, such as 1 = little to no competitive advantage, and 5= critical to the success of the business.
Once stakeholders have given each user story a score for urgency and business value, they can multiply Urgency * Business Value = Priority. These three values can be captured on the upper right hand corner of the user story cards. The highest priority user stories are those that score 25.
In only a few seconds per user story, this analysis technique can provide more value to the stakeholders, thus increasing the likelihood of success.
If the risk posed to your end-users is significant, it is worth your time to quantitatively prioritize the riskiest requirements.
If you identified your risks and wrote them down on sticky notes, you can easily prioritize them by placing the risks you identified on a Simple Prioritization Matrix (Exhibit 5) with probability on the vertical axis and impact on the horizontal. Step back and you will have a great visual tool for SEEING what risks you really have to deal with. Draw a line to focus on what risks you will deal with above the line and which ones you will have to let go for the moment, which are below the line. This threshold line is subjective depending on the risk tolerance of you and your stakeholders. Finally, number your risks to give you an idea of priority after you transfer the information on the sticky notes to a document or spreadsheet.
5. WHAT TO DO
Many organizations think they do risk management when they identify risks. If all you do is identify risks and have no plan for what to do if the risks happen, then you have wasted your time.
A properly written risk (threat or opportunity) helps to identify what is the best set of risk responses. Use the Cause, Risk, Impact format (Exhibit 6) for risks. By using this format, you will be able to clearly see what to do to mitigate the probability and impact of this risk.
This is the only step which is not a planning step. Managing risks for requirements means identifying new risks during the course of the project, keeping an eye on existing risks, and reporting on performance metrics.
Business analysts and project managers need to capture more than just time and cost when considering performance. Yet so many times, I see companies struggle to know what other performance metrics can be managed.
You can use tools to assess the impact of individual contributors to the success of the project (Exhibit 7).
This chart depicts the use of a productivity percentage for each of the staff on the define phase of a project to measure their performance.
Estimates for the time it takes to elicit requirements can be multiplied by the productivity percentage of each team member. When an activity is completed, the gap between the actual and the estimate can be analyzed to create a performance metric which may provide continuous improvement and more successful project outcomes.
These six steps for planning and managing requirements problems before they happen is something every team member can do. Instead of focusing on the status of projects, which focuses on the past, spend more time in planning to make happy customers who will buy your product, time and time again.
ABOUT THE AUTHOR
For over 25 years, Dayle Beyer has taught thousands of people how to save lives, manage projects better, take sophisticated exams, and deal with business and personal obstacles. She is a frequent speaker at industry events.
As CEO of Dayle Beyer Learning Solutions, she combines her knowledge and experience in peak performance project management, business analysis, leadership, and team development to help you build leadership strength for extraordinary success.
CONNECT WITH ME!
Hastie, S., & Wojewoda, S. (2015, October 4). Standish group 2015 Chaos report - Q&A with Jennifer Lynch. Retrieved February 23, 2016, from http://www.infoq.com/articles/standish-chaos-2015
Lant, M. (2010). How to easily prioritize your agile stories. Retrieved February 23, 2016, from https://michaellant.com/2010/05/21/how-to-easily-prioritize-your-agile-stories
Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.
Project Management Institute. (2015). Business analysis for practitioners: A practice guide. Newtown Square, PA: Author.
The Standish Group - Service. (n.d.). Value portfolio optimization and management service. Retrieved February 23, 2016, from http://www.standishgroup.com/service.
Van Hese, Z. (2010, April 7). Test side story. Retrieved February 23, 2016, from https://testsidestory.com/tag/chaos-report/