The Truth about Common Project Management Misconceptions
July 12th, 2004 by HalHold onto to your hats! Mark Zweig, as usual, freely speaks his views. He just did so in a webcast on project performance for AE firms. Brian Driscoll offered some highlights of the webcast in this today's ZweigLetter. I'll recap the "misconception", Mark's view, and then offer my commentary.
The firm's performance is the sum of its project performance.
I (Mark) say that's wrong. You might be making money on every job, but if you're not doing enough of them, you can go broke. (W)hen firms find out what their real overhead is, they find that they're not doing enough.
Mark makes the case for company management practices that are more encompassing than a simple roll-up of project performance. "Of course!" you might say. But my experience with particularly the small and medium size AE firms is they are missing the tools to take the whole-company view.
Firms should have minimum (profitability) standards for what jobs they can take on.
It's naive to think you can just not do work of certain sizes for good clients. Look at the totality of the relationship and how well you do across all of the client's work.
I've been on both sides of this one. I've proposed minimum standards for taking on construction work. I've also argued that any margin is good margin. Mark proposes that we look at the whole of our relationship with a client to evaluate profitability. And I'll add, do that on a regular basis.
It's the job of the project manager to tell everyone what the budget, scope, deadlines, and so on are.
I (Mark) say that is wrong. The project manager's responsibility is to make sure information is available to everyone, but firms need to place the onus on the individuals to seek the information out.
Knowing budget and schedule are important. Very important. And both change on most projects. The one person who knows about those changes is the project manager. Just updating some system, as good as it may be, doesn't guarantee that team members will learn about it in a timely way. Yes we want people on our teams who are inquiring. But don't leave it to chance that team members will learn what you need them to learn. Cultivate people who are responsible to find out what is going on AND hold your project managers accountable for wide open and timely communications among the team.
The reductionist deterministic behavioral approach is bankrupt. And therefore all the training that is based on it doesn't improve performance.
Project managers should be the front-line bill collectors for firms.
I really disagree with this one. It's not the best use of their talent. Some will do it, but the majority of them won't do a very good job.
Yes, it is tough. And late payment can be associated with dissatisfaction. There's no better way I know than to ask directly, "Is there something that you are dissatisfied with?" When the answer is "No," you can then make a request for your client to step in to see that you are paid on time. If the answer is "Yes," then you have the opportunity in that moment to address the dissatisfaction following which you can ask to be paid.
Project management training will improve performance.
I (Mark) don't know where the data is that supports this conclusion because I sure as heck haven't seen it. I see a lot of bad training out there that makes absolutely no difference in how project managers do their jobs. I'm not saying all project management training is a waste of money, but I will say that a lot of it is.
I agree with Mark. While Mark doesn't say why some project management training is a waste, I will. Much of the project management training that we see today conforms to conventional wisdom. The prevailing wisdom is motivationist and controlling. Computer systems of course conform to the conventional wisdom, else they wouldn't be selling. The reductionist deterministic behavioral approach is bankrupt. And therefore all the training that is based on it doesn't improve performance. If you're interested in some training that will work, then look towards Scrum and lean project delivery. The Scrum approach was designed for software development. The lean approach has been used successfully for a variety of AEC projects. Both will work for AE projects.
So, the folks at ZweigWhite want to know, "Does conventional wisdom work for you?" Leave you comments on this weblog or write Brian Driscoll.
Related Posts
- David Schmaltz Does It Again So you're asking who is David Schmaltz and what has he done? David is the author of the book The Blind Men and the Elep...
- Did the WSJ Get It Wrong about Lean and Taylor? Mark Graban thinks so. His impassioned editorial at the Lean Blog is a must read. Mark takes on the common sense of ...
- Why Projects Fail Software plans often lack common sense (and a) user focuseWeek reports the FBI is likely to scrap their $170 million V...
- Our Common Sense Betrays Us We can't see what we can't see. I've been in a number of project conversations recently that raise the issue that suc...
- Point Your Finger at Lean Six Sigma There's a new kid (blog) on the block. He calls himself the Lean Six Sigma Academy, a.k.a. Ron Pereira. He's not afr...










