Maestro, please!


by Adrian Abramovici, PMP

A few months ago I took my 10-year-old to a Junior Concert given by the Toronto Symphony Orchestra. The theme of the day was the role of the conductor; the silent partner in what is, after all, a music-making effort. With many hilarious examples, the symphony showed the kids how quickly music can degenerate into plain noise without the key ingredients supplied by the maestro. And I just kept thinking: here is a project manager at work!

So let's explore the analogy and see what lessons we can learn from it.

Setting Up the Project Team

At the beginning of a project, I'd love to be able to “cherry pick” the staff and get the best people onto my team. Wouldn't you? Sure you would. But would cramming your project full of superstars really make your life easier? Probably not—and not just because you would become Enemy No. 1 on every other project manager's list. Would an orchestra built of superstar soloists ever work in the long run? No, probably it wouldn't; they would be at each other's throats clamoring for their interpretations to be heard. Same on the project: too many superstars would create factions, friction, and ultimately an unmanageable mess for the project manager. So what do we really do? We assemble a competent team, with good practitioners in all the “positions,” a few team leads, and go from there.

Empowering the Teams

Teams must be empowered to plan and perform their tasks from beginning to end. We should use the team, or the team leads, to develop most of the project task planning. Teams and individuals must be allocated clear tasks on the overall schedule and the funds to perform them, and then they should take ownership of these allocated tasks—just like an orchestra and its various sections and individual players.

Adrian Abramovici, PMP, is director of product assurance for MD Robotics (formerly Spar Aerospace) in Brampton, Ont., Canada, manufacturers of space robotic systems such as the Shuttle's Canadarm and the new robotic systems for the International Space Station. He has more than 17 years of project and program management experience at increasing levels of responsibility in the aeronautical and aerospace Industry.

The maestro assigns priorities and the rhythm of the work for each area, to ensure the total effort remains coordinated.

The project manager does not have time to dwell (much) on the implementation details, and should not, since it will come at the expense of managing the project. For example, in an engineering company, most project managers were once good engineers, and somewhere deep within they believe they still are, but now they must manage, and leave the detailed engineering to the new batch of engineers in charge. How many times do we see project managers attempt to dig in and “one up” the engineering team by “showing them how it's done”? That, of course, leads to some “interesting” project reviews which Mr. or Ms. Nitpick will sign off with glazed-over eyes on critical, risky decisions that fall outside his or her area of knowledge, just to come alive and dissect to death the poor soul presenting the area of the project in which the manager's background lies. In most cases we do not have all the details, all the inputs that led the team to recommend a certain solution, and unless we are willing to duplicate all their work from scratch before we buy in, we should learn to keep our involvement at a higher level.

This goes even further. Back to our analogy: I don't think we will often see the maestro pick up the violin to show the First Violin how to play. Most likely, the maestro does not even know how to play all the instruments that make up his orchestra, nor should he. Nor is the project manager an expert in all the fields from which he or she has drawn the team members and, of course, need not be. The project manager, like the maestro, is a leader who must understand and appreciate the work each individual or team must produce, as well as see and coordinate the way all these outputs merge into the overall project, or symphony, but not do the work for them.

I am not saying we should not question, probe, and use our accumulated experience in evaluating the team's inputs and solutions, but we should abstain from attempting to do their work for them. We must learn to delegate and trust the ones we delegate to—or replace them. If you need to question in depth and second guess every decision your team member, team lead, or manager has taken, it often goes beyond “the need to understand” and into lack of trust, and your staff feels it. In many cases they end up “managing the manager” instead of addressing the problems and managing the team to recover from the problems. Ask, “How can I help?” Lay off the inquisition, or else replace the individual you can't trust—if you feel you can't trust any of the inputs, check your birth certificate to see if your middle name is “Nitpick.” Each level in a project has duties; keep to them, don't try to work one level below the one you are supposed to.

Management Interaction. One cannot empower a team and at the same time nit-pick its activities, or question its decisions, or assign blame if decisions turn out not as well as expected. Institute a policy of “no surprises”; meaning that all team members undertake to immediately communicate any and all information to all interested parties, both in management and in the other potentially affected groups. The groups must be given considerable autonomy under the “no surprises” rule and within their allotted requirement, cost, and schedule boundaries. Management has to be kept aware and cognizant of things happening, but continuous management signoff on implementation decisions (within the constraints listed) should not be required.

Dealing With Failures. Failures must be dealt with under the “fertilizer happens” approach, as management and staff must accept the fact that errors will happen in a high-pressure project environment. Errors should be corrected, causes identified, and if need be, processes (or manpower and skills mix) adjusted to minimize potential recurrence of similar events…and life should move on. This approach greatly enhances the team spirit, the willingness of people to flag problems early and to contribute to problem solving in areas not necessarily their own.

OK, So What Does the Maestro Do?

The maestro leads. The maestro imbues the team with his or her vision of how the project (or symphony) should be performed, and motivates the team to perform it that way. The maestro coordinates the groups and individuals in their task performance. He or she decides how loud any instrument shall play (or what emphasis shall be placed on what project area). The maestro assigns priorities and the rhythm of the work for each area, to ensure the total effort remains coordinated. He or she ensures the deliverables are completed in time for the next group to continue the effort. The maestro improvises when that is required—he or she monitors the implementation, and intervenes and changes priorities, resources, or tasks to recover from problems.

The maestro decides when a soloist should enter and merge his talents with those of the team, and when he should stop. The maestro keeps the senior managers happy and assured of the symphony's success, and off the individual player's back. The maestro conducts reviews and rehearsals to ensure the proper flow of the project, and that it continuously meets the customer's expectation.

And, last but not least, the maestro communicates, and he or she facilitates communication. He or she communicates the goals and the vision, and elicits and incorporates suggestions as to how best to improve the execution or make it more efficient. The maestro listens, learns, and leads.

Maestro, please! img


Reader Service Number 184

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

March 2001 PM Network



Related Content