RSP&&A;; Web Site: Commentary

Fear of Trying: The Plight of the Rookie Project Manager

A version of this commentary will be published in IEEE Software in early 1998.

A front-page article in The Wall Street Journal (April 4, 1997) noted that "... many [technical] people don't want to be managers, and many people who are managers are, frankly, itching to jump off the management track - or already have." Describing a phenomenon that it called "management phobia", the Journal noted that sentiment against moving into management positions is the highest it has been in over two decades. The article profiled young technologists, who in another era would have gladly moved toward project management, but today are shunning such positions. Most cited the "Dilbert Factor" as their primary reason for staying put.

As a software engineering consultant, I've noticed this phenomenon among the ranks of software engineers in companies large and small. Most don't want the hassle of project management, feel ill-prepared (and often are) to take on the responsibility, and abhor the politics and frustrations that are endemic in the position.

And yet, few senior managers would argue with the notion that "poor project management" is the number one cause of project failure. We need good project managers, but it seems that the best and the brightest practitioners have a fear of trying the project management route. What to do?

There are hundreds of books and training courses and dozens of management theories that address software project management. Each discusses the techniques and tools that lead to a successful project and the attributes that are exhibited by successful project managers. After more than 20 years of consulting with software development organizations in companies large and small, I've come to believe that successful projects have much more to do with the person leading the team than they do with project management techniques and tools.

So, how do we grow a good project manager? What do we teach the rookie who has just been appointed to lead her first software project?

Regardless of the approach that you use, I would focus on four major attributes, listed in order of importance.
Communication

Here's the scene. A young project manager is called in front of an product steering committee (made up of senior executives) to report on the status of a critical project that is in trouble. He begins by looking at his shoes, unfolding a sheet of rumpled paper, fidgeting nervously, and then, without preamble, saying: "We've run into a roadblock in module TCP/IP xcon. The status bit that should be set by module, uh, I forget it's name, anyway, its a real-time control module in the network management architecture, has uh, given us a bit of a problem because, well, we thought that the requirements were consistent with ... ." I suspect you've been there.

Project managers need to understand how to communicate, and more important, how to tune their communication to the audience that is listening. It doesn't matter whether the communication is a presentation, a written report, or a phone call. It must be structured in a way that will get the message across in a clear and concise manner.

Some people have a natural instinct for communication, but most do not. The rookie manager must be trained to express the same idea to different constituencies in different ways. She must understand the needs of her audience and craft the communication to meet those needs. On a given day, she may have to deliver the same message to executives, technologists, customers and/or end-users. The overall thrust of the communication may be the same, but the tone and structure will be radically different for each constituency.

Can this be taught? The answer is yes. Can it be learned on the job? The only reasonable answer is, "That depends." If the rookie manager has a competent mentor who is willing to spend the time to critique and instruct all communication to all constituencies, learning can occur on the job. But if the rookie is thrown into a project and expected to "understand" how to communicate with little or no training or help, problems will result immediately.
Negotiation

Rob Thomsett, a well-known and widely respected consultant in the software project management area, talks about "first, second and third wave" project management. In the first wave (1960s and 1970s) software people had all the power and were the one who dictated delivery dates and costs to end users and customers. During the second wave (1980s), there was (at least in principle) a more balanced power relationship, business people worked with software people to derive requirements and mutually set deadlines and costs. Now we're in the third wave, and the balance of power has shifted to end-users and customers. This means that they - not software developers - dictate the rules of the game. It also means that the rookie project manager had better learn to negotiate, with his customers, with the technologists on his team, and with the business executives who oversee his work.

There are, of course, many different ways to negotiate, but all can be summarized in five steps that every rookie project manager must learn:

1. A dialogue between two parties must be established. Since the software project manager is no longer in a position of power (as she was during the first wave), it is critical that she apply the communication skills that we discussed earlier. She must probe, offer ideas and suggestions, build on the client's ideas and suggestions and constructively criticize requirements that will lead to trouble. Since the power is on the other side of the table (whether software people like it or not), the project manager must work to make the customer understand that successful software will magnify the customer's power, and that the only way success can be obtained is through a close working relationship.

2. A negotiating strategy must be plotted. A rookie project manager probably believes that quick thinking during discussions with end-users and customers is the key to successful negotiation. In reality, the most important thing for a rookie to do is to plan a negotiation strategy in advance, before any attempt is made to overcome obstacles and come to terms. In essence, the following questions must be answered: What will be negotiated? Who are the players? When and where will the meeting take place? Once answers to these questions are obtained, the software project manager can better analyze his position, better organize the information he'll need to conduct a successful negotiation, and better assess alternative solutions and positions that may come up during discussions. The vast majority of rookie managers walk into a customer meeting ill-prepared. They often get steam-rollered as a result.

3. Obstacles to success must first be identified and then overcome. A rookie project manager and an end-user are discussing requirements and delivery dates for a major enhancement to a legacy system. The reach an impasse (e.g., an impossible deadline or a set of requirements that cannot be implemented within existing budgetary constraints) that seems impossible to break. What should the rookie manager do? One approach is to state a firm desire to continue discussions and then initiate a change of pace. Something like, "I think we've made some good progress [Mr. Customer] and I want to continue so that we can finalize things and begin this project. Why don't we take a break and then get back together, at, let say 3:00?" Of course things may not be that simple. The customer may be confrontational or even irrational. There are ways to handle these behaviors as well, but only if you've had some training in negotiation.

4. The parties must come to terms. The rookie manager must now carry out the actual negotiation. To do this he should open with a statement of purpose (why the parties have gotten together) and a review of the information (already known to both parties) that is the substance of the negotiation. The rookie manager must recognize that both parties have needs and these can be fulfilled in a number of different way. Together he must work with the client to arrive at the best alternative. Finally, the software project manager must "close." That is, he must summarize the agreement and identify the responsibilities of both parties and the steps that follow.

5. The parties must make it happen. Using the organization and facilitation skills noted below, the software project manager begins the technical aspects of the project, but never forgets that communication and negotiation are ongoing activities.

The vast majority of rookie software project managers have never had any formal training in negotiation. In fact, few have even read a book on the subject. They do not know the steps discussed above and do not apply them when they meet with end-users and customers. The result: misunderstandings, insane deadlines, unclear requirements, and a feeling of tension and frustration that leads to management phobia.
Organization

It is true that many people bumble their way through life, often just one wrong move from chaos. Amazingly, this approach to existence can work, but not for a rookie (or an experienced) software project manager. The manager must administer technical work, coordinate the people who do the work, and track and control the resulting work products. All of these tasks require organization.

Organization is a partitioning process. The rookie software project manager must know how to partition the work to be accomplished. Both product functionality and tasks associated with the software process must be partitioned and then related one one another.

She must be able to partition the manner in which she interacts with project team members. It is difficult to take on the role of advisor, confessor, therapist, parent, cheerleader, and yes, disciplinarian, all at the same time. In fact, an attempt to do all of this at once will invariably lead to chaos. Before entering into a meeting, a review or a one-to-one conference, the manage should consider which role(s) are most important for the given situation.

Finally, the project manager must be able to understand what elements of the work require immediate attention and which can proceed without oversight. On large projects, it is difficult and inadvisable to track and control all work tasks with equal emphasis. By partitioning work tasks and their relative importance to project goals, the project manager prioritizes - a key to keeping the project on schedule.
Facilitation

In addition to being a communicator, a negotiator, and an organizer, a software project manager should also be a facilitator. Stated simply, the role of the project manager should be to make things easy for the people who are doing technical work. In her role as a facilitator, the project manager acts as a buffer between the "techies" on the project team and those who fund, track and control the project.

As leader of the project team, the project manager should shield practitioners from the time consuming burdens of everyday corporate bureaucracy. In software design jargon, the manager applies 'information hiding,' treating the team as an encapsulated object in which data and the functions that manipulate that data are (to some extent at least) hidden from the outside world. The manager serves as the team's interface. Communication with team members are filtered (not to keep team members in the dark, but to filter out unnecessary distractions and time-consuming communication that has little or nothing to do with project success). Bureaucratic record keeping duties and reporting functions should be minimized to allow team members maximum time for productive work. Meetings should be structured for effectiveness. The project manager must set an agenda in advance, demand advance preparation (when required), ensure that records are kept and that action items are identified.
Bottom Line

The rookie software project manager should be given the opportunity to succeed. Ideally, he should be trained in advance and provided with necessary tools and resources that help get the management job done. But this is the real world. In far too many cases, the rookie is thrown into a project with little training and fewer resources. When that happens, things can be difficult - for the rookie, for the project team, and for the project. But even in this less-than-ideal situation, a manager can survive if she remembers four key concepts: communication, negotiation, organization, and facilitation. All the rest is detail.

Home About us Products Product Models SE Resources Commentary Contact us
Web site and all contents © 2006, R.S. Pressman & Associates, Inc.
All rights reserved.

Free website templates


	*Fear of Trying: The Plight of the Rookie Project Manager* A version of this commentary will be published in IEEE Software* in early 1998.* A front-page article in The Wall Street Journal (April 4, 1997) noted that "... many [technical] people don't want to be managers, and many people who are managers are, frankly, itching to jump off the management track - or already have." Describing a phenomenon that it called "management phobia", the Journal noted that sentiment against moving into management positions is the highest it has been in over two decades. The article profiled young technologists, who in another era would have gladly moved toward project management, but today are shunning such positions. Most cited the "Dilbert Factor" as their primary reason for staying put. As a software engineering consultant, I've noticed this phenomenon among the ranks of software engineers in companies large and small. Most don't want the hassle of project management, feel ill-prepared (and often are) to take on the responsibility, and abhor the politics and frustrations that are endemic in the position. And yet, few senior managers would argue with the notion that "poor project management" is the number one cause of project failure. We need good project managers, but it seems that the best and the brightest practitioners have a fear of trying the project management route. What to do? There are hundreds of books and training courses and dozens of management theories that address software project management. Each discusses the techniques and tools that lead to a successful project and the attributes that are exhibited by successful project managers. After more than 20 years of consulting with software development organizations in companies large and small, I've come to believe that successful projects have much more to do with the person leading the team than they do with project management techniques and tools. So, how do we grow a good project manager? What do we teach the rookie who has just been appointed to lead her first software project? Regardless of the approach that you use, I would focus on four major attributes, listed in order of importance. Communication Here's the scene. A young project manager is called in front of an product steering committee (made up of senior executives) to report on the status of a critical project that is in trouble. He begins by looking at his shoes, unfolding a sheet of rumpled paper, fidgeting nervously, and then, without preamble, saying: "We've run into a roadblock in module TCP/IP xcon. The status bit that should be set by module, uh, I forget it's name, anyway, its a real-time control module in the network management architecture, has uh, given us a bit of a problem because, well, we thought that the requirements were consistent with ... ." I suspect you've been there. Project managers need to understand how to communicate, and more important, how to tune their communication to the audience that is listening. It doesn't matter whether the communication is a presentation, a written report, or a phone call. It must be structured in a way that will get the message across in a clear and concise manner. Some people have a natural instinct for communication, but most do not. The rookie manager must be trained to express the same idea to different constituencies in different ways. She must understand the needs of her audience and craft the communication to meet those needs. On a given day, she may have to deliver the same message to executives, technologists, customers and/or end-users. The overall thrust of the communication may be the same, but the tone and structure will be radically different for each constituency. Can this be taught? The answer is yes. Can it be learned on the job? The only reasonable answer is, "That depends." If the rookie manager has a competent mentor who is willing to spend the time to critique and instruct all communication to all constituencies, learning can occur on the job. But if the rookie is thrown into a project and expected to "understand" how to communicate with little or no training or help, problems will result immediately. Negotiation Rob Thomsett, a well-known and widely respected consultant in the software project management area, talks about "first, second and third wave" project management. In the first wave (1960s and 1970s) software people had all the power and were the one who dictated delivery dates and costs to end users and customers. During the second wave (1980s), there was (at least in principle) a more balanced power relationship, business people worked with software people to derive requirements and mutually set deadlines and costs. Now we're in the third wave, and the balance of power has shifted to end-users and customers. This means that they - not software developers - dictate the rules of the game. It also means that the rookie project manager had better learn to negotiate, with his customers, with the technologists on his team, and with the business executives who oversee his work. There are, of course, many different ways to negotiate, but all can be summarized in five steps that every rookie project manager must learn: 1. A dialogue between two parties must be established. Since the software project manager is no longer in a position of power (as she was during the first wave), it is critical that she apply the communication skills that we discussed earlier. She must probe, offer ideas and suggestions, build on the client's ideas and suggestions and constructively criticize requirements that will lead to trouble. Since the power is on the other side of the table (whether software people like it or not), the project manager must work to make the customer understand that successful software will magnify the customer's power, and that the only way success can be obtained is through a close working relationship. 2. A negotiating strategy must be plotted. A rookie project manager probably believes that quick thinking during discussions with end-users and customers is the key to successful negotiation. In reality, the most important thing for a rookie to do is to plan a negotiation strategy in advance, before any attempt is made to overcome obstacles and come to terms. In essence, the following questions must be answered: What will be negotiated? Who are the players? When and where will the meeting take place? Once answers to these questions are obtained, the software project manager can better analyze his position, better organize the information he'll need to conduct a successful negotiation, and better assess alternative solutions and positions that may come up during discussions. The vast majority of rookie managers walk into a customer meeting ill-prepared. They often get steam-rollered as a result. 3. Obstacles to success must first be identified and then overcome. A rookie project manager and an end-user are discussing requirements and delivery dates for a major enhancement to a legacy system. The reach an impasse (e.g., an impossible deadline or a set of requirements that cannot be implemented within existing budgetary constraints) that seems impossible to break. What should the rookie manager do? One approach is to state a firm desire to continue discussions and then initiate a change of pace. Something like, "I think we've made some good progress [Mr. Customer] and I want to continue so that we can finalize things and begin this project. Why don't we take a break and then get back together, at, let say 3:00?" Of course things may not be that simple. The customer may be confrontational or even irrational. There are ways to handle these behaviors as well, but only if you've had some training in negotiation. 4. The parties must come to terms. The rookie manager must now carry out the actual negotiation. To do this he should open with a statement of purpose (why the parties have gotten together) and a review of the information (already known to both parties) that is the substance of the negotiation. The rookie manager must recognize that both parties have needs and these can be fulfilled in a number of different way. Together he must work with the client to arrive at the best alternative. Finally, the software project manager must "close." That is, he must summarize the agreement and identify the responsibilities of both parties and the steps that follow. 5. The parties must make it happen. Using the organization and facilitation skills noted below, the software project manager begins the technical aspects of the project, but never forgets that communication and negotiation are ongoing activities. The vast majority of rookie software project managers have never had any formal training in negotiation. In fact, few have even read a book on the subject. They do not know the steps discussed above and do not apply them when they meet with end-users and customers. The result: misunderstandings, insane deadlines, unclear requirements, and a feeling of tension and frustration that leads to management phobia. Organization It is true that many people bumble their way through life, often just one wrong move from chaos. Amazingly, this approach to existence can work, but not for a rookie (or an experienced) software project manager. The manager must administer technical work, coordinate the people who do the work, and track and control the resulting work products. All of these tasks require organization. Organization is a partitioning process. The rookie software project manager must know how to partition the work to be accomplished. Both product functionality and tasks associated with the software process must be partitioned and then related one one another. She must be able to partition the manner in which she interacts with project team members. It is difficult to take on the role of advisor, confessor, therapist, parent, cheerleader, and yes, disciplinarian, all at the same time. In fact, an attempt to do all of this at once will invariably lead to chaos. Before entering into a meeting, a review or a one-to-one conference, the manage should consider which role(s) are most important for the given situation. Finally, the project manager must be able to understand what elements of the work require immediate attention and which can proceed without oversight. On large projects, it is difficult and inadvisable to track and control all work tasks with equal emphasis. By partitioning work tasks and their relative importance to project goals, the project manager prioritizes - a key to keeping the project on schedule. Facilitation In addition to being a communicator, a negotiator, and an organizer, a software project manager should also be a facilitator. Stated simply, the role of the project manager should be to make things easy for the people who are doing technical work. In her role as a facilitator, the project manager acts as a buffer between the "techies" on the project team and those who fund, track and control the project. As leader of the project team, the project manager should shield practitioners from the time consuming burdens of everyday corporate bureaucracy. In software design jargon, the manager applies 'information hiding,' treating the team as an encapsulated object in which data and the functions that manipulate that data are (to some extent at least) hidden from the outside world. The manager serves as the team's interface. Communication with team members are filtered (not to keep team members in the dark, but to filter out unnecessary distractions and time-consuming communication that has little or nothing to do with project success). Bureaucratic record keeping duties and reporting functions should be minimized to allow team members maximum time for productive work. Meetings should be structured for effectiveness. The project manager must set an agenda in advance, demand advance preparation (when required), ensure that records are kept and that action items are identified. Bottom Line The rookie software project manager should be given the opportunity to succeed. Ideally, he should be trained in advance and provided with necessary tools and resources that help get the management job done. But this is the real world. In far too many cases, the rookie is thrown into a project with little training and fewer resources. When that happens, things can be difficult - for the rookie, for the project team, and for the project. But even in this less-than-ideal situation, a manager can survive if she remembers four key concepts: communication, negotiation, organization, and facilitation. All the rest is detail.