I have met many project managers who approach their roles with dedication, thoughtfulness, and considerable diligence. The body of knowledge in the PM field is growing, aided by the efforts of such groups as the Project Management Institute. Rigorous certification programs are offered around the world, and many motivated people have pursued learning the Project Management Body of Knowledge (PMBOK).
Yet, in spite of all this effort, the evidence shows that we are not getting better at managing projects in our organizations.
Depending on the study you look at, between 37% and 68% of projects (in the IT field) are judged to be “failures” in that they did not meet expected outcomes (70% or lower completion of objectives), ran seriously over budget (by 160% or more), or blew past their timeline goals by a wide margin (180% or more). The data for ERP (Enterprise Resource Planning) and BI (Business Intelligence) projects is even worse.
So, what are we missing?
As you read through the analytical studies, a theme begins to emerge. One researcher ascribes the shortcomings to our inability to analyze the business problems we choose to solve. The IAG Consulting study referenced below explains the consequence in this way: “Companies with poor business analysis capability will have three times as many project failures as successes.”
The PM solutions report referenced below asserts that the leading causes of project failures have to do with:
- Resources: Lack of resources, resource conflicts, turnover of key resources, poor planning.
- Schedules: Too tight, unrealistic, overly optimistic.
- Planning: Based on insufficient data, missing items, insufficient details, poor estimates.
- Risks: Unidentified or assumed, not managed.
But like the IAG people they concluded that the NUMBER ONE cause of project failures is related to:
Requirements: Unclear, lack of agreement, lack of priority, contradictory, ambiguous, imprecise.
What makes matters worse is that even if the project is technically successful, too often it was just not worth the effort. Who cares if we meet the requirements and meet our timeline and budget if the outcome did not materially impact our business? Now if I reflect on my own personal experiences, I can recall numerous projects where we actually delivered on what our documented requirements were only to have the client (whether internal or external) say “well. . . thank you but this isn’t what I was imagining”, or “could you change it to do this or that instead”? Who among us hasn’t been to that movie? In fact I can recall a meeting with one of my past clients where we were discussing the question of requirements definition and the Senior VP of IT stood up and said to his people “if at the end the client is not happy, you just show them the requirements list!” Yikes! Really? Let’s rub their face in it? How did we degenerate into that kind of defensive action where the requirements list becomes little more than a “CYA” tool?
What was interesting to me about this example was that the executive I am describing was highly intelligent and worked for a well-regarded and quite sophisticated company. But he was operating in a political climate where other operating executives were criticizing his team for their lack of responsiveness and effectiveness. We are all a product of our organizational culture.
When you spoke to the project managers in that company, they, of course would describe how difficult it was to get clients to sit down and focus in a meaningful discussion about what they needed.
Why is this so hard?
I believe this is because we often ask the wrong questions. When you sit down and ask someone what they want, they often can’t tell you. If you show them some type of prototype, they can typically tell you what they like or dislike, but not everyone has a good imagination. We are limited in our ability to articulate requirements because of our limited life experiences and our knowledge of what might be possible technologically. It is hard for me to imagine something I have never seen or experienced. This is why focus groups have gone out of fashion, as market researchers across the planet look for better ways to understand their customers. The game is more about understanding what customers think and feel, instead of relying solely on what they say.
A BETTER line of questioning has nothing to do with requirements, but with what PROBLEMS I am trying to cope with as I conduct my job? Let your customer service people express:
“I don’t have the information to answer customer phone questions about delivery status”; or “I feel if I had access to information about our products and pricing, I think I could sell the caller on different products or services. Sometimes they order the wrong things”; or “we are way too slow in responding to requests for emergency service”. Then, let your inventive technical people try to imagine how they might help with those things. Once they have some ideas, they can share them with their client to test the viability. Speak to them within the context of THEIR world, not yours.
The Creative Problem Solving Process is one way I know to do a better job with the challenge of problem definition. It uses an 8-step sequence of actions. The orange section (steps 1-3) is all about understanding the problem(s) more deeply, and then choosing the most relevant ones to solve. The yellow section (steps 5 and 6) is about generating solution ideas and choosing the best ones. The green section (steps 6-8) is about execution planning.
The main (and often surprising) insight is that the first three steps (1-3) consume as much as 50-60% of the time in the process! The discovery part of this section does not come from an interrogation of clients to solicit a list of requirements, but from the art of empathetic observation. Here we are trying to go beneath the layer of superficial knowledge to gain a deeper insight into client emotions, biases, and motivations.
Too often we reject this notion because we allow ourselves to be trapped in a paradigm where we need to take immediate action, producing solutions – so that we are efficient. I’m all for efficiency, but efficiently solving the wrong problem is not helping anyone.
Sometimes it pays to slow down. Slower, often can be faster . . . and better.
Other Resources
Poor requirements definition is the number one reason for poor outcomes. (you can tell this article was written by a person with traditional PM training.) Why 37% of Projects Fail?
And another — which reinforces the issue that we aren’t solving the right problems (and are generally poor at defining requirements) Study: 68 percent of IT projects fail
And this one — argues that we haven’t improved at all in the last decade (in spite of the energy put into better PM skills) 62 percent of IT projects fail. Why?
Source Data from IAG Consulting, their Business Analysis Benchmark
Source Data from PM Solutions Study
A reasonable primer on “Why Do Projects Fail?: Learning How to Avoid Project Failure”
More details on the idea that sometimes slow is fast. Slowing Down to Move Fast, by Len Brzozowski
Innovation management vs. project management thinking, Design thinking: A new approach to fight complexity and failure
More on market and client intelligence gathering. Driving Innovative Strategy Through Empathetic Observation, by Len Brzozowski
lenbrzozowski
lenbrzozowski 