The Mission of a Project Manager

There are many reasons why a project may fail or result in poor quality. Many of them may be attributed to all kinds of technical reasons, and we are often pretty quick to do so; technology is a convenient and nameless scapegoat. But authors and consultants such as Roger Pressman who have witnessed many projects can testify: "If a post-mortem [assessment] were to be conducted for every project, it is very likely that a consistent theme would be encountered : Project management was weak ." ^[1]

^[1] See Pressman 2001, p. 55.

A Complex Role

"People, product, process, project ”in that order," is how the same Roger Pressman defines the scope of software development project management.

• People. Software development is very human- intensive and depends highly on the skills and the coordination of work among people. Many of the activities of a project manager will rotate around people and are focused mainly on the development team.

• Product. Nothing can be planned, studied, or produced if the objectives and scope of the software to be developed are not clearly established, and although the project manager does not define all the details of the requirements, your role is to make sure that the objectives are set and that progress is tracked relative to these objectives. This involves extensive communication with parties external to the development team, as well as with the development team.

• Process. If one person has to fully understand the process of developing software, it is the project manager. Project management is the embodiment of process. Having the RUP or not having it makes no difference if project management is not fully process-literate and does not drive the process. The process, supported by the right tools, is the common roadmap, understood and used by all team members .

• Project. And then, once on the road, the project manager manages the project itself, planning, controlling, monitoring, and correcting the trajectory as often as necessary. The project manager is dynamically steering and adapting.

In the very end, though, the manager of a software project will not be judged on good efforts, good intentions, using the right process, or having done everything "by the book," but on results . So throughout the lifecycle, the project manager should keep focused on the results, or any partial results that are getting the project closer to success. A RUP project is a collaborative effort of several parties, including the project manager. And within the very dynamic context of iterative development, the role of the project manager is more to "steer and adapt" than to "plan and track" (as often is the case in other domains).

So the role of the project manager is complex and requires many different skills to be able to dynamically steer and adapt:

• Technical skills to understand the issues at hand ”the technologies and the choices to be made. Far too often, we run into organizations that still believe that a project manager just manages resources (including people), and does not need to understand the product or the process. As a project manager, you do not need to be a technical expert in all aspects, and you should rely on the right people to help you on the technical side (see the Chapter 16 on architects and their relationship with the manager), but a good level of understanding of the technical issues will still be necessary to achieve the best results.

• Communication skills to deal with many different stakeholders and have an ability to jump from one style to another. For example, from personal communication (face-to-face, such as interviews and meetings) to impersonal (status reports ), from formal (customer reviews and audits ) to informal (small group brainstorming, or just walking around the project to test the mood).

A Person or a Team?

We tend to think of the project manager as one person. And in most small- to medium- sized projects (3 to 15 people), only one person will fulfill this role. But the RUP describes the project manager not as a person, but as a role that a person will play, and it is likely that on large projects, more than one person will play this role. There will still be reason to have one clear project leader, but that person should not feel the need to run all the RUP activities in the project management discipline.

First, there can be a small team of people doing the project management. One can be focused on planning; another one can deal with some of the key communication interfaces, with product management or the customer; another one can follow internal progress. Note that some of this specialization is already acknowledged by the RUP, which defines more than one manager role; there are managers' roles with specialized expertise, for example, configuration manager, deployment manager, test manager, and process engineer.

Also, for larger software development organizations, say 25 people or more, it is common to have the organization broken up into smaller teams , and each team lead will be delegated part of the project management role, relative to one team. In other words, the project manager has delegated some of the routine management and will get some "eyes and ears" all across the project.

Finally, in larger projects, some groups can be set up to handle some of the management activities in a more formal way and to support the project manager:

• To monitor the project's progress: a Project Review Authority (PRA) and a Change Control Board (CCB)

• To set up and improve the software process: a Software Engineering Process Authority (SEPA, sometimes also called SEPG)

• To drive the definition and adoption of tools, a Software Engineering Environment Authority (SEEA)

These groups are set up with people of the right expertise and authority, sometimes with full-time people, and they operate when necessary to support the management group or when dictated by the process.