Chapter 8

Development and Management Standards

8.1 Microsoft Solutions Framework

Microsoft solutions framework (MSF) is a disciplined approach to software development, first introduced by Microsoft® in 1994, to overcome some of the limitations of existing development practices, such as the inability to adapt to changing requirements. The method emphasizes a deliberate application of proven techniques. In fact, it includes best practices applied in Microsoft®, observed in other organizations, and suggested by effective development processes.

The main motivation for MSF is to define a method that mixes agile and traditional techniques to get the best of the two approaches. In fact, according to the Visual Studio Team System (2004), agile relies too much on individual ability, while traditional techniques can be cumbersome and slow to adapt. The framework has evolved over time, accommodating the experience gotten from the field. See Microsoft (2013) for the latest definition of the framework.

The framework is based on the following concepts:

• Foundational principles: the core inspirational principles on which the framework is based.
• Models: the way in which the foundational principles are systematically applied to a project. We look, in particular, at the team model, which describes the team structure and interactions, and at the process model, which describes the organization of activities.
• Disciplines: namely, the tools that support the development process.

8.1.1 Foundational Principles

MSF is based on eight foundational principles, which establish the basic principles of the framework. They take inspiration from agile methodologies. They are simple and self-explaining and there is not much arguing about their usefulness in a software development project.

Four of them focus on team, team structure, and team organization. The first, in fact, suggests foster open communication; the second demands empowering team members, and the third requires establishing clear accountability and shared responsibility. The fourth principle states learning from all experiences.

The remaining four establish some basic properties about the project approach and the development process. The fourth and fifth principles suggest working toward a shared vision and focusing on delivering business value, so that focus can be kept during a project. The need for agility and flexibility is stated in the sixth principle, which recommends staying agile and expecting change. The seventh principle states the importance of investing in quality.

8.1.2 Team Model

MSF organizes software development by allocating activities and responsibilities to seven different roles, each corresponding to a different project concern. The roles are

• Product management: the role responsible for ensuring that the system being developed delivers value to the customer
• Program management: the role responsible for ensuring that the solution is delivered according to the project constraints
• Architecture: the role responsible for designing a solution that meets the requirements and constraints
• Development: the role responsible for building the solution according to the specification
• User experience: the role responsible for ensuring usability of the solution
• Test: the role responsible for quality assurance
• Release/operations: the role responsible for smooth transition from development to operations.

The coupling between roles and project concerns clearly allocates the responsibility of each major project concern to a specific set of people. Thus, for instance, people taking the architecture role in a project will be responsible for building a solution that meets the requirements and constraints, possibly negotiating and mediating with the team members with different roles.

Another distinguishing feature is that MSF favors small teams and a flat structure. The first simplifies interaction and maintains the process agile. The second empowers team members, simplifies building a shared vision, and eases the process of building a solution that meets all the required constraints and qualities.

8.1.3 Process Model

MSF supports an iterative development process, which takes inspiration from the waterfall model and the spiral model. It is shown in Figure 8.1.

The process is staged and based on five different activities. Each activity ends with a milestone, with specific acceptance criteria. Milestones are opportunities to verify the achievement of the goals of one phase, adjust scope, if needed, and decide the transition to the next phase. In the words of Lory et al. (2003), the “end of each phase represents a change in the pace and focus of the project.” Similar to the agile disciplines, at the end of each cycle, a product is deployed and the process iterates with a broader scope.

The first activity is envisioning and the corresponding milestone is vision/scope approved. During this activity, the team, the customer, and the project sponsor define and agree on the scope of the project, on a preliminary plan, and on the project risks. At the end of the phase, all actors agree on the goals to be achieved and on the approach to achieve them.

Following the envisioning, the team can start the planning activity, with the corresponding milestone project plans approved. During this activity, the team defines the solution in detail, specifying what will be built, how it will be built, who will build it, and when it will be built. The starting point is the output of the previous step, and the main documents that are produced are

• Functional specification, describing the functional and physical characteristics of the system to be built
• Master project plan and master project schedule, describing the tasks performed by each role and their schedule.

The next two activities, developing and stabilizing, focus on building the system and readying it for deployment. The first activity, developing, builds a working system. Its milestone is scope complete. The second activity, stabilizing, performs testing on the system built, readying it for deployment. The milestone to transition to the next activity is release readiness approved.

The process ends with a deployment phase, during which the system is deployed and put in production.

8.1.4 Disciplines

During each iteration, three tracks run in parallel to the main development process, supporting its implementation. They are

• Risk management
• Readiness management
• Project management.

Risk management is conducted following the approach and principles described in Section 4.2.

More interesting is the readiness management discipline, whose goal is to ensure that adequate knowledge, skills, and abilities (KSAs) are in place to successfully conduct a project. The discipline embeds a continuous learning environment in the development process and is organized in four activities.

An initial requirements definition activity allows one to identify the main characteristics of the project and, consequently, the main KSA requirements. Microsoft (2005) distinguishes among high potential, strategic, key operational, and support projects concerning, respectively, the development of new products, the experimentation of new technologies, and the upgrade and customization of existing products.

Following the definition of the requirements, an assessment phase conducted on the team through self-assessment or other types of evaluation allows one to identify the main needs and gaps.

These are filled in the next phases, making the team ready for the project activities.

Finally, concerning the project management discipline, one important and distinguishing ingredient of MSF is that there is no formal project manager. Various management activities in MSF projects, in fact, are allocated to the program management cluster, but the responsibility is distributed among the team. The organizational structure remains flat. This also applies to larger projects, for which MSF envisages the identification of a role with specific project management duties.

8.2 PMBOK® Guide

The project management body of knowledge (PMBOK® Guide) is one of the main references for project management. It is structured as a collection of practices and techniques that help ensure the sound management of a project. The framework is applicable to any kind of project, including software development projects. The body of knowledge is maintained by the Project Management Institute, an association of professionals in the area of project management (Project Management Institute, 2013).

PMBOK® Guide organizes management disciplines and activities in two dimensions. The first dimension defines the knowledge area to which a specific discipline applies. PMBOK® Guide, in particular, distinguishes 10 disciplines, which we describe in Section 8.2.1. The second dimension identifies the project phase during which a specific discipline can be applied. More information can be found in Section 8.2.2.

PMBOK® Guide is a comprehensive framework from which project managers need to select the activities that best suit the project needs.

8.2.1 Knowledge Areas

Knowledge areas identify the main management concerns in a project. These run throughout the life cycle of a project. PMBOK® Guide distinguishes 10 different areas that a manager should monitor in a project:

1. Project integration management, with the goal of harmonizing all management activities and ensuring that a project aligns with the performing organizations goals.
2. Stakeholder management with the goal of managing stakeholders. It is a new area, introduced in the fifth edition of the manual. Before that, PMBOK® Guide described activities related to managing stakeholders in the communications management area.
3. Scope management, with the goal of controlling the project scope.
4. Time management, with the goal of defining, managing, and controlling the project schedule and timing.
5. Cost management, describing how to manage and control the project budget and costs.
6. Quality management, describing how to manage quality in a project.
7. Human resources management, describing best practices to manage resources in a project.
8. Communication management, which focuses on managing communications.
9. Risk management, which focuses on identifying, assessing, and managing risks.
10. Procurement management, which focuses on the management procurement activities.

8.2.2 Process Groups

According to PMBOK® Guide, projects develop in five distinct activities:

1. Initiating includes all activities related to starting a project.
2. Planning includes all activities to plan and get organized with work.
3. Executing includes all activities necessary to implement and build what is specified in the project scope, according to the cost, time, and quality constraints.
4. Controlling includes all activities necessary to monitor a project. Running in parallel to the executing phase, this activity collects data about a project and compares them with the forecast defined in the planning phase.
5. Closing includes all activities necessary to close a project and hand over the project results.

8.2.3 Processes

Knowledge areas and process groups can be organized in a table, having the process groups as columns and the knowledge areas as rows. At the intersection of each knowledge area and process group, PMBOK® Guide identifies a set of activities that address a specific project concern in a specific project phase. These are summarized in Table 8.1. Thus, for instance, at the intersection of time management and planning, there is the prepare schedule activity, whose goal is that of coming out with a plan for the project.

Concerning the sequence in which the different activities can be executed, there is a natural ordering from left (process initiation) to right (project closing) and from top to bottom. Project activities, however, can also be organized according to a different ordering, if one prefers to do so.

8.2.4 PMBOK® Guide for Software Development

PMBOK® Guide collects a set of practices that are applicable to any project, including those related to software development. As a matter of fact, IEEE® and PMI® are drafting, at the time of the writing of this book, a specific guide to the application of PMBOK® Guide practices. Some considerations on the matter can be drawn independent of the report being developed.

PMBOK® Guide is a comprehensive framework. A full application of its practices is definitely best suited for traditional and very structured approaches to software development. This is the case, for instance, of the Waterfall model, RUP, and V-Model, although both RUP and the V-Model come with their own project management practices.

In a traditional scenario, in fact, various PMBOK® Guide knowledge areas and processes integrate rather well and, in some cases, overlap with the corresponding phases required by the traditional software development process. According to the project goals, in fact, the requirements definition phase of the waterfall process corresponds or greatly overlaps with the scope definition activity of PMBOK® Guide. Similarly, most of the quality assurance activities of PMBOK® Guide correspond to the different testing activities of the waterfall model and the V-Model.

Not all activities of PMBOK® Guide are relevant for software development projects. Some activities, such as quantitative risk assessment, find niche applications in software development projects. Moreover, projects with a strong focus on software development might find the activities related to the communications and procurement management knowledge areas to be less important.

The application of PMBOK® Guide to agile development processes requires a lot more work. The best approach is one that picks only selected activities of those found in Table 8.1, according to the actual needs.

8.3 NASA Practices

NASA contributes significantly to the definition of good practices and standards for the management and development of (safety-critical) systems. Today, it defines and enforces the application of standards to contractors in the most diverse engineering disciplines. In the following sections, we focus on three important publications. The first is relative to the engineering practices of complex systems; the second describes the requirements that currently apply to the software development process; the third shows an example of a software development process, taken from NASA guidelines and documents released in the 1990s, but still relevant and applicable. All documents provide insightful information on the organization of projects.

8.3.1 NASA System Engineering Practices

NASA’s system engineering practices are collected in NASA (2007), where systems engineering is defined as a “methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system. A system is a construct or collection of different elements that together produce results not obtainable by the elements alone.”

The manual, clear and very readable, describes how to organize the development of a complex system. There are two main characterizing aspects in the organization of a project.

The first is what is called the system engineering engine, which breaks the complexity of system development using a product work breakdown structure. In this way, in fact, each node of the WBS defines a set of technical and managerial goals to lower levels, while at the same time ensuring that the technical and managerial constraints imposed by the upper nodes of the WBS are met.

The second feature is that system engineering is a linear and staged process organized in seven main phases (NASA, 2012). The first three end with a concept, which if validated allows a project to move to the actual construction phase. They are

• Prephase A: concept study, during which possible solutions are investigated
• Phase A: concept and technology development, where the project is defined
• Phase B: preliminary design and technology, during which the preliminary design is established.

A successful exit from Phase B moves the project to the actual construction and operation, which is organized in the following four phases:

• Phase C: final design and fabrication, where the system is designed and components built
• Phase D: system assembly, integration and test, launch, during which the components are integrated
• Phase E: operations and sustainment, where the system is operated and maintained
• Phase F: closeout, during which a system is properly disposed of.

The transition from one phase to the next is regulated by key decision points, or KDPs. There is at least one decision point per phase, but the actual number of KDPs per phase depends on the type of system being developed. This is illustrated in Figure 8.2. As can be seen from the figure, the first three phases are dedicated to the formulation of a solution, in the form of a design. After Phase B, a formal approval moves the project to system production and, after Phase D, to operations. The cycle terminates with the disposal of the system.

8.3.2 NASA Software Management Process Requirements

NASA has an articulated set of policies and standards related to software development. We will look at NASA (2009). The starting point is that NASA distinguishes eight different classes of software, which differ for their effect, should they fail.

The classes are identified by a letter. The first class identifies the most critical software. Thus, for instance, class A software is safety-critical software used in manned missions, while class H is general-purpose desktop software.

Clearly, different requirements apply to the development of different classes of software. Thus, rather than suggesting a specific process, NASA (2009) does not include any recommendation about the best software life cycle model; rather, it lists the requirements that a development process for a specific class of software should have. In this way, a manager is free to choose the process that fits better the system at hand, as long as it meets the requirements specified in the document.

The requirements of the admissible development processes are organized in the following areas:

• Software management requirements, which regulate many aspects of software development projects, such as interfaces with other organizations, estimation of costs, and verification and validation of minimum requirements
• Software engineering life cycle requirements, which define the minimum set of activities that have to be performed in any software development project
• Supporting software life cycle requirements, which identify the support processes that need to accompany development
• Software documentation requirements, which list the minimum set of documents and minimum set of information they need to contain.

Concerning software management requirements, a minimum of five different software plans have to be defined independent of the software class. These cover, respectively, overall management, with the software development or management plan; quality, with the software test plan and the software assurance plan; configuration management, with the software configuration management plan; and operations, with the software maintenance plan. In addition, safety-critical software requires the definition of a software safety plan.

As one might expect from a document by NASA, various other requirements of NASA (2009) cover safety-critical and mission-critical software, spelling the minimum functional requirements, support activities, and minimum requirements for contractors. For instance, different classes of software are bound to different maturity levels of subcontractors. Class A software requires a CMMI® level 3 certification (see Section 8.5).

As mentioned earlier, no specific constraint is imposed on a development process. However, at a minimum, any project must include the following activities:

• Requirements definition, which collects user and customer requirements and for which traceability and change management practices must be in place.
• Software design, which defines the architecture of a system; the standard requires to maintain a bidirectional traceability between design and requirements.
• Implementation, which produces code that must be unit tested and checked using static checkers. Bidirectional traceability with the design and explicit software versioning policies ensures that the software can be traced to each element of the architecture (and, by transitivity, to a set of requirements) and is properly versioned.
• Testing, which verifies the software functionality. Class A to C software (safety- and mission-critical software) requires some form of formal verification to be performed.
• Software operations, maintenance, and retirement, which require the definition of appropriate plans for the operational and retirement phases of a software system.

Six supporting activities complete the requirements of a sound development process. They are

1. Software configuration management
2. Risk management
3. Software peer reviews/inspections
4. Software measurement
5. Best practices
6. Training.

Of these, the first four are more directly related to the development, while the last two are more focused on exploiting and improving NASA organizational assets.

8.3.3 NASA Software Development Practices

NASA (1990) and NASA (1992) describe a disciplined approach for the development of software systems. It is an implementation of the requirements described in the previous section.

The development process is based on a sashimi waterfall (compare Section 7.2.1), which is organized in phases and activities.

The phases are

• Requirements definition and requirements analysis, which define and organizes the requirements
• Preliminary design phase, and detailed design phase, which define the system architecture with different levels of consolidation and certainty
• Implementation, which builds the system
• System test and acceptance test phase, which perform the system and acceptance tests, respectively.

The document also recognizes five different types of activities, which are necessary to build a software system. They are requirements analysis, design, implementation, system testing, and acceptance testing.

Similar to RUP, different activities are performed concurrently during system development. For instance, during the requirements analysis phase, most of the effort is dedicated to the requirements analysis activity, but some design and, possibly, some implementation activities will also take place. This is shown in Figure 8.3, taken from NASA (1992), where the relative weight of each activity is shown for each development phase.

Also of particular interest are the practices suggested for metrics collection. Table 8.2, adapted from NASA (1992), in particular, shows the timing and the type of data that should be collected during a project. In more detail, the guidelines suggest collecting metrics concerning estimated size (measured in SLOC), actual effort spent (man-hours), project status (SLOC written, test completed), and change and error traffic (requirements growth, errors, and changes). These data, in fact, allow one to monitor the main aspects of a development project, as discussed in Chapters 3 and 4.

8.4 PRINCE2®

PRINCE2® (Project in a Controlled Environment, version 2) is a de facto standard for projects conducted with the UK government. It started as an evolution of the PROMPTII methodology, defined in the 1970s by Simpact Systems (Offices of Government Commerce, 2009).

The initial consideration is that PRINCE2® recognizes that project management is seldom linear and straightforward. In a project, therefore, four management levels interact, exercise influence and control, and need to exchange inputs and information.

They are

• Corporate or program management. The highest level of the hierarchy, corporate and program management, influences projects by setting the business context for a project.
• Project direction. Immediately below the previous level, project direction ensures strategic steering to the project mediating and interpreting in the project context requests and constraints coming from the upper level. Strategic steering is performed by senior management and is based on management by exception strategy. Project direction approves a plan and then delegates its execution to the project manager; senior management intervenes only if some significant deviation from the plan occurs.
• Project management. Responsible for conducting a project, the project manager focuses on the daily planning and management of activities.
• Product delivery. The last management level, product delivery focuses on the delivery of planned products, that is, project deliverables.

The definition of PRINCE2® is based on a process model, which defines the management activities to carry out, and on a set of components, which support the management activities. Eight is the magic number. There are eight main activities in the PRINCE2® process model and eight different components. We analyze them in more detail in the next sections.

8.4.1 PRINCE2® Process Model

PRINCE2® adopts a staged approach to project development. We can distinguish, in particular, an initial phase, a development phase, and a closing phase:

• The initial phase is composed of starting and initiating, which have the goals of setting up a project and getting the project started.
• The development phase is organized in stages (or iterations), which can run sequentially or in parallel, according to the project’s logic. Each stage is composed of three different groups of activities: managing product delivery, controlling a stage, and managing stage boundaries, which have the goals of preparing activities of a specific iteration, controlling how work develops in the iteration, and closing the iteration.
• The closing phase is composed by closing a project, which manages all project closing activities.

The main development cycle is governed by two processes that run throughout a project. The first, directing a project, includes all activities meant to give strategic guidance to a project. The second, planning, includes daily and routine management activities.

Let us see in more detail the goals and content of each process.

8.4.1.1 Starting a Project

Different from many frameworks, PRINCE2® explicitly allocates time for the preparation of a project management structure. Thus, the goal of starting a project is to define a projects objectives and allocate sufficient time and resources to properly plan the project.

The process successfully ends when the project manager, the project team, and the project board are identified and appointed, the project benefits are assessed and considered worth pursuing, a project approach to the delivery of products is chosen, and the next step (project initiation) is planned.

8.4.1.2 Initiating a Project

Given the information of the previous step, during project initiation, the actual plans for the project are defined.

This includes planning the schedule, risks, quality, and project outputs. During this phase, the technical infrastructure is also set up. This includes a document repository and location for logs, such as, for instance, risk logs.

The process successfully ends when the project plans are defined and the project is authorized.

8.4.1.3 Directing a Project

Directing a project mainly involves the project board and it has the goal of providing strategic steering to a project.

Based on the information obtained from the project manager and the other processes, the project board authorizes project phase transitions, the application of exception plans, and confirms project closure.

If a project requires it, this process also provides ad hoc steering.

8.4.1.4 Controlling a Stage

Work in PRINCE2® projects proceeds in stages, with each stage corresponding to a project cycle, a work-package element, or other project element with a clear scope and output.

Controlling a stage properly starts a stage. The work required includes authorizing the work in a stage, allocating the necessary resources, and monitoring the stage execution, so that the expected product is actually built.

The main goals are to ensure that the quality, cost, and time constraints are satisfied, so that the planned benefits are achieved.

8.4.1.5 Managing Product Delivery

The main activities in managing product delivery are the authorization of the work in a stage and reporting to the project manager about the progress and the main parameters (quality, cost, time). When a product is completed, the process ends with the team manager getting the approval for the work performed.

The process allows for a clear separation of duties and responsibilities between the project manager, who is responsible for controlling a stage, and the team manager, who is responsible for carrying out the work envisaged in a stage. This is similar to the distinction between a project manager and a work package leader, which we have seen in Section 5.2.1.

In large projects, this process also allows one to clarify the allocation of duties and responsibilities between the contractor and the suppliers, similar to what was explained in Chapter 3 when we considered the Contract Work Breakdown Structure (CWBS); see page 56.

8.4.1.6 Managing Stage Boundaries

The managing stage boundaries process performs all the activities necessary to close a stage, including the collection of performance data and planning for the next stage, verifying that no significant changes have occurred in the project environment and in the expected benefits, and preparing a report for the project board.

8.4.1.7 Closing a Project

Closing includes all those activities necessary to verify project outputs, collect project data, assess benefits, and report on performances.

This is similar to what we have already discussed in Section 3.10.

8.4.1.8 Planning

Planning is the set of activities that allows one to build a project plan. Most of the activities required to build a plan have already been illustrated in Chapter 3.

Some of the distinguishing features are that PRINCE2® planning requires a project narrative to be developed and the definition of exception plans.

A project narrative is a textual description of a plan, explaining its structure and providing insights on the motivations driving one to specific project choices. The project narrative makes the project assumptions clear, simplifying comprehension and helping in the approval process.

An exception plan is a plan that is applied to put the project back on track, should an exceptional situation occur. PRINCE2® recognizes that plans are not perfect and that replanning is necessary. Thus, if, during project execution, someone recognizes the occurrence of an exceptional situation, the management board might authorize the definition and the application of an exception plan, which applies to activities up to the end of the current stage and which are meant to put the project back on track. The exception plan updates or replaces the nominal plan.

A final aspect to highlight is the British aplomb with which the guide recommends performing estimations in a project. At p. 174 of Offices of Government Commerce (2009), in fact, we find: “Estimating cannot guarantee accuracy, but it is better than not estimating at all.”

8.4.2 PRINCE2® Components

Eight components support the implementation of the processes we have just described. They are concerns and best practices spanning the different processes and phases of a project.

PRINCE2®, in particular, defines the following components:

• Business case
• Organization
• Plans
• Controls
• Management of risk
• Quality in a project environment
• Configuration management
• Change control.

Of these, the practices suggested for the management of risks, quality, and configuration management are very similar to what we have already seen in Chapters 3 and 4. In the rest of this section, therefore, we focus on the remaining components, highlighting some characterizing aspects proposed by the methodology.

8.4.2.1 Business Case

Business case is the reason for a project to exist. The higher level of the management structure authorizes a project based on a business justification and a project continues as long as it has a business case.

A business case is fully specified by providing the following information:

• A reason, which explains why the project outcome is needed.
• The options, which outline the alternatives to the project output.
• The benefits provided by the project outputs.
• The risks, which could seriously affect the outputs.
• The cost and timescale and investment appraisal, which evaluate a solution based not only on the development costs but also considering the operational, maintenance, and support costs. As specified in Offices of Government Commerce (2009), “the baseline for investment appraisal is the ‘do nothing’ option, i.e., what will the picture of costs and benefits be if the project is not undertaken?”

8.4.2.2 Organization

PRINCE2® proposes a reference organizational structure for a project, which identifies and clearly allocates roles and responsibilities.

In synthesis, the structure proposed by the methodology is a hierarchical structure, organized around the four layers identified above: thus, we can identify a project board that provides strategic guidance, a project manager, who is responsible for the management of a project, and team managers, responsible for organizing work in stages.

One noteworthy aspect is that the project board needs to include representatives, which can ensure that the three different interests of a project are represented, namely, the business (the product meets a business need), the user (the product satisfies a user need), and the supplier (the product is built according to the supplier’s capabilities and skills).

A second important aspect that is highlighted by Offices of Government Commerce (2009) is that the project board is not a democracy, but rather, a key decision maker. This is to avoid the management by committee syndrome, in which project decisions reflect a mediation of different interests and people, rather than focusing on the most appropriate action to have the project succeed.

8.4.2.3 Plans

Plans are the basis for any project. According to PRINCE2®, a good plan identifies the products to be produced; the activities, resources, time, and dependencies necessary to produce the products; a schedule of the activities, coherent with the dependencies among activities; and agreed tolerances. The identification of assumptions and prerequisites allow the project manager to understand the opportunities and constraints and build a plan that is coherent with this information.

In PRINCE2®, plans are organized at different levels of granularity, ranging from the program plan, the highest level, to the team plan, which defines how to achieve a specific deliverable. An exception plan allows one to manage nonnominal situations. The plans are interconnected, with higher-level plans setting constraints and framing boundaries of more detailed plans.

8.4.2.4 Control

Control is about verifying that the project is proceeding according to plans and verifying that the planned products are produced according to quality, cost, and time.

A first good practice we find in this component is that PRINCE2® acknowledges variations in planning, by incorporating tolerances in the plan. Thus, rather than having plans with fixed data, project managers in PRINCE2® reason with ranges of values.

The definition of tolerances in a project proceeds from the top of the hierarchy to the bottom, with higher levels defining what deviations are acceptable. Control allows the monitoring of actual results and creates a flow of deviations from the nominal plan from the lower levels of the management structure to the upper levels.

A second interesting aspect is the suggestion to use a daily project log. The manual suggests that the project manager should make writing the daily log a regular routine. Entries in the log can be organized by product and highlight any significant event, such as the status of work, outstanding issues, and products that will be due soon.

8.4.2.5 Change Control

PRINCE2® recognizes that change is structural in a project and that a sound change control system is essential to any project. Change management is based on a project issue log, that is, a way to systematically capture changes. Project issues include

• Changes in requirements, independent of their (apparent) impact. Even changes that seem minor, in fact, might have major consequences.
• Changes in the project environment, including, but not limited to, changes in regulations, suppliers, team members, and policies.
• New risks that occurred or were identified during project execution; risk that occurred.
• Problems or errors occurring on work being carried out.
• Queries about any aspect of the project.

Similar to what is described in Section 4.1, issues can either be a request for changes or nonconformance reports (off-specifications, using PRINCE2® terminology) and they need to be captured, assessed, and decided upon, documenting all the steps along the way.

PRINCE2® is flexible in defining what decision process should be applied for change management. This, in fact, depends on various project characteristics. Not surprisingly, the guide states that it is important to define processes and responsibilities in the initial phases of the project.

8.5 Capability Maturity Model Integration

Capability maturity model integration (CMMI®) is a certification program developed by the Software Engineering Institute, which is meant to measure the ability, or maturity, of an organization to develop and manage projects. The program starts from the consideration that there are three main components in an organization: the first is people, the second is tools and equipment, and the third is procedures. These components are held together by processes. Thus, measuring and improving an organization’s processes helps to improve the capabilities and performances of an organization. CMMI®, in particular, focuses on three domains: product and service development, service establishment and management, and product and service acquisition.

CMMI® measures the maturity in levels. Each level defines a set of organizational capabilities and builds on the previous one by adding some new capabilities. CMMI® identifies five different levels:

1. Initial. This is the starting level, where no process is defined or, when it defined, it is not controlled. As mentioned in CMMI® Product Team (2010), “Success in these organizations depends on the competence and heroics of the people in the organization and not on the use of proven processes.” Any organization is at least at level one.
2. Repeatable. This is the level of organizations that have a managed process. Projects are planned and managed by skilled people, who apply practices and standards and ensure an adequate control. The actual practices in place, however, are project-specific.
3. Defined. This is the level of organizations that have defined standards for managing projects. These standards are proactively applied and are used organization-wide.
4. Quantitatively managed. This is the level of organizations that are able to measure process performances.
5. Optimizing. This is the level of organizations that can make sense of the quantitative data they measure and that can use the data to improve their process.

The positioning of an organization at a specific level is determined by establishing and applying a set of good practices in different process areas.

A process area is a set of practices that are important for successfully managing a project. For instance, CMMI® for product and service development defines 22 process areas. Among them, we find those defined in the previous chapters of this book and some specific ones, such as, for instance, causal analysis and resolution and decision analysis and resolution. Some areas are relevant only for higher maturity levels.

In more detail, the methodology defines a number of generic and specific goals. Generic goals apply to multiple process areas, while specific goals are particular to an area. For instance, one generic goal at level 2 is that responsibility is assigned for “performing the process, developing the work products, and providing the services of the products.” Although the methodology defines practices that help achieve each specific goal, the model is flexible with respect to the way in which an organization satisfies it. The only important aspect is that the goals are met. Table 8.3 lists the CMMI® process areas for product and service development and summarizes the number of practices suggested by the methodology to achieve the goals of a specific area. They are only a very indirect measure of the difficulty of achieving a level, since different practices might be of different complexity.

In an ideal process, an organization implements an increasing number of practices to move up the certification ladder. CMMI® envisages two approaches to certification, staged and continuous. They differ in scope and method. In the staged approach, an organization achieves maturity levels by satisfying all the goals defined at a specific level. In the continuous approach, organizations achieve capabilities in specific process areas. A capability is achieved when all the goals of a specific process area are met. Thus, the continuous model allows for a more gradual or selective introduction of the practices. As a matter of fact, it defines a level 0, in which an organization has achieved the goals of one or more key process areas. The continuous model can be applied only up to level 3, since the higher levels of CMMI® require all practices to be achieved together.

See CMMI® Product Team (2010) for more information.

8.6 Questions and Topics for Discussion

1. Discuss the main differences and similarities between PRINCE2® and PMBOK® Guide.
2. Discuss the similarities and differences between the NASA development process presented in Section 8.3.3 and RUP.

References

CMMI® Product Team, 2010. CMMI® for development, version 1.3. Technical Report CMU/SEI-2010-TR-033, ESC-TR-2010-033, Software Engineering Institute.

Lory, G., D. Campbell, A. Robin, G. Simmons, and P. Rytkonen, 2003, June. Microsoft Solutions Framework white paper. Technical Report, Microsoft. More information and downloadable copy available at http://www.microsoft.com/msf. Last retrieved June 1, 2013.

Microsoft, 2005. Migrating Oracle on UNIX to SQL server on Windows. Technet, Microsoft.

Microsoft, 2013. Microsoft Solutions Framework (MSF) overview. Available at http://msdn.microsoft.com/en-us/library/jj161047.aspx. Last retrieved June 1, 2013.

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

NASA, 1992. Recommended approach to software development. Software Engineering Laboratory Series SEL-81-305, Revision 3, NASA.

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

NASA, 2009. NASA software engineering requirements. NASA Procedural Requirements NPR 7150.2A, NASA. Available at http://nodis3.gsfc.nasa.gov/. Last retrieved June 1, 2013.

NASA, 2012. NASA space flight program and project management requirements w/changes 1-10. NASA Procedural Requirements NPR 7120.5E, NASA. Last retrieved June 3, 2013.

Offices of Government Commerce, 2009. Managing Successful Projects with PRINCE2 (2009 ed.). The Stationery Office, London, UK.

Project Management Institute, 2013. Project Management Institute home page. Available at http://www.pmi.org. Last retrieved June 1, 2013.

Visual Studio Team System, 2004, May. Visual studio 2005 team system: Microsoft Solutions Framework. Available at http://msdn.microsoft.com/en-us/library/aa302179.aspx.