In my last post, we saw the “disabling professions” establish a “one best way” in both traditional and agile project management. A different face of this problem is dealing with stakeholders who don’t recognise major parts of the orthodoxy.
In this post, I’m covering the inability of project management to deal with the “quick fix” syndrome, whether or not it’s valid for any project.
The “Quick Fix” Syndrome
If you’ve spent any time at all on projects in the average organisation, you’ll recognise these scenarios:
- “We should get “package XX” because I used it in a prior role and it was simple. ”
- “I don’t need analysis and design work. I know what we need, so build what I tell you. Everything else is a waste.”
- “The solution has to be in by the end of Q1, so we can impress everyone at our stockholder’s meeting. ”
- “A solution to fix ABC problem shouldn’t cost us more than $10k”
- “Gartner recommended it as a strategy”
Sometimes these statements might be correct. I’m sure there’s a kernel of something in most of them we can extract and turn into value. But, as stated, they turn out to be major oversimplifications that cause endless delivery problems.
A Project Selection Problem
When I was working in the project management team at large telco, our new Vice-president dropped by for a “meet and greet”. His briefing mentioned “problems with project delivery” several times. As first to put a question, I said:
“I know you’ve seen many projects with issues. But I don’t think we have a project delivery problem. We have a project selection problem. Many problems that surface in delivery are because of project selection or the up-front definition of the project.”
He stared at me for a while, and then, gruffly: “Nope, you’re wrong! They are project delivery problems and I’m going to fix them!”
I suppose that’s what you get when you challenge your senior manager on his first meeting.
But I know I was right: so many problems we see in project execution are actually problems arising from project selection and definition.
Why Does the “Quick Fix” Prevail?
Why do we have project selection and definition problems in the first place?
One reason is that it is common practice:
“… management literature sometimes seems obsessed with the tradition of proposing the optimal solutions, `the one best way’. Bookshelves are flooded with quick-fix `how to’ literature.”Richard Normann. Reframing Business: When the Map Changes the Landscape
Another reason is that getting things right up front is hard and risky.
It’s hard to understand the true business problem that you’re trying to solve and to frame it in value creation terms. It’s hard to consider the many impacts of organisations, teams, risk events and future unknowns in ways that are both realistic and appropriate (e.g. to budget and time expectations).
And it’s risky (to the key stakeholders in the up-front definition) to become attached to a failed option.
Without pointing fingers at any role or management type the early stages of projects are “idea-rich” in an environment which values ideas. Conceptual benefits are easy to describe and problems easy to avoid or dismiss. Short-cuts are easy to take in the mind: and are always successful.
Project Management Struggles in the Front-end
This is where project management runs into problems. Because it isn’t set up to address the “hard bits” at the “fuzzy front end”. It gets trapped in its own processes with an audience who is more likely to be process averse.
Project managers who work in this phase of a project find it hard to pin down specifics. They struggle to find adequate tools in their standard project management toolbox. Project managers “gross-up” their estimates to account for all real and projected costs. And we end up with a forecast cost greater than the sponsor wants to pay, or a duration far longer than the sponsor wants to wait.
Sponsors demand that project managers “prove” their assumptions. How do you prove that the potential risk events and outcomes will occur? Or that probabilities are correct (high). Or that task durations are accurate.
It’s a reversal of the burden of proof that PM’s find difficult to counter. There are few facts: only assumptions. Arguments like “it’s not best practice” or “it’s not following the standard practice” find little support.
And all this is without dragging out a specific process to propose to these stakeholders, e.g. a Value Management process.
Agile frequently has the opposite problem, especially poorly practised agile. Agile can inadvertently encourage quick-fix behaviour by its emphasis on verbal communication and abbreviated definitions. The ease with which an agile team can get to building product easily becomes just a fast start to a feature release plan.
What can we do?
There’s not much within our power to remove the tendency to “quick fix” mentality. But we can develop new skills and tools to deal with this better.
Forget the common toolsets. Harping on about compliance with process or best practice doesn’t help, no matter how true this may be. (it’s not always).
PM’s need to find new tools and practices that can help front-end stakeholders on their terms. Help them understand the implications of decisions and shape their front-end definition. The very first tool is to establish better relationships with front-end stakeholders. All else follows.
And PM’s need to play the long game: a “whole of project” game. Consider that your role isn’t as a PM in this early stage. Find another role that gives you a seat at the table now. Later, you can resume your real role as PM.
I’ll be writing about these in future posts.