Project Management

"Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet and exceed stakeholders' needs and expectations from a project." ^[2]

^[2] See PMI 2000.

Meeting or exceeding stakeholders' expectations invariably involves balancing competing demands among

• Scope, time, cost, and quality.

• Stakeholders, internal and external, with different needs and expectations.

• Identified requirements (needs) and unidentified requirements (expectations).

Scope of the Project Management Discipline in the RUP

An important warning is now due. The RUP deliberately does not cover all aspects of project management, and it remains focused on the engineering aspects.

Despite what we wrote above about the first "P," People, the project management discipline in the RUP does not cover many of the aspects related to managing people ”all the human resources management. So, in the RUP you will not find guidance on how to hire, train, compensate, evaluate, or discipline people.

Similarly, the RUP does not deal with financial issues, such as budget, allocation, accounting, or reporting. Nor does it deal with legal and contractual issues, acquisition and sales, licensing, or subcontracting . Additionally, the RUP does not deal with some of the administration issues associated with people, finances, and projects.

There is a wide range of practices around the world on these topics. And there is a wide body of knowledge accessible and not specifically linked to software development.

One great source of information is the Guide to the Project Management Body of Knowledge (PMBOK), developed under the auspices of the Project Management Institute (PMI) and endorsed by IEEE as Standard 1490-1998, Adoption of the PMI Guide to PMBOK.

The RUP does, however, concentrate on the software-specific aspects of project management, that is, the areas where the nature of software has an impact, making it different. The activities that are not covered by the RUP do take a significant amount of time and effort, and they require some skills. So they should not be overlooked when establishing the schedule of the people managing a project.

Software Development Plan (SDP)

It is hard to reduce software project management to a handful of recipes, but let us try to define the overall pattern ”the good practice.

The best approaches we have found so far is for the project manager:

1. To express the project's plans (the expectations as seen from the project management) in the various areas: scope, time, cost, quality, process.

2. To understand what could adversely affect these plans over time; that is, what are the risks if the project does not follow these plans.

3. To monitor progress to see how the project stays aligned to the plan, using some objective metrics whenever possible.

4. To revise any of these plans if the project goes significantly off-course.

5. Finally, to learn from your mistakes, so that the organization will not repeat them in the next iteration or the next project.

Consequently, the key artifact a project manager will focus on is a Software Development Plan , which is an umbrella artifact containing many different plans, each one dealing with one management topic:

• Project plan and iteration plans (see Chapter 12)

• Test plan

• Configuration Management plan

• Measurement plan

• Risks

• Documentation plan

• The specific process the project will use ”its development case

For better clarity, visibility, and accountability, the Software Development Plan may be one of the few formal artifacts of a project.

As the project unfolds over time, these plans are refined, corrected, and improved, as one may expect from iterative development; and to achieve this, other tactical artifacts are created. They are usually taking a snapshot view of the project to allow concerted reasoning about some tactical decision to be made:

• Review record (minutes)

• Issues lists

• Status assessment

One important aspect of the SDP is to define more precisely the process the project will use: This is the role of the development case described in Chapters 10 and 11. The project manager will set up and maintain the right degree of formality , the "level of ceremony" as Grady Booch calls it, that is adequate for this project. And this development case will also evolve as the project unfolds, based on the lessons learned at each iteration.

Iterative Development

This sounds like a leitmotiv in this book, but it is worth mentioning again. In an iterative development, you do not plan once and then monitor the project and try to coerce it to conform to the plan at any cost. You plan, and then replan, as necessary, again and again. You may therefore end up in a different spot from where you had intended to arrive in the very first plan, but you will find yourself at a better spot, or a more modest but more realistic spot, which is better than never arriving anywhere .

If you have never managed an iterative project, it can be daunting the first time. ^[3]

^[3] See Kruchten 2000b.

Risks

To effectively manage iterative development, the second concept the beginner RUP project manager must master and keep constantly in mind is that of risk. There are inherently many risks, of various magnitude and probability, that could affect a software project. Managing a software project is not a simple matter of blindly applying a set of recipes and templates to create wonderful plans engraved in stone and then bringing them back to the team for execution. Managing a project involves being constantly aware of new risks, new events, situations, and changes that may affect the project and reacting rapidly to them. The successful project manager is the one who is present, is curious , speaks to team members , inquires about technology, asks "why" and "how" and "why" again to identify new, unsuspected risks ”and then applies the appropriate recipes to mitigate them.

Metrics

Another key word for the RUP project manager is metrics. To avoid being sidetracked by subjectivity or blinded by biases, experiences, or knowledge deficiencies, the project manager establishes some objective criteria to monitor (more or less automatically) some aspects of the project. A few measurements can be put in place to help you gather variables such as expenditure, completion (how much of the functionality is complete), testing coverage (how much have you tested ), and defects (found and fixed), as well as the trends over time. Other useful metrics involve changes over time: amount of scrap and rework , or requirements churn, which can be tracked via a good Configuration Management system. The smart project manager would want to automate as much as possible the collection of these metrics to free more time for activities that might require more human interaction.

Metrics, from the current project and from previous projects, are what will help the team develop estimates, and in particular workload estimates (see Chapter 12 on Planning). These estimates are a shared responsibility between the project manager and the rest of the team. The project manager cannot unilaterally impose them on a team.