What makes a successful project? There are many objective measures (such as on time and on budget) and subjective options (e.g., customer satisfaction) to answer that question. As a generality, I think a project is successful when we apply an appropriate solution to a business problem, one that addresses the underlying cause. In short, we are successful when we address the “business need.”
We all know it is easy to jump to solutions or to fix just the symptoms of a problem. We are all guilty of it and is so common it has a name: “jumping to solutions.” When we do this, we often fail to get to or seemingly even want to get to the root cause of a problem.
As an example, let me paraphrase a classic story of solution jumping vs. getting to the root cause. The Jefferson Memorial in Washington DC had a problem a few years back with large amounts of paint chipping off. It required repainting every six months to a year, far more frequently than it should have needed.
If you know this story, then you know it was not poor-quality paint or shoddy workmanship that caused the need for frequent re-paintings. It was because of bugs! Near dusk when they turned the lights on this beautiful monument, a certain type of bug came out. Not a bug, but hordes of them! With so many bugs, the birds in the area swooped in to eat them and then left bird droppings as a souvenir after their insect feasts. The root cause of the problem was bird dung from bugs that caused frequent power washing to clean it, that then wore away the paint that caused the need for frequent re-painting.
To make a long story short, once the U.S. Interior Department got to the root cause, they found that turning on the lights a little bit later fooled the bugs. Far fewer of them swarmed around which in turn reduced the bird droppings and the solution drastically reduced the power washing and repainting needed.
This series of articles will explore how to understand business needs using five common and proven root cause analysis techniques. By finding root causes we can truly understand business needs and not rely on what our business stakeholders tell us their needs are. It is a repeatable way to provide appropriate, cost-effective, and lasting solutions like they finally did for the Jefferson Memorial. Part 1 will focus on what are business needs.
What are Needs?
So, what are needs? I do not mean psychological needs like in Maslow’s hierarchy. I am also not differentiating between needs vs. wants so that if I say I need a new pair of shoes, I do not literally mean I am currently shoeless. What I essentially mean is “I really want a new pair and I’m willing to pay for them.” And that is what any project or program requires – a sponsor willing and able to pay for something new.
When considering “business needs,” what do sponsors pay for? Too often it is a predefined solution. I am sure many of you have experienced a sponsor bringing you a solution. In that case the project or program’s objective is to implement the predefined solution with business needs either previously explored, assumed, or possibly overlooked.
I frequently hear people tell me they are brought into projects after the solution has been chosen – seemingly too late for any needs assessment or root cause analysis. I often respond: “It is never too late!” You can always help forestall project disasters if you are diligent about wanting to get to root causes and actual business needs.
Business needs have many facets including:
- They represent business problems
- They represent business limitations
- They reduce the chance of “solution jumping”
- They lead us to requirements and designs
- They justify projects
Why are needs so important?
Figure 1: From Needs to Solutions
Anything a project team creates “should” stem from needs. Needs are at the heart of what we do, and they tie back to business problems or opportunities. They lead us to the requirements and are also the basis for designs, both “logical” or physical designs. Designs are turned into constructed things such as solution components, which in my experience has been software, but could be any constructed deliverable. Finally, all the components add up to one or more solutions.
You may intuitively know this but having a visual helps me to see the relationships and the importance of getting needs right. If we fail to understand needs, we risk delivering solutions that will not address underlying business problems and the resulting solutions will have decreased value and may even be scrapped.
What do IIBA and PMI-have to say about Needs?
The BABOK Guide v3 from IIBA (International Institute of Business Analysis) defines needs as “A problem or opportunity to be addressed.”
Looking further into the BABOK Guide, it literally starts with Needs as the core input when planning the BA approach. It is the very first task in the Guide. I realize the tasks are not intended as sequential items, but the placement is hard to ignore.
Figure 2: Needs in BABOK Guide v3
Needs are also the primary input when eliciting requirements, which leads to virtually every other task in the BABOK Guide.
The first Domain in The PMI Guide to Business Analysis (from Project Management Institute) is Needs Assessment. The Business Need for a project or program in that standard is defined during the “Assess Current State” task along with a current state assessment. It is also the entire first chapter in the PMI publication Business Analysis for Practitioners: A Practice Guide.
Figure 3: Needs in PMI Guide to Business Analysis
Needs are formally defined in PMI’s BA Standard as “…the impetus for a change in an organization, based on an existing problem or opportunity.“ It is entirely consistent with the IIBA definition and both standards remind us why root cause analysis techniques are so important for clarifying business needs before analyzing and defining solutions.
In the next article of this series, look for descriptions of five common and useful techniques for root cause analysis, and by extension, business needs.
A Guide to the Business Analysis Body of Knowledge (BABOK® Guide) v3 from International Institute of Business Analysis, published 2015.
Business Analysis for Practitioners: A Practice Guide from Project Management Institute, published 2015
The PMI® Guide to Business Analysis from Project Management Institute, published 2017