Claudia M. Baca
Project-Management
Consultant
Engineers are problem solvers. They like to think outside, inside, above, and below the box. Problems are only riddles to be solved, puzzles to be . . . unpuzzled. Still, despite years of education and experience, many engineers, accustomed to working in their own narrow area, are not prepared for the next step — project management.
Project management can push normally competent, even brilliant, engineers out of their comfort zones. Supervising others, scheduling, planning, personnel issues, organizational politics — the list of areas in which project managers can find themselves immersed goes on and on. But one problem engineers-turned-managers have is a tendency to focus on the tasks they know. Most project- management jobs have both a technical and a management side. Sociologists who study management models have noted a common theme among teams headed by engineers: Team leaders with engineering backgrounds often focus on technical issues while giving management aspects short shrift. This tends to happen even if the main challenges reside on the managerial side.
Clearly there is a disconnect between the manager’s attention and the requirements of the job. One way for engineers to avoid such traps is to know the duties of a project manager.
So, what are the primary roles of the project manager? Though it may seem obvious, every project-manager’s duties involve communication. All communication with those outside the team should flow to and from the project manager. The manager communicates the work to be done and apprises sponsors, stakeholders, and customers of developments.
Trouble often comes because managers simply fail to communicate with some person or community involved with the project. This may stem from a failure to identify all interested parties. New project managers tend to underestimate how many departments and people need to be posted on developments. The exclusion of stakeholders can create enemies. And calamity can result when a concerned party is left out of the loop.
The project manager is also responsible for assessing risks and deciding how to accept, avoid, remove, or mitigate them. He or she must determine the best way to deliver results, often building “what if” scenarios to keep on schedule and within budget. This instills the work with rhythm and ensures smooth handoffs between parties. Managers coach team members, direct their performance, and conduct performance reviews.
On the whole, engineersturned- managers do a good job of assessing technical risks. Where problems are more likely to arise is in the assessment of personnel, economics, and scheduling. It is not a coincidence that management of risks in these areas can only take place collaboratively. The manager can’t come to meaningful conclusions about risks without cooperation. The danger for most managers lies in having a view of risks that is not expansive enough.
Perhaps the most important role of any project manager is that of leader. The project manager must motivate the team and build an environment conducive to success. He or she must establish goals and evoke images of what success looks like.
Many people make the mistake of confusing leadership with charisma. One need not have charisma to lead — though it helps! Much has been written about leadership and one point is clear: Clear thinking and good communication go farther than charisma.
Project managers who climb the organizational ladder may eventually become program managers, managing a group of related projects. A program manager oversees the efforts of several project managers.
It’s also important to understand the relationship of the project to the organization’s strategy. Project management is part of a larger network that management uses to deliver strategy. Organization executives formulate a strategy, which drives the formation of portfolios, programs, and finally, projects.
An organization builds a portfolio, which is made up of programs and projects, to achieve its goals. Managing a portfolio involves identifying, prioritizing, managing, and controlling programs, projects, and related work. Imagine a cell-phone maker wanting to become a leader in its field, so it builds a portfolio to that end. A program for enhancing cell phones could be assigned to Research and Development. The program might include several projects to build prototype phones.
The portfolio manager starts new projects and stops those involving a product or enhancement that’s no longer needed. But how does a manager decide which projects to start and which to stop? Perhaps it is best to answer this question by saying what the manager shouldn’t do: Let promising technologies be the main determinant of project viability.
In most areas, technological road maps shouldn’t dictate product strategy (high-tech areas such as semiconductor manufacturing aside). The more logical way to make life-or-death decisions about projects is to use market conditions as a guide. But that isn’t the whole answer. The solution gets back to corporate strategy: What do company managers mean when they say they want to “lead” the field? Often this goal isn’t stated explicitly. Defining what it really means keeps projects on track. Top management may desire technical superiority. Or it may not. It pays even the lowest-level project managers to find out.
A final note about overall strategy is that it determines the goals of the various projects. The problem is that these goals may be implicit rather than explicit. In other words, there may be unwritten understandings about the relative importance of specific values in the deliverables of a project. Novice project managers can find themselves doggedly pursuing an elusive result that isn’t even on the radar screen of upper management. This is not merely a misallocation of resources; for the manger, it can be a professional land mine.
Some companies establish a PMO — which can stand for a project- management office, programmanagement office, or portfoliomanagement office. PMOs may do some or all of the following: report on the status of projects, programs, and portfolios, create standards used throughout the hierarchy, act as a resource of experienced managers, and allocate resources across the entire portfolio.
Organizational structure
It’s not uncommon to find engineering organizations set up along functional lines, with departments for traditional disciplines such as manufacturing or design engineering. Over the last decade, however, a growing number of companies have applied a project-style work mode by means of matrix-management or concurrent-engineering teams. Matrix-management schemes typically assign engineers in a department to different projects, and often to multiple projects simultaneously.
The problem with matrix management from the project manager’s viewpoint is fairly obvious. Project team members may be working for multiple bosses. Moreover, project managers may have limited clout with the members of their team because the functional manager often has more say about raises and promotions.
Thus matrix management can put the project manager in a difficult situation. Though matrix schemes do have advantages — for example, they make it easy to move engineers with specialized talents — the difficulties they can impose on project managers have never entirely been solved. The degree to which matrix organizations function well is often determined by employee morale and attitudes rather than by factors in the organization chart.
Companies that superimpose concurrent-engineering teams over functional departments tend to avoid the problems that result from working on multiple projects. Concurrent-engineering teams are usually made up of a core group of engineers who are dedicated to following a project through to the end. Generally, the core group has no other project assignments to make demands on their time. This often means core members of the group wear more hats than in a matrix effort where specialists float in and out of the project.
Project managers running concurrent- engineering teams don’t have to deal with the same potential time conflicts as matrix managers. The difficulties these managers face often have more to do with the amount of authority they have over the employees on their team. As one might expect, project managers with substantial input in evaluations of team members tend to have fewer problems than those whose input is less strategic.
(For further insights on concurrent engineering, see “Lessons from the Best,” Machine Design, 12/10/98, p. 52. Machine Design also published a series of articles on concurrent engineering in the 1990s which still offers useful advice.)
There are all sorts of variations between functional and projectoriented organizations. Though it may sound obvious, project managers need to identify the kind of organization they are working for and get the authority they will need.
Of course politics is part of every project, no matter how a company is organized. A manager must be his or her own promoter. It’s important that he or she have clear ideas about the message conveyed both to team members and to those outside the team. In other words, control the message. In politics, the best defense is a good offense, and an effective manager starts by assuming the role of public-relations agent.
Risk management
Risk strategy is part of any project. Most companies have formal risk-management policies in place, at least for technical risks. If you don’t know your company’s tolerance for risks, find out. Are project leaders regularly asked to aim for stretch goals? Or are goals set so they can usually be met? Team members should understand risk-management strategy and how to quantify risks. The manager should spell out who is responsible for what, and know the likely timing of risks.
View risks from the perspectives of probability and impact. To determine probability, look at the project plan and schedule. Based on the current plan, assess the likelihood of the risk. It might be helpful to use a scale of 1 to 5 to quantify the probability of the risk. Examine the impact of a particular risk. First, imagine the risk happening. The typical approach is to categorize the impact as to its effect on performance, time, and cost. Again, a scale of 1 to 5 helps establish a value for the impact of each risk.
You’ll want to get a handle on potential risks as far in advance as possible. Brainstorming sessions are often used to expose potential problems. Consider bringing in a professional facilitator for these sessions. Studies show brainstorming sessions are more effective when run by professionals. Risk gathering can also be informal. At every team meeting, ask members what new risks they have identified and add their responses to a risk-identification list. Finally, formulate a response plan for the most critical risks.
Getting everything on the list and working through the process allays team members fears and helps you focus on what’s important — the project.
Claudia M. Baca is an independent project-management consultant and author of Project Management for Mere Mortals, published by Addison-Wesley.