Introduction to Software Project Management

Adolfo Villafiorita

• Editorial: Auerbach Publications
• Año: 2016
• ISBN:
  9781498759731
• Edición: 1
• Categoría: Business
• Categoría: Operations

Although software development is one of the most complex activities carried out by man, sound development processes and proper project management can help ensure your software projects are delivered on time and under budget. Providing the know-how to manage software projects effectively, Introduction to Software Project Management supplies an acces

Chapter 1

Introduction

1.1 What is a Project

1.1.1 Projects and Operational Work

Project Management Institute (2004) defines a project as a temporary endeavor undertaken to create a unique product or service. The definition entails five important characteristics of a project, some explicitly mentioned and some following as a consequence. These characteristics also define some of the requirements of a good project manager, as we will see later.

The first characteristic is that a project is temporary, that is, it has a beginning and an end. In many cases, determining the start and the end is easy. Consider the following examples: a contract sign-off, a formal authorization to proceed from senior management, a system going in production. In practice, however, many projects begin by slowly building up resources and interest, while the official start happens sometime after the resources and work have been invested. Others have residual work and activities going on after the official end, for instance to follow up on defects and problems found in project outputs. In all cases, however, projects have a start and a conclusion.

The fact that a project is temporary has a natural consequence. Every project will, in fact, have

1. An initiating phase, during which the project infrastructure and the project’s goals are drafted.
2. A planning phase, during which project goals are refined, activities identified and scheduled, and many other support activities are properly planned.
3. An executing phase, during which the actual work takes place. Running in parallel, a monitoring phase measures the progress and raises flags when plans and reality disagree.
4. A final closing phase, where the project outputs are handed out and the project is closed.

The amount and intensity of work in a project change according to the project phase. The initiating and planning phases will require a relatively small amount of work. Work will accumulate fast during the execution phase, as the project activities, many of which are running in parallel, unfold. As the project gets near to its conclusion, work will reduce and stop, of course, when the project delivers its outputs. If we plot the cumulative work produced in a project, we get an s-shaped curve. Both the phases of a project and the typical trend of cumulative work are shown in Figure 1.1.

Figure 1.1

Project phases and cumulative work.

As a side remark, Figure 1.1 also introduces the notation we will use for process diagrams, which was inspired by the activity diagram notation of the Unified Modeling Language (UML). In particular, rounded rectangles represent activities, a black dot represents the initial state, and a bull’s eye represents the final state. The arrow shows the order in which activities run. Although not shown here, we will also use rectangles to denote artifacts and diamond for choices.

The second characteristic is that a project delivers an output in the form of a product, a service, or a capability. The outputs are tangible, and often their properties are also measurable. Thus, a project can be set up and organized, starting from the description and the characteristics of the outputs it delivers. Such description, in fact, entails the work that has to be done to build the outputs. The description of the project outputs also defines the project completion criteria: the project ends when the outputs are delivered as specified. Things are not always so simple, however. Many projects have a clear output, but the way in which this is achieved might not be clear. Consider, for instance, a situation in which we want to improve the performances of a software system. The goal is clear, but the means to achieve it might not. In other situations, the outputs might not be completely clear or well spelled out. This is quite common in software development, where coming out with a complete and unambiguous description of a system is not always easy.

The third characteristic is that projects are resource constrained. A limited time is available to build the project outputs. Also limited will be other project resources, such as the budget and the team. An important consequence is that the project manager and the team have to find an achievable solution, while respecting all project constraints. Thus, the output of a project is seldom the best possible solution but rather the best solution given the constraints.

The fourth characteristic is that a project requires a progressive elaboration to build the project outputs. At the beginning, different ways are possible to achieve the project goals. As we move along, many project activities require to take choices, which reduce the degrees of freedom, till we get to the end of the project with the only possible implementation of the project goals. Thus, the cost of changes increases as a project progresses, since the amount of rework necessary to implement a change increases as we reduce our degrees of freedom.

The fifth and final characteristic is that a project delivers a unique output. Thus, what a project delivers has some novelty, one way or the other. This allows us to introduce the last important characteristic, namely, that a project always has some risk coming in the form of menaces or opportunities. Risks come from the unique characteristics of the project outputs, which sometimes are not fully understood or not clear when a project starts. Other risks derive from additional constraints that are set in a project; consider, for instance a situation in which a customer pushe...