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.

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 pushes for a schedule that is too tight or for quality requirements that are set too high.

Having seen the main qualities of a project, we need to mention that not all work is a project. Work that is not a project is called operational, even though one might still call it a project. The techniques for managing a project, however, can also be useful for operational work.

1.1.2 Programs, Subprojects, and Portfolios

Projects come in different sizes. Small projects might require the work of a few people for a few weeks or a few months. Larger projects might involve the work of thousands of people for years. Consider, for instance, the development of the F22 fighter aircraft. The development started in 1986 with a first phase to build two prototypes, which lasted 50 months. After the demonstration of the prototypes and the selection of the best model, the actual development started in 1991, with the first production aircraft delivered in 2003. The total costs of the project are estimated at 67.3 USD billion, in then-year dollars, that is, without any adjustment for inflation (Gertler, 2012).

Although in principle the development of the F22 could be organized as a single project, a more practical approach organizes its construction at different levels of abstraction and granularity. Projects are thus often organized and combined to achieve objectives larger than those of any single initiative. A common classification distinguishes among portfolios, subprojects, and programs.

1.1.2.1 Programs

A program is a set of related projects managed in a coordinated way. The underlying motivation is that coordination allows one to achieve additional benefits.

The most famous program is probably the U.S. manned space program, which culminated with men landing on the moon.

Program management uses many project management techniques, but it has a different focus and goal. The higher abstraction level at which program management takes place, in fact, requires a manager to reason in terms of vision, rather than goals, and roadmaps, rather than detailed plans.

1.1.2.2 Subprojects

Complex projects for which program management is an overkill can be organized and broken down into subprojects.

A subproject is thus the way in which one can organize the implementation of some specific objectives of a larger project. We will see in Chapter 3 how the organization of project activities can naturally lead one to identify a set of subprojects, with the definition of the contract work breakdown structure.

The distinction between a subproject and a project is often just a matter of terminology, since the approach and techniques are identical. A similar consideration applies to the boundaries between a project organized in subprojects and a program with different projects.

1.1.2.3 Portfolios

Organizations often use projects to develop similar systems. The term portfolio management thus identifies a situation in which a set of independent projects are coordinated to achieve better results.

A common situation is one in which a portfolio includes projects with similar functional aspects or technical challenges. Different groupings are possible. For instance, Project Management Institute (2004) highlights that a portfolio could include projects with the same class of risks, since they might benefit from the application of similar techniques.

1.2 What is a Software Project

When we think about software projects, probably the first thing that comes to mind is developing applications. While this is true in many cases, software-related projects take different forms. Even when the main goal is developing a system, coding is just one of the required activities, as we will see in Chapter 2.

In this section, we look at the main types of software-related projects.

1.2.1 Application Development

Application development might not be the only type of software-related project, but it is probably one that is great fun. The goal in this kind of project is building an application and providing the additional services and outputs to support it.

From the project management point of view, we can distinguish the following types of applications:

• One-offs or bespoke systems that are software systems specifically created for a customer. A bespoke system often implements a specific need of a customer, although in some cases the customer base of the final product could be large. Some examples of bespoke systems include a luggage tracking software, a compiler for a specific hardware platform, and a system to monitor a fleet of trucks. For bespoke systems, the specification of the application to develop (more in general of the project goals) will be driven and have to be agreed with the customer. The ownership and the source code of the final product might also be handed over to the customer. This kind of projects offers an opportunity for the supplier to enter a new market or establish a long-term relationship with a new customer. Consider, for instance, activities related to the long-term maintenance of a complex software system. The uniqueness and novelty of the product also constitute the main risk both for the customer and the supplier.
• Off-the-shelf applications are software systems implementing a function which is useful to many different users. It is the software we buy from marketplaces or stores and it is the equivalent of the Ford Model-T: one size fits all.* The goals and functions of the applications, in this case, come from the company developing the system, which sometimes conducts user surveys, to better understand needs and features that are most useful. Larger organizations might involve different departments in the specification of the software, making the activity similar to the previous case. A marketing department might play the role of the customer, defining the requirements, while an engineering department plays the role of the supplier and delivers the solution. The main characteristic is that the system is the same for each user and that the company developing the system sets the roadmap, choosing when to upgrade, what functions to add, and when to do maintenance.
• Finally, a customized off-the-shelf application sits somewhere between the two other types of applications. They are systems that are developed similar to off-the-shelf applications. However, they need to (or can) be customized to fit the customer needs. An example of a customized off-the-shelf application is an enterprise resource planning (ERP) system. An ERP system helps plan the resources of an organization and automate information management. While the engine of many ERPs is generic (and developed as an off-the-shelf application), many other characteristics (modules to use, what data has to be stored, how information flows) need to be customized for each client.

* This is not completely true as many applications come in different versions, for instance, a base and a pro, or with a plugin system that allows some customization.

1.2.2 Process and Systems Reengineering Services

Process and Systems Reengineering Services are projects related to improving the efficiency of an organization, by changing the way in which they conduct their operational work. These projects often accompany the introduction of one or more systems. In many cases, the system being introduced is an ERP. According to the project goals and size of the client, these projects might be significant and complex.

Consider the example of a multinational company revising its customer help-desk to improve quality and responsiveness. This project requires to understand how the organization currently works, what are the bottlenecks, and thus the possible interventions. These could include modifications to the current practices, training, and perhaps the introduction of a customer relationship management system to support the new processes.

See also Section 2.2 for a discussion on the topic.

1.2.3 System Integration Services

System integration services are projects and services related to automating the information flow among the different and independent systems used by an organization. The goals are to improve the efficiency of work and to reduce data duplication and errors. The approach is chosen when migrating to a new system is impractical or too costly.

Two types of integration are possible, vertical or horizontal. The first refers to the integration of different systems performing similar functions (e.g., putting together data about customers kept by different departments of a multinational company). The latter refers to automating or improving business functions (e.g., automating the flow of orders from marketing to production).

System integration services are more common in large organizations, which have a long history of system automation, or organizations in which departments have large autonomy. In these cases, in fact, different departments might automate similar functions without paying too much attention to data integration. Over time, the portfolio of applications grows and data coherence problems start to pop up. For instance, the IT systems of a company might still grant access to its premises to a person whose contract has expired, if the contracts and accesses are managed by two independent systems and someone forgot to manually update the data.

According to the project scope, these kinds of projects might be large, like in the case of reengineering services, or very focused, like it could be the case of a project to interface two systems. In the first case, the project requires an analysis of the business procedures and of the IT infrastructure. Compare the previous section and Section 2.2. In the second case, they are organized similar to an application development project.

1.2.4 Other Types of Projects

Consulting services might be asked to gain know-how, which is outside a company’s core competence. An example of consulting services is the evaluation of the reliability of a software system conducted using very specific techniques, which could not be part of the core business of a company. Another very common request is the assessment of the state of the art in a particular sector.

Installation and training services are services related to the installation of specific software systems (also in the open source domain) and/or training in the use of specific technologies or systems.

1.3 Managing Projects

1.3.1 The Project Manager and the Project Stakeholder

In my career, I have met project managers with different characters, qualities, and capacities, and I believe there is no such thing as the ideal project manager. Similar to a sport, talent, studying the techniques, practicing a lot, and learning from experience determine the kind of manager one becomes.

We have hinted above, however, that the characteristics of a project determine some of the features of a good project manager. Let us elaborate a bit on the concept.

As we have seen, projects are characterized by constraints and uncertainty. A bit of inventiveness and some predisposition to risk and flexibility can thus be of help in integrating the techniques we will present in the rest of this book. Notice that project management is about taming and mitigating risks, rather than passively accepting them. However, even when one tries and plans for the unexpected, unplanned unknowns will happen and a good project manager deals with them.

Another important distinctive feature is that projects are time limited. Thus, a sense of urgency can help set up a project fast and deliver according to the time constraints. The project manager, however, is also responsible for setting a sustainable pace in a project, so that the right rhythm is set and the team can work more effectively.

Some projects are also characterized by enormous complexity and require difficult choices to be taken. Cox and Murray (2004), a very nice reading about the Apollo program, describes many situations in which the project team had to take difficult decisions. One example that I found particularly striking is when George Low, manager of the Apollo program, faced with the possibility of the program slipping after the deadline set by President Kennedy, decided to change the schedule of flights, reducing the number of unmanned test flights, since these would not have provided any significant information to the program. History and system engineering proved him right.

I have not yet mentioned technical proficiency, namely, mastering the tools and techniques, which will be used in a project. I did it on purpose. Technical competence is certainly an important asset for a project manager, since it simplifies various tasks, such as forming a vision on the product, choosing a sound approach to project development, and identifying the main project criticalities and risks. Management is also about delegation, and technical proficiency can backfire, if, for instance, it comes with stubbornness or an incapacity to listen or second the choices of experienced teams.

People are a key contributor to the success or failure of projects. It is the work of people that makes the project outputs possible, mitigating the impact of technologies that do not work as expected and finding creative solutions when the unexpected occurs. They can also contribute to the failure of a project, with their sloppiness or disinterest. A good project manager thus deals with and manages people effectively. This is so important that Project Management Institute (2004) dedicates to these activities three of the 10 areas it defines to manage a project: stakeholder management, human resource management, and communications management.

1.3.2 Project Stakeholders

Project Management Institute (2004) defines a project stakeholder as any individual or an organization that is actively involved in a project, or whose interest might be affected as a result of project execution or completion.

Some stakeholders are simple to identify. Since the definition includes all people working in a project, the project manager and the project team, namely, the people responsible for carrying out the work in a project, are stakeholders.

Other stakeholders are those who benefit from the project execution or the project outputs. Among these are the client, the performing organization, and the project sponsor. The first, in fact, benefits from the project outputs, the second from the know-how and the revenues made in the project, and the third because of the peculiar interest he or she has in the project.

The remaining stakeholders might be directly or indirectly affected by the project. For instance, a company producing a software system might be negatively affected by a project of another organization developing a competing product.

Understanding who are the project stakeholders and effectively managing them is an important activity of a project manager. We will see in Chapter 3 some techniques to identify and manage stakeholders. Here, it is sufficient to mention that stakeholders have different interests and influence. Some might be interested to see the project that fails, while others might support it strongly. The influence a stakeholder can exert is usually a combination of how close the stakeholder is to a project and how much power he or she has.

1.3.3 Code of Conducts and Ethical Aspects

I do not want to go here into a philosophical discussion about what is good and evil and why one should behave good rather than bad. So I will take a rather practical approach and say that sticking to a code of conduct and behaving ethically is often also the most efficient and best choice both for the manager and for the project.

In an informal survey conducted among the members of the Project Management Institute (PMI®), about 80% of the managers interviewed faced ethical dilemmas (Cabanis, 1996). This is not surprising as many decisions taken by project managers are in the gray area, in which distinguishing what is good from what is wrong can be difficult. Consider, for instance, a situation in which a “buy in” bid is made to get a contract.* Surely it does not sound right. Consider the same situation, however, when getting the contract makes the difference to some employees of a company, who will get fired if the contract is not awarded. The situation becomes a bit more blurry.†

Organizations provide different codes of conduct. We will stick to that promoted by the PMI®, one of the reference organizations for project management, which we will briefly present here.

The code of conduct of the PMI® has been written by practitioners and is organized in four areas:

1. Responsibility: the duty of taking ownership of decisions made or failed to make and their consequences
2. Respect: the duty of treating with respect the resources assigned to us, such as people, money, reputation, environment, and so on
3. Fairness: the duty of taking decisions impartially and objectively
4. Honesty: the duty of acting in a truthful manner.

For each area, two types of requirements are listed. Mandatory requirements have to be met in any situation. Aspirational requirements are nice to have (Project Management Institute, 2013).

Thus, for instance, while a mandatory requirement is that of getting informed and sticking to regulations and laws governing one’s work (Requirement 2.3.1), listening to and understanding other people’s point of view is an aspirational requirement (Requirement 3.2.2). (As a side remark, the fact that the requirement of listening to and understanding other people’s point of view is only aspirational tells a lot about how daunting the task is and how patient project managers are.)

Other codes of conducts are available and applicable to the profession of project managers. For instance, the IEEE Board of Directors (2006), the code of ethics of the Association of Electrical and Electronics Engineers, similar to another famous code of conduct, lists in 10 items the rules one should stick to.

Although one’s values are often sufficient to take sound and ethical decisions, reading one or more codes of conduct is a good idea to help individuate those situations that might pose ethical choices in the profession and give project managers and professionals a reference framework when needed.

* A “buy in bid” underestimates project costs to make it more appealing. The costs are then raised as the project develops to match the actual expenditure.

† It is still wrong should you have had any doubt.

1.4 Software Project Management

Software project management is the integration of management techniques into software development. The need for such integration has its root in the 1960s, in the days of the “software crisis,” when practitioners recognized the increasing complexity of delivering software products meeting the specifications. A number of works started then to improve the software development practices, detailing and structuring technical activities more rationally.

In parallel with this, some big engineering projects started by the U.S. Government in the 1960s contributed to the consolidation and introduction of important project management techniques. The two areas, however, were too young or growing too fast to look at each other, and for a while they grew independent of each other.

Similar to system engineering, software engineering shares many concerns that can be dealt with by sound management practices. As software engineering matured as a discipline, more interest grew in the systematic integration of management activities in the software production process. Software development and project management thus started to be integrated more tightly. This is exactly what we start doing in this section.

People in operating systems often compare the architecture of an operating system to that of an onion. Similar to an onion, operating system architectures define different layers of functions, each layer building on top of the lower level ones. Taking inspiration from this analogy, we try and build our own tastier comparison between software project management and the millefoglie pastry, which is made up of layers of pastry and custard cream.* It requires quite a bit of fantasy, and maybe it does not work as well as the onion analogy, but it is certainly tastier!

Similar to the pastry, in fact, we organize software project management activities in two groups. The pastry gives structure and helps deliver. The custard binds the pastry together and ensures a harmonious result.

Our millefoglie is composed of four layers of pastry. The bottom layer includes all the activities that are essential to develop software. The other layers are made of management flour and butter. The second layer is scope management, which includes all the activities to ensure that a project delivers according to the goals it sets. The third layer is time management, which defines a schedule for a project and delivers according to the schedule. The fourth layer is cost management, which defines a budget and controls spending during a project.

With four layers of pastry, we need three layers of custard. These come in the form of technical and managerial activities to help ensure a coherent development of a project and of its results. Their common characteristics are that they run along the whole process and interact with the other activities, guaranteeing order and coherence.

The first layer of the custard is composed of change and configuration management, which help manage changes in a project, while maintaining a coherent view on its outputs. These processes interact with all software development activities and also influence goals, schedules, and costs.

The second layer of the custard is risk management, the set of activities to effectively manage menaces and opportunities. Similar to the previous case, risk management runs throughout a project, reducing the influence of unexpected events.

Finally, the third layer of the custard is made of quality management, the set of activities to ensure that a project defines quality goals and delivers accordingly the goals.

Finally, human resource management and stakeholder management are the powdered sugar sprinkled at the top. Try it without it, and it does not taste as good.

To continue the analogy, we can split our millefoglie into four slices, corresponding to the four phases we have introduced in Section 1.1.1. Each slice will still have all the layers. As a matter of fact, all the management concerns we have introduced in our analogy have an initiating, a planning, a monitoring, and a closing phase. (Software development is a bit of an exception, since it is mainly concentrated in the execution phase.)

This is shown in Figure 1.2, where we present our millefoglie. The horizontal axis represents the various project phases, while the vertical axis presents the pastry and custard, one per row. In Figure 1.2, we have deconstructed the millefoglie a bit, so that we can present more elementary activities and suggest one ordering in which the activities can be executed.

The first row contains the management of the project goals. The process spans all the four phases, including an assessment of the feasibility, the formalization of the project goals, the collection of the outputs, and closing the project.

The second row shows the software development activities, in which we have highlighted only two of the phases, namely, development and release.

The third row contains time management. We distinguish three activities, namely, the definition of a schedule, kickoff of activities and, in the dotted box, monitoring and control.

The fourth row contains cost control, including the definition of the budget and its monitoring (dotted box).

The remaining four layers contain the activities to manage changes, control software configurations, assess quality, tame risks, and manage human resources.

The arrows show a possible ordering of the activities. As we will see, it is one of different possible ways to organize work.

Notice that not all layers are always necessary to have a good project. Practitioners distinguish between traditional and agile management. The first favors structure, while the second prefers more lightweight approaches. Thus, some projects are better managed by reducing the fat and the infrastructure, while others can succeed only if you have the full deal. This also holds true for the millefoglie: more is not always better.

To conclude, I hope that you enjoyed the analogy with gusto. In the next chapters, we will have a look at the techniques in each area.

* Good food seems to be particularly relevant for people working in the area. A report about the meeting where the “software crisis” term was coined includes the following quote: “The conference had been held outside Rome in a rather charmless American-style hotel whose facilities and cuisine I’m sure did little to engender a harmonious atmosphere” (Randell, 1996).

1.5 Goals and Organization of the Book

This book is organized in two parts. The first part introduces the building blocks and techniques to develop and manage software projects, while the second puts them together in an organized process.

To go back to Figure 1.2, the first part describes the boxes, while the second part shows how these boxes can be organized in different ways. The goal of this approach is to achieve flexibility and to allow readers to be creative by selecting and mixing the techniques they find more effective for their projects. For this reason, traditional and agile techniques are presented side by side.

The first part of the book develops in the next four chapters. In more detail, Chapter 2, introduces the main activities characterizing software development projects. It covers the execution phase of a project and also helps understand why a sound management structure is also necessary for software development.

Chapter 3 covers the essentials, namely, how to manage goals, time, and costs. Starting from project selection, which describes some of the factors to consider before starting a project, the chapter develops by introducing techniques to define project goals, making them into a specification and a schedule of the work to be performed. A discussion on algorithmic techniques helps us understand how we can come out with reliable estimations and, consequently, with a budget for the project. The chapter covers the different project phases, including monitoring and control. Thus, it introduces the basic management techniques from end to end.

Chapter 4 introduces the variability and uncertainty that characterize any project and describes the techniques that can be used to ensure that these do not affect a project and its outputs. We will look, in particular, at techniques to deal with change requests and changes and demonstrate why a sound configuration management is essential. We will continue by analyzing the main techniques to deal with risks. A discussion on quality and on the techniques to ensure that quality goals are met concludes the chapter. Some might argue that quality management is an essential process deserving to be presented alongside goals, time, and costs management. I understand the point of view. Quality and quality management, however, not only set the baseline characteristics of the project outputs but also ensure that they are met in spite of the unexpected. I prefer to emphasize this second aspect.

Chapters 5 and 6 close the first part of the book. Chapter 5 introduces some theories about what motivates people and the techniques to manage team and stakeholders, establishing appropriate project structures and communication channels. Chapter 6 introduces some concepts related to software pricing and procurement activities.

The second part of the books puts the techniques together in a coherent process. Over the years, the way in which software projects are organized has changed considerably. Chapter 7 thus describes how to organize software development projects, introducing traditional and agile processes. Thus, the technical and managerial activities presented in the first part of the book are put together in different ways to try and tame the complexity of software development.

Chapter 8 concludes the description of processes by presenting standards and frameworks for software project management.

Automation has always been important to present and track information in a project. Today, it has become an essential infrastructure to also organize and allocate work. Chapter 9 thus closes this book by presenting some open source tools to support planning, management, and the organization of work.

The simplest way to read the book is, of course, from end to end. Each chapter, however, should be sufficiently self-contained to be readable and understandable by itself. The chapters in the second part of the book (Chapter 7, Chapter 8 and Chapter 9) make more sense after reading the first part of the book.

1.6 Further References

The literature on project management, software engineering, and software project management is huge. There are some references that I have found myself resorting to over and over again during my career as a teacher and as a professional. So, while you will find specific references in the chapters, if you are building your software project management bookshelf or if you want to complement this book with some additional readings in the area, the following references are some starting points.

Project management books:

• Burke (2006) is a very well-written introduction to project management. With its many diagrams and techniques, it clearly explain many topics of project management. I have found particularly interesting the discussion on project selection and budgeting techniques. All in all, the book is clear and fun to read.
• Wysocki (2011) is another very readable book on project management. With its 734 pages, it is also a considerable challenge to reading, but worth the effort or worth consulting, if you prefer to pick topics here and there. I found the description of traditional, agile, and extreme project types particularly interesting. Critical chain management and project closing are two other topics to look at.
• Maylor (2010) provides many insights from case studies while presenting techniques to manage projects. The presentation is based on the 4-D model: define it, design it, do it, and develop it.
• Project Management Institute (2004) is the definitive reference guide on project management. Sponsored by the PMI®, it illustrates the techniques that are most appropriate at each phase of project development. Given the breadth, the book only hints at the techniques and is a starting point to look for further references. The organization in process groups and knowledge areas, which we will see in Section 8.2, is very effective.

There are also various books explicitly focused on software project management. Among them

• Brooks (1995) is a seminal book on the topic, covering and introducing various important concepts that distinguish software project management from other management areas. Worth reading.
• Henry (2003) is the first book on software project management that I came across. It also raised my interest to the function points estimation techniques, which are clearly introduced there. We will cover function points estimation in Section 3.4.5.1.
• Hughes and Cotterell (2009) is a nice introduction to the topic. With a nice discussion on software quality and procurement, it introduces many of the concepts related to software project management.

A huge number of books cover software development and the management of software projects. I will mention only a few:

• McConnell (1996) presents critical aspects of software development, suggesting how becoming more agile can help tame wild software schedules. Rich in examples, the description of how stakeholders can make the project goals impossible to achieve is very interesting.
• Rothman (2007) provides a very practical approach to managing a project, with many insights and techniques to cope with the difficulties of software development projects.
• Ruby et al. (2013) provides the clearest and most readable example of agile development that I came across recently. So, while the book presents Ruby on Rails, a web development framework, its presentation is organized as a Scrum sprint. We will cover Scrum in Section 7.3.3.

Finally, I need to mention the many reports and books on the topic made available by NASA. While only partially overlapping with project management, NASA (2007) is very interesting to read. So are various other reports, including NASA (1990).

1.7 Questions and Topics for Discussion

1. Recap the main characteristics of a project.
2. Try and see which of the activities you commonly do could be organized as projects and which are operational work. Consider the following examples: writing an essay; studying at the university; preparing a meal; preparing dinner every evening; painting a house; exercising; training for the Olympic games.
3. Consider the construction of a web application that allows people to donate food. Who could be the stakeholders of the project?
4. Many software development processes are iterative. Each iteration delivers a software system that gets refined as development progresses. Go back to Figure 1.2 and think about how you could modify the process to make it iterative. How many possible loops can you envisage?

References

Brooks, F. P. J., 1995. The Mythical Man Month (Anniversary ed.). Addison-Wesley, Boston, MA, USA.

Burke, R., 2006. Project Management, Planning and Control Techniques (4th ed.). John Wiley & Sons, New York, NY, USA.

Cabanis, J., 1996, December. A question of ethics: The issues project manager face and how they resolve them. PM Network, 19–24.

Cox, C. B. and C. Murray, 2004, September. Apollo. South Mountain Books, Burkittsville, MD.

Gertler, J., 2012, October. Air force. Technical Report RL31673, Congressional Research Service. Last retrieved July 11, 2013. Available at http://www.fas.org/sgp/crs/weapons/RL31673.pdf

Henry, J., 2003. Software Project Management: A Real-World Guide To Success. Pearson Education, Addison-Wesley, Boston, MA, USA.

Hughes, B. and M. Cotterell, 2009. Software Project Management. McGraw-Hill Higher Education.

IEEE Board of Directors, 2006, February. IEEE code of ethics. Available at http://dusk.geo.orst.edu/ethics/codes/IEEE_code.pdf. Last retrieved May 31, 2013.

Maylor, H., 2010. Project Management (4th ed.). Pearson, Harlow, England.

McConnell, S., 1996. Rapid Development—Taming Wild Software Schedules. O’Reilly, Sebastopol, CA, USA.

NASA, 1990. Manager’s handbook for software development. Software Engineering Laboratory Series SEL-84-101, NASA Goddard Flight Center.

NASA, 2007, December. Systems engineering handbook. Technical Report NASA/SP-2007-6105 Rev1, NASA.

Project Management Institute, 2004. A Guide to the Project Management Body of Knowledge (PMBOK Guides) (4th ed.). Project Management Institute, Newtown Square, Pennsylvania 19073-3299 USA.

Project Management Institute, 2013. Project Management Institute—code of ethics and professional conduct. Available at http://www.pmi.org/en/About-Us/Ethics/~/media/PDF/Ethics/ap_pmicodeofethics.ashx. Last retrieved May 31, 2013.

Randell, B., 1996. The 1968/69 NATO software engineering reports. Last retrieved July 11, 2013.

Rothman, J., 2007. Manage IT! Your Guide to Pragmatic Project Management. The Pragmatic Bookshelf, Raleigh, NC.

Ruby, S., D. Thomas, and D. H. Hansson, 2013. Agile Web Development with Rails. The Pragmatic Bookshelf, Raleigh, NC.

Wysocki, R. K., 2011, October. Effective Project Management: Traditional, Agile, Extreme (6, illustrated ed.). John Wiley & Sons, New York, NY, USA.