5 Myths that Can Ruin Project Management
Today’s post is by Mary Prescott of WorkZone.
Every industry has its myths, and project managers aren’t exempt. This is unfortunate for the industry, but if you can dodge the myths, you can pull ahead of the competition. Are you aware of these falsehoods? Or are you wasting resources and time as we speak?
It’s time to correct a few misconceptions.
1. The customer knows what they want
Whether you’re dealing with “customers” or “clients,” it’s a longstanding myth that the purchaser knows exactly what they want from you. But, it turns out, we humans are actually notoriously bad at predicting what we want and what we need.
When Guy Kawasaki gave a presentation shortly after Steve Jobs’ death, he decided to talk about twelve key lessons he learned from the giant of Apple. Lesson number 2 was that customers can’t tell you what they need. He went on to say, “The day that you hear that Apple’s using focus groups to decide on its future projects, that’s the day to short Apple stock.”
This applies to all industries, and it applies equally to the B2B sector.
It’s important to remember that the customer is not the expert. You are. That is your value.
When you’re speaking with your client or doing market research, focus on the “why” of the project. What are the goals? What problem are you trying to solve?
2. You need to win every battle
This myth starts with a faulty assumption. Good project managers don’t win “battles.” They identify faulty processes, and they fix them.
– When your ideas aren’t innovative, something is wrong with your creative process
– When workers break the rules or slack off, something is wrong with your incentives
– When projects fall behind schedule, something is wrong with your planning process
– When personalities are distracting or counterproductive, something is wrong with your hiring process
Project managers who put the blame on human beings, rather that processes, ultimately cultivate project teams that are cold, fragmented, and individualistic.
Nothing is more corrosive to collaboration than a culture of blame. Project managers who “fight battles” only damage morale and breed animosity.
3. Detail is key
The most detailed project charter is often the worst.
Let’s turn to an unlikely example of this: the Boeing 777.
At first, the Boeing 777 looks like a dramatic triumph of up-front design. The entire plane was designed from top to bottom, front to back, in a computer, long before a single part was made. It would seem like this is the nail in the coffin of the idea that the best projects start with simple guidelines.
A closer look reveals a very different story.
The Boeing 777 was, in some ways, the very antithesis of big design up front. Project goals and guidelines were only loosely defined by management. Boeing dramatically changed the way that its teams were organized. They opened up project planning.
Far from a closed process, the design was a participatory, iterative process. Procurement staff, engineers, manufacturing staff, suppliers, and customers were all involved. Communication both up and down the hierarchy was encouraged. Team members were encouraged to bring their concerns to management.
In short, the creation of the Boeing 777 can only be seen as “big design up front” if we imagine that the design process was handed down from on-high as an unquestionable document.
In reality, the design of the Boeing 777 is more appropriately seen as an iterative, open, involved project.
The lesson? Detailed plans aren’t necessarily bad, but they can only be as detailed as the expertise of the people involved in the planning process. The best project management styles focus on building collaborative teams and processes that can respond to changes and errors quickly.
4. You must sacrifice quality to meet deadlines
The best laid plans can fall apart, and when they do, resources are scarce. When this happens, we’re often told to believe that there are only three options:
– You can push the deadline further back
– You can spend more on resources
– You can reduce the quality of the end product
This is a false choice. I’m not denying that there are situations where tradeoffs are inevitable. I just don’t believe that the tradeoff should ever be between time/resources and quality. Instead, the tradeoff should be between time/resources and grade.
A good compact car isn’t lower in quality than a sports car. It’s a different grade.
What’s the difference? Quality is closely linked with error and inconsistency. You don’t want to release a product riddled with errors and inconsistencies. It’s far better to release a product with more limited features that still meets its core requirements very well.
When you have to make a sacrifice, and you’re not willing to sacrifice time or resources, sacrifice your product’s grade, not its quality.
5. You can’t stop a project once it starts
This is a huge mistake that should be avoided at all costs. There is absolutely nothing wrong with stopping a project after it starts if the effort is no longer worth the outcome.
This kind of behavior is tied to human nature. It’s called loss aversion. We’re hard-wired to take bigger risks to avoid a loss and smaller risks to win.
When management declares that they can’t stop a project once it’s started, they are usually suffering from this short-circuit of the human condition. They’re willing to take an unacceptable risk to avoid losing the resources that went into the project, even though they would never take the same risks to justify a new project.
The rule of thumb is fairly simple. Would you start this project today with the resources and environment that you have now?
It’s time for management to stop believing lies like these. Customers don’t always know what they want, it’s not worth sacrificing quality, the best plans are open, you can stop a project once it starts, and none of this has ever been about fighting battles.
Let’s take this knowledge and put it to use.
– Mary Prescott is a community manager at WorkZone – A web-based project management software company. She is @MaryPrescott on Twitter. When she’s not working, you’ll find her reading fiction or hiking with her dog.
Did you enjoy this post? If so, I highly encourage you to take about 30 seconds to become a regular subscriber to this blog. It’s free, fun, practical, and only a couple of emails a week (I promise!). SIGN UP HERE to get the thoughtLEADERS blog delivered to your inbox every week!
Good advice! I turned them around as dos rather than don’ts
1. The customers may know their needs but not how you can best solve them
2. You need to win the war, so avoid unecessary battles
3. The devil may be in the detail but the overall process is key
4. You must not sacrifice quality to meet deadlines
5. You can stop a project if it no longer makes sense to continue
This is definitely food for thought. As a public servant I believe quality is important and is a responsibility we have to the public. Too often because of deadlines, budgets, politics etc (at least that is the excuse of managers) we often sacrifice quality. Unfortunately this lack of quality ends up in court where it is remarkably noticed and we are sent back to square one. This happens way more often than one wants to recognize and is irresponsible to the public we serve. Thanks for the reminder that quality is important as I was just getting sucked into the vortex of sacrificing quality once again because of battle fatigue.
Very real advice! We have faced and experienced all of them at one time – especially 1 and 4.
Hi Mike,
Actually #4 is not a myth, you NEED to sacrifice quality to meet deadlines. Quality can be improved later on, but in many projects, you will have to meet the deadline. Release now, improve later.
It seems that there are too many myths out there to conquer! #2 (“You need to win every battle.”) definitely resonates with me. We at Wrike just debunked our own set of PM myths and said nearly the same thing: Projects failures are not fatal. If you’re interested to see our list of myths, here’s a link: http://www.wrike.com/blog/02/12/2014/Top-Five-Project-Management-Myths-Busted-NEW-INFOGRAPHIC