Archive for the 'policy' Category

Hold 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.

This is the third of five project e-Tips on ideas that are reshaping the delivery of projects. As you read through this consider whether you are systematically doing it or do you just know about it.

The Project Reformer's e-Tip of the Week

026: Optimize the Whole

AEC projects are contracted in ways that usually result in optimization at local or subcontract levels. Consulting engineers manage their work to maximixe engineering utilization. Plumbers do what is good for the plumbers. Other performers do the same. Some people say that if we do well with each of the parts, the whole will do well too. That is blatantly not true. And, people on the project know it. Sometimes it takes one group goins slow so that the project can proceed more effectively. However, the incentives are not set up to accomplish that. Optimizing the whole requires on-going attention. Circumstances change. What appears to be good for the whole at one point in the project may not be so at other points. It takes a recurring conversation and assessment among the many project participants to continue to act for the general well-being of the whole project. Try asking just one question at each of your coordination meetings: What is the best we can do for the project in the coming week? Answer the question in the group setting. Be open to adjust scope, fees, and plans accordingly. As the result, you'll do better for you client and the team. The Project Leaders' Studio™

©2004 Hal Macomber | RPM | e-Tip Archive | PDF | Submit Tip

Let me know what you learn while you try this out. And send me your proposals for an e-Tip. If I publish it, then I'll send you a Free Prize Inside!