As a project manager, I'm saddened to see that project management and project managers are getting a bad rap from both ends of the spectrum. Business tends not to see the value in them, and developers tend to believe their own "creativity" is being stymied by them.
Recently, I read the article titled "Project management: A surefire way to kill your software product," by Stephen Lowe, on TechBeacon. The article received many supportive comments for its criticizism of project managers and the practice of project management itself.
Let's set the record straight: Project management is a prized methodology for delivering on leadership's expectations. The success of the methodology depends on the quality of the specific project manager. And the good ones are hard-pressed to overcome the failings of those who have come before.
Here was Lowe's main argument: "Project management emphasizes things that do not matter—estimates, time, conformance, ceremonies, and all of that—while ignoring the things that do matter: value generation, user satisfaction, group learning, team dynamics, root causes, information gaps, business insights, and innovation."
But project management is not broken. Here's what good project management looks like, what makes a good project manager, and the myriad ways you can prevent the grim picture that Lowe paints.
Bad requirements are one problem
Project management is more of an art than a science. It takes personality, empathy, persuasiveness, tact, a little Jedi mind power, and a bit of the Oprah effect. A good project manager needs not only to be able to calculate the burn rate and create amazing project plans, but also to be an artful diplomat, stellar communicator, creative writer, and exceptional herder of cats. All of which cannot be gauged by answering a multiple-choice question.
It's clear that Lowe is upset because he has seen projects that didn't meet customer expectations, and he has probably worked with bad project managers as well. But here's where his logic is flawed: A project can only be as valuable as the requirements. If the user stories and requirements are bad, of course you are going to produce a product that's not valuable.
How is that the project manager's fault?
The business, for whatever reason, either failed to capture and identify meaningful requirements that added value or really didn't know the meaning of business value. Moreover, it sounds from Lowe's musings as if he's been on bad projects that had ineffective business sponsors, and that they used the wrong methodology.
Using the wrong methodology is another
A few questions:
What methodology does the organization use to deliver projects—waterfall or agile?
Is the right product owner engaged? Does she or he really know the product—is the product owner identifying and bringing forward value?
Adopting a new capability requires a plan that spans people, processes, and technology. An organization can't have success adopting new capabilities—especially if it is an enterprise with multiple, distributed stakeholders—without taking into consideration all three aspects.
If the organization has not embraced delivering in an agile way, that failure should not be attributed to the project manager or project management itself. Sometimes it can be tricky to choose the right agile framework or technique for your project. But when the right choice is made, with the right project manager, project management runs smoothly.
The "delusions" of project managers
From Lowe’s article:
"Project managers add unnecessary complexity and friction and invite a counterproductive temptation to focus on the box [project plans] instead of the problem or product. This misplaced emphasis leads to some harmful delusions: Conformance to a schedule is not the same thing as success.”
So this is the first item on a list of seven “delusions” that project managers supposedly have because we focus too much on the plan and not the results, right?
This first bullet makes me wonder where I can find these companies that don’t use metrics like revenue to determine success, but instead check to see if a project manager’s plan was followed perfectly.
Results matter above all else, but a team still needs to hit the target date of a product launch or deadline to keep revenue streams flowing and stay out of a development quagmire. Lowe seems to believe that developers are here to just develop in their little bubble, unmanaged, with no end in sight.
Another one of the “delusions” that Lowe says project managers have:
“Estimation accuracy is possible and desirable enough to measure and optimize for.”
What? So estimation accuracy is impossible and undesirable? Not in my experience, and not in the experience of many others in the software industry.
Consistently perfect estimation is certainly rare, but consistently accurate estimation is absolutely achievable. Project management is more of an art than science. Yes, it’s great to estimate points and monitor burn, but if you don’t end up with a valuable minimum viable product what’s the point?
Here's the next “delusion” on the list:
“The plan is perfect and guarantees success.”
A good project manager knows that there are NO guarantees in life except death and taxes. There are always going to be events that negatively impact a plan, so it’s a pretty weak argument against project management to say there will never be a “perfect” plan, so therefore, let’s criticize planning. A true project manager knows that success means getting a solution to a problem or developing a functional, valuable product by the target date.
Continuing with more of Lowe’s “delusions” of project managers:
The cost of forming and dissolving teams is zero.
The cost of functional silo hand-offs is zero.
I, and other project managers, definitely don’t assume this.
This one really bothers me:
“The bigger and more comprehensive the plan the better.”
Managers are not measured by the size of their plan. They are measured by being able to manage a team through the ups and downs of teaming, address and resolve issues, clear obstacles, document and manage issues and risks, and a whole host of other meaningful and productive attributes and skills.
What’s the use of having a “big and comprehensive” plan if you do not have the correct skills and emotional intelligence to manage it? No halfway-decent project manager would feel they have to bulk up the size and complexity of their plan just to look good for upper management.
And here’s the last “delusion” on Lowe's list:
“Predictability and efficiency are paramount.”
Predictability and efficiency are not paramount—the product is! As you can tell by now, a lot of these bullets aren’t incorrect statements by themselves. It’s just not true that decent project managers actually believe any of these things.
But wait, there’s more!
“Traditional project management attempts to optimize for predictability, for ‘efficiency.’”
No, my young padawan. Project management and project managers do not attempt to optimize for predictability and efficiency. Let me tell you why.
A good project manager will not manage solely to get to a predictable state. A good project manager knows that managing a team is not like driving your trusty old Buick. They know that a team is not a car—you just don’t put the key in the ignition and go. There are other important aspects to managing a team that I’ve described above and none of those boil down to predictability and efficiency.
What a good project manager does
Project management only works when a good project manager applies the correct methodology and has the right attributes that include emotional intelligence, empathy, and battle-tested management skills. It also requires sound, adaptable business requirements. Good project managers are not backseat drivers or micro-managers, and it's completely unrealistic and naïve to expect them to just let the development team go off and play. There is a need for planning, reporting, and budgeting.
Deadlines exist for a reason. Businesses want to launch a product or functionality by a certain date for a reason. Project teams are not meant to develop in perpetuity. But Lowe seems to dismiss the time-tested concepts of estimates and deadlines. Yes, I am all for people learning and being creative, but there's a limit (budget) and a point at which you're just sawing the sawdust.
If the project is being managed correctly by the project manager/scrum master, that euphoric state that developers want to get to can be achieved, along with the project objectives—all within the prescribed budget and timeline.
Denouncing an entire practice based on what appears to be a limited, misaligned application of the correct methodology does not make all of project management and all project managers bad.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
