Projects throughout the world are challenged. Think of your own projects. What percentage were completed on time, on budget, and with the anticipated scope? What percentage never made it to the finish line to land in the big project junk pile in the sky? Organizations such as Gartner and the Standish Group provide statistics each year that tell the same story. The fact is only 39 percent of projects today are completed successfully.
Figure 1 Project Resolution Results from CHAOS Research Years 2004 to 2012. The Standish Group
The statistics on project success have not significantly changed in the past 10 years, and neither has the cited reasons for the challenges that the projects face.
The most cited reasons for challenged and failed projects are:
1) Lack of clear requirements
2) Lack of executive support
This book addresses both of these reasons for challenged projects. It starts with the premise that lack of executive support contributes to the lack of clear requirements. That’s right. It starts with the executives, not the unfortunate project line staff trying to do too much with not enough time and the wrong set of skills. Figure 2 provides a visual of how the reasons relate to result in the project challenges we see today.
Figure 2 Correlation Between Executive Support, Poor Requirements, and Challenged Projects
Strategies for Project Sponsorship (Management Concepts 2013)i provides ideas and information to project managers and business analysts to help get the needed executive support in general for this project. This book focuses on making the business case for strong business analysis and outlining the executive and organizational support needed to mature organizations’ business analysis practice to improve project success rates.
Business analysis gained a new proponent in 2014 that will change how organizations view business analysis in the future. Well, to say a “new proponent” may be a bit strong as they have always had an interest in business analysis. The organization I am talking about is the Project Management Institute (PMI).2
In recent years, we have seen PMI taking a greater interest in business analysis with the latest editions of the Guide to the Project Management Body of Knowledge (PMBOK® Guide). The fourth edition, published in 2008, included “Collect Requirements” as a task for the first time (see below for my thoughts on collecting requirements). You can see how the role of business analysis has evolved for the PMI in their discussion of the “business case”. The fourth edition states, “The requesting organization or customer, in the case of external projects, may write the business case.”3 Fast forward to 2013 and the release of the fifth edition, “… such analysis is usually completed by a business analyst using various stakeholder inputs”4. This is a great step in the right direction.
“Collect Requirements?”
I have a hard time with this as a project task. The IIBA’s BABOK® Guide refers to this activity as “elicit requirements”. I think of project requirements like Easter eggs at an Easter Egg Hunt. We can collect those that are right in front of our face. But to get all of the Easter eggs, we need to do some analysis. We need to do a little digging, interview stakeholders (dad), and explore until the last Easter egg is found. Because if we don’t find the last Easter egg, we may have a big stinky mess on our hands down the road.
This is how we should treat our requirements to avoid a big stinky mess in our projects.
In 2012 the PMI introduced a new community of practice, Requirements Management Community of Practice. Here, PMI members could share information and find education information on managing requirements. What came next should not be a big surprise.
In March 2014 the PMI announced a new credential program, Project Management Institute Professional in Business Analysis (PMI-PBAMSM). While the credential name indicates that it is a general business analysis credential, the information provided and examination content refer to a proficiency in requirements management within the project and program context. This is a more narrow view of business analysis than the Certified Business Analysis Professional™ (CBAP®) credential offered by IIBA.5 However, the scope of the examination extends beyond requirements management and the project.
The year 2014 was truly the year of business analysis for the PMI, with the publication of PMI’s Pulse of the Profession: Requirements Management—A Core Competency for Project and Program Success6 in August of that year and prerelease of Business Analysis for Practitioners—A Practice Guide in November.7
PMI’s 2014 annual global Pulse of the Profession® study revealed that “inaccurate requirements gathering” remained a primary cause of project failure (37 percent) in 2014 (up from 32 percent in 2013). This fact, plus PMI’s focus on this practice area, led us to research this cause of failure in-depth and publish our findings in this report. (Pulse of the Profession Executive Summary)
PMI also states that this is the main reason for the creation of the PMI-PBAMSM credential.
The bottom line is that the PMI is on a mission to enhance the core competencies of those who elicit and manage requirements for projects and programs. This is the same mission that IIBA has had since 2003.
What I aim to add to the conversation is that projects need executive support to get skilled staff, training and skills development, time, and access to people and resources needed to elicit and manage quality requirements that maximize the chance for project success and added business value. Reading this book is the first step to realizing these benefits, and for the mere price of this book.
You can see in some of the more recent trends how organizations are working to try improving success rates of projects and bringing more value to the business with these projects. In reality, they are finding that none provide the magic bullet that leads to project success.
Agile
Agile methods, especially Scrum, became all the rage rolling into the mid- 2000s. It promised to be a way to deliver projects without a heavy investment of documentation and requirements upfront. The problem isn’t that Scrum is not a way to gain additional value from the projects an organization takes on. The problem is that it is misused. Tell anyone that you are doing an Agile project, and the first thing that comes to mind is that there is not any project documentation. Wrong! The Manifesto for Agile Software Developmentii states: “Working software over comprehensive documentation”. Agile is not a license to skip documenting the business need, but rather it provides processes to do this in a “just in time” manner, a manner that may not be acceptable to some organizations or project teams.
“Agile methods are not an excuse to hack at breakneck speed to make a quick buck. Instead, they are a disciplined new product development process that is optimized for efficiency, speed, and quality.”8
Let’s review the Agile Manifesto for Agile Software Development together.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Starting with the title, we can see this is a manifesto for “software development”. The development of software is a small piece of the overall picture in implementing a solution that will be of value to the business. The values are prioritized within pairs, but the manifesto does not claim that “processes and tools”, “comprehensive documentation”, “contract negotiation”, or “following a plan” do not provide value. Instead, the manifesto states, “There is [more] value to items on the left.”
One of the major challenges with Scrum is that the values of “working software over documentation” and “responding to change over following a plan” both lead to the need for rework. However, taking the time to do the needed rework and refactoring often gets neglected, resulting in a solution that does not meet the business need or requirements. There are two major contributors to this neglect.
The first is a natural tendency not to redo something that was once considered complete. Engineers find this frustrating. I have heard in my own project teams that they would rather see the full picture and build it right in the first place.
The other factor is that the project team does not provide adequate time in the schedule, or sprint backlog, for rework. The need for rework needs to be factored into team velocity or by adding user stories for the rework to the product backlog. Explaining this need to sponsors and executive stakeholders is a challenge.
Another issue I have with Scrum is that it ignores the role of the project manager. In Agile is Not a Project Management Framework,9 I fully detail the need, purpose, and role of the project manager in an Agile project. In short, there is still a need for a project manager and champion to orchestrate the project beyond the confines of the Scrum team.
One big strength of Scrum is the use of the product owner role. The product owner is the keeper of the Product Backlog (a prioritized list of features), and has ultimate authority over this priority within the development team. The product owner is often cited as “the single wringable neck” on the Scrum team. The product owner role is best suited to someone with strong business analysis skills. These skills will allow them to gain an understanding of the cost-benefit of features and the overall value they bring to the final solution. The product owner is also responsible for eliciting, documenting, and communicating the requirements for each of the user stories (features).
I am a fan of Scrum when the following conditions exist.
• Project management is a role outside of the Scrum team.
• The organization’s management understands and accepts the product backlog process and prioritization, and
• The team is fully trained, understands, and accepts the processes.
Unfortunately, I personally have not yet had the opportunity to work on a Scrum project where all of these were true, and the result was that each of these projects was challenged.
Lean
In 2007 Toyota passed General Motors to become the world’s largest motor vehicle producer. The success of Toyota is attributed to their use of Lean Manufacturing (LEAN) processes. “A manufacturing/production system best characterized as relentlessly eliminating waste from all of its activities and operations. Lean strives to produce products.”10 This is also the year that the Lean Global Network was established promoting Lean principles, setting the stage for LEAN in the mainstream. LEAN has been adopted in the project world as a new methodology. This methodology focuses on removing non-value-added tasks from the project. This becomes an issue when the view of “non-value added task” does not take into account the full project, solution, and stakeholders to the project.
5 Lean Principles
Value: Identify what really matters to the customer
Value Stream: Ensuring every activity adds customer value Flow: Eliminating discontinuities in the value stream Pull: Production is initiated by demand
Perfection: Retaining integrity via Jidoka (autonomation) and Poka-Yoke (mistake-proofing)
These five principles of LEAN further articulate the need for strong business analysis in organizations. Business analysis evaluates scope and processes to ensure that each provides value to the customer-----not to the lead architect, not to the CIO, but to the customer.
We Do Analysis
Most organizations do the analysis, as discussed within this text. The need is recognized to some extent. The challenge lies in recognizing the value of a business analysis professional. I often hear, “I am the project manager on my project and I do the business analysis work. Is this okay?” If you can effectively perform the tasks of the project manager and the business analysis to provide the team with what it needs for a successful project in a 40-hour workweek, then yes, this is okay.
The project manager will often possess some of the specific skills required for business analysis and may have some capacity for the work. It is rare to find a project manager who can answer yes to this question unless they, like me, are also trained in business analysis and the project is small enough to allow capacity for both.
I have worked on projects that were small and simple enough to play both roles, so it can work. However, I did find that there was an added challenge in this situation. I found my decisions leaned toward whatever discipline I had last been actively engaged in. In other words, if I had just been looking at the schedule and cost of the project, I leaned toward project recommendations that supported cost and schedule over business value. If I had last been working with stakeholders in eliciting requirements and understanding what they felt solution success would look like, I’d lean toward recommendations that provided more value to the solution without as much regard to project schedule and budget. A professional skilled in both business analysis and project management may fill both roles, and the only caution is that you continuously keep the overall solution and project in mind in your decisions and recommendations. Take the time and be willing to ask yourself the hard questions to make sure the overall project and solution it brings will provide the right value for the right cost.
This book will provide specific examples of how a business analysis professional can help your business see greater benefits from the projects selected and implemented. You may find that there are those in your organization that perform these tasks. An employee does not need to have the title of Business Analyst to be a business analysis professional. This book will help you recognize the roles and individuals, and provide information about how to mature and expand the use of the role for better results.
2Project Management Institute (PMI). www.pmi.org.
3PMBOK® Guide, 4th Edition, page 75.
4PMBOK® Guide, 5th Edition, page 69.
5Credential offered by IIBA. Credential holders have demonstrated 7,500 hours of experience in business analysis activities in addition to 21 hours of education, and have passed a rigorous exam proving expert knowledge in the area of business analysis.
6Smith, A. (2014). “Requirements Management: A Core Competency for Project and Program Success.” PMI’s Pulse of the Profession, 20-20. Retrieved from http://www.pmi.org/~/media/PDF/Knowledge Center/PMI-Pulse-Requirements-Management-In-Depth-Report.ashx, (October 5, 2014).
7Project Management Institute. (2015). Business Analysis for Practitioners: A Practice Guide. Newtown Square, PA: Project Management Institute.
8Rico, D., Sayani, H., & Sone, S. (2009). Future of agile methods (Chapter 24). In Business Value of Agile Software Methods: Maximizing ROI with Just-in-Time Processes and Documentation, p. 175. Fort Lauderdale, FL: J. Ross Publishing.
9http://project-pro.us/2012/04/14/agile_not_pm_framework/.
10Definition from the Lean Manufacturing Facilitator’s Glossary—http://tpslean.com/glossary/leanproductiondef.htm.
iJames, V., Rosenhead, R., and Taylor, P. (2013). Strategies for Project Sponsorship. Virginia, VA, Management Concepts Press.
iiManifesto for Agile Software Development—http://agilemanifesto.org/.