Developing mission critical software

soft on the product, hard on the project

Process Engineer
Centro de Computação da Aeronáutica de São José dos Campos – CCA-SJ
Departamento de Controle do Espaço Aéreo – DCEA, Brazil

João Murta Alves, DSc

Instituto Tecnológico de Aeronáutica – ITA
Centro Técnico Aeroespacial – CTA, Brazil

Proceedings of the PMI Research Conference 11-14 July 2004 – London, UK

“The problem is how you see the problem.”

(Stephen R. Covey)


Software development is an area where project management (PM) best practices are not easily applied. This paper focuses on dealing with the soft product scope in complex software development projects. To solve this problem, a framework that allows for a scope statement, configuration management, and help with software PM (schedule and cost) is presented. The research is based on a Brazilian government institution, which develops company-wide mission-critical software. The framework uses a product-project model; its consistency is maintained by a set of baselines.


The major reason for wasted time on large-scale information technology (IT) projects can be traced to vague or conflicting project definition and scope (Settle-Murphy & Thornton, 1999; Pressman, 1995). According to page 51 of A Guide to the Project Management Body of Knowledge (PMBOK® Guide), product scope refers to the features and functions that characterize a product or service, and project scope refers to the work that must be done to deliver a product with the specified features and functions. The former is managed by configuration control, and the latter through the project scope management. Even though it seems simple and straightforward, scope management and configuration control are complex tasks.

Since software’s adaptive nature does not allow the planning of software development to be made deterministically (Lewis, 2001), the generally accepted project knowledge and practices described in the PMBOK® Guide (2000) are not easily applied to software development. The development of complex, company-wide software is a hard task that involves several business processes, sometimes with complex interactions. The amount of business processes often result in fuzzy requirements; the frequent changes make it difficult to control scope and have a negative impact on schedule and budget, often making all the planning useless. Only through incremental development – sometimes a sequence of projects – can the stakeholders and users define all the product’s requirements. In-house development is the worst case in this scenario, as the lack of contractual bounds obstructs scope control.

That was the very problem found in a Brazilian government institution. This organization had great difficulty managing product configuration and project scope during the simultaneous development of three company-wide information systems, which had fuzzy requirements and were coupled in different degrees.

This paper presents a product and project scope management framework that was the result of work done on this institution, and answers the question of “how to develop multiple interdependent products through a set of manageable projects.” The Product-Project Framework enabled the target company to make product configuration and project scope control. As a side effect, the framework also enabled the company to reduce rework, overtime, and budget in software development projects.

The framework uses a Product-Project Model, supported by a set of baselines, which allows its consistency. The model aims to solve the product configuration and project scope control problems. In this model, each system is called a product, and the efforts to include functionalities in these products are called projects. A project can be related to one or more products. Each project is comprised of a set of well-defined requirements, allowing scope, time, and cost control. Through the baselines, the product vision—the set of functionalities already known—can evolve, regardless of the projects. New requirements can be added and old ones can be modified with controlled impact on projects.

This paper’s main contribution is to show a way to achieve the benefits of PM best practices in the development of company-wide and complex information systems. Project managers, software project managers, and general software project staff may use or adapt what is presented here in order to fulfill their particular needs. This paper is organized as follows: First, we offer remarks about the software development problem presented and put the problem in context. Next, we explain the framework in detail and describe its use through six processes. We will discuss preliminary results and will summarize the information in our concluding remarks.

The Crude Reality

Software is a very peculiar product category; it is developed or designed and not manufactured in the classical way (Pressman, 1995). Its production does not require heavy and expensive machinery. Instead, most software is developed through infrastructure that most of us can achieve. Unfortunately, buying a computer and using a developer’s suite do not give everyone the ability to make any software. Except for some very specific systems, a high level of knowledge, both technical and managerial, is needed.

Lewis (2001) puts software in a product category, which has an adaptive nature and cannot be planned deterministically. Settle-Murphy and Thornton (1999) state that the very nature of large-scale information technology (IT) projects makes them so difficult to continually meet deadlines, work within budget constraints, and please stakeholders. The major reason for wasted time on these projects can be traced to vague or conflicting project definition and scope (Settle-Murphy & Thornton, 1999; Pressman, 1995). Here, the software development difficulty is differentiated according to size (large and small) and complexity (complex and simple) (Exhibit 1). Large systems are company-wide impacting on most or all company sectors. Small software, on the other hand, is defined as being used in only one sector. Complexity here is related to the nature of automated processes; these can be complex or emerge from interdependency.

Software development categories

Exhibit 1: Software development categories

This article focuses on complex, company-wide software development projects. Since these include the whole enterprise processes and have to deal with their interactions, the complete product scope is very hard to define completely. Only through incremental development, the clients evolve a better understanding of their own business and are able to define all the systems requirements. It is also true that when a system deals with complex phenomena (physical, biological, etc.), the unknown reality simulation is done through trial and error. Having either fuzzy requirements or a high rate of change does not permit product scope of definition and control.

These conditions also make it difficult to implement the knowledge and practices described in the PMBOK® Guide (2000). By including all the product features and requirements (even the fuzzy ones), a project end date will be very hard to estimate and a high risk of project failure will be assumed. On the other hand, if you avoid the fuzziness by only including the well-defined points, you may lose sight of the entire product.

The Research Context

This paper is based on the work on a Brazilian government institution. It is a countrywide enterprise and has some in-house software development. The sector studied develops company-wide mission critical software, and the products under their responsibility are deeply coupled. Besides that, the lack of contractual bounds between this sector and their clients create a tendency to mix product maintenance and development, making it difficult to control scope and creating an even “darker” scenario in which projects have “fuzzy” requirements and high rates of change.

Since 2002, this particular sector is defining a software project development process, in order to raise its maturity level, both in software development and PM. It was also decided that this process should reference the Rational Unified Process (RUP) (Rational Software Corporation, 2002), compatible with the PMBOK® Guide (2000) and prioritized by The Capability Maturity Model (CMM) (Software Engineering Institute (SEI), 1995) and the Project Management Maturity Model (PMMM) (Kerzner, 2001). The focus here is on the configuration and change management discipline policy, and how it will adequately present the following scenario and objectives.

Background and Objectives

The target organization scenario was a complete lack of PM practices, even though they called their systems projects. Due to poor product configuration control, they had a mutant project scope, thus neither time nor budget estimates were ever reached and the incapability to reach these estimates eroded the confidence of the clients’ sectors. During the research period, three systems were under development (Exhibit 2).

Systems under development

Exhibit 2: Systems under development

The systems were also coupled in different degrees (as they were all related to the enterprise core business, but targeting different company levels), and this relationship raised a high-level of complexity (both in engineering and management). Thus, the company had problems managing the products and the related projects separately, as the change in one product may affect the others. A methodology adherent to CMM level 2 and based on RUP was defined to allow faster information interchange between project teams. To reduce the interaction impact, the systems started to be seen internally as a whole, though they were treated as different projects. These initiatives, however, did not have the expected result. Since RUP’s PM discipline does not encompass all the PM knowledge areas (Rational, 2002), the PMBOK® Guide (2000) was used to define the planning processes of the methodology.

Through the PMBOK® Guide (2000), some gray points became clear. First, projects are “a temporary endeavor undertaken to create a unique product or service” (p. 4). The amount of fuzzy requirements included in each project scope invalidated any effort to predict the project’s end: the only way to have a valid ending date estimate is by having defined project and product scopes. Second, configuration change management should track the product scope closely in order to reduce the cross impact from systems’ change. From these conclusions, the objective defined was to determine a configuration change management scheme that provides a way to:

  • Apply PM best practices to allow for scope control, while avoiding overtime and over-budget situations
  • Negotiate non-fuzzy project scopes (without including fuzzy requirements) and consequently reducing project risk
  • Make projects shorter and more manageable.

The Product-Project Framework

Scope Change Control, as described on page 62 of the PMBOK® Guide (2000), is useful only within the project boundaries. A broader approach is needed in the case of software systems, as their configuration includes hardware, firmware, and software, some of them outside the project boundaries. The Software Configuration Management (SCM) knowledge area presented in the Software Engineering Body of Knowledge (SWEBOK) (Abran, 2001) suggests a useful breakdown structure to organize this discipline. Both the PMBOK® Guide and SWEBOK approaches, however, allow configuration management only through the project life cycle and not through the entire product life cycle.

The product-project framework was designed according to the previously presented needs, and its goal is to ensure the configuration change management inside and outside projects, thus encompassing the entire product life cycle. It is important to emphasize that this framework is aimed at environments where the products under development are coupled or full of fuzzy requirements, creating a complex and hard to define information system. Using it in different situations will cause an unnecessary excess of control and a loss of time and effort.

Before presenting the model, it is important to note that this work’s software terminology and methodology are based on the Rational Unified Process (RUP). The product definition is traced from the problem statement to the requirements (Exhibit 3). The problem space includes the problem statement and the related stakeholders’ needs. The solution space includes the characteristics that a system must have and the functional and non-functional requirements that specify these characteristics.

Traceability dependencies

Exhibit 3: Traceability dependencies

RUP also advocates the iterative life cycle process (Rational 2002; Royce 1998). With this life cycle, an effective solution and effective plan are developed over several iterations, reducing risk exposure. The iterative approach, however, is sometimes misunderstood as an indeterminate sequence of iterations. It may sound very interesting when there are fuzzy requirements: it makes the system definition smoother as you learn from experience, but no end date can be set. If so, a project will be turned into an activity. The Product-Project Framework allows an iterative development through a sequence of well-defined iterative projects. It is comprised of a Product-Project Model and a set of baselines and rules that maintain its consistency.

Product-Project Model

In the Product-Project Model, each system is called a product and the efforts to include functionalities in the products are called projects. A project itself can be related to one or more products (Exhibit 4).

Relationship between products and projects

Exhibit 4: Relationship between products and projects

Each project’s scope is composed by a set of well-defined needs and features picked from what is already known about the product, and must allow scope, time and cost control. As a new project can exert an impact on existing products, on projects being developed, and even on the entire company information system, it falls into one of three scenarios:

  1. It is a completely new product (or set of products).
  2. It is a project on an existing product (or set of products).
  3. It includes new products and impacts on existing products.

In order to maintain the consistency of products and projects, baselines and related evolutionary rules were created. These let the product vision—a set of functionalities already known—evolve regardless of projects: new requirements can be added and old ones modified with controlled impact on projects.

Maintaining Consistency Through Baselines

Three types of baselines keep the product vision evolving and the development on track: vision baseline, product baseline, and project baseline.

Vision Baseline

The vision baseline encompasses all that is known about the product. This includes all of the stakeholders’ and users’ necessities, as listed in the problem space. The solution space shows systems, which fulfill the necessities described. The main artifact in this baseline is the product vision document (based on RUP‘s vision document, Rational, 2002). Its objective and contents are shown in Exhibit 5.

Product vision document—its objective and contents

Exhibit 5: Product vision document—its objective and contents

The vision baseline evolves through minor and major changes (Exhibit 6):

  • It suffers a minor change whenever a project is finished, in order to reflect the current status of its parts. For example, a functionality that was implemented during the project must have its status changed from identified to incorporated.
  • A product vision modification triggers a major change. This evolution occurs only with the client’s accordance. It can happen freely, regardless of projects or product versions.
Vision baseline evolution

Exhibit 6: Vision baseline evolution

Product Baseline

The product baseline tracks the evolution of stable builds delivered to clients. It includes all artifacts, software, and information needed to rebuild each version (software models, source code, libraries, development and operational environments, etc.). The product baseline is always compatible with a product vision version (not necessarily the most recent one). It is also the starting point for new projects.

The product baseline evolves through minor and major changes (Exhibit 7):

  • Minor changes occur when bugs are fixed and no new functionality or feature is added to the product version; in this case, the new product baseline version stays linked to the same product vision version as its antecessor.
  • At the end of a project, a new version of the product is available, the final product version. It is then promoted to a new product version. As it incorporates new functionalities and features to the product, it triggers a major change.
Product baseline evolution

Exhibit 7: Product baseline evolution

Parallel projects on the same product(s) have to be managed carefully. It is possible that some projects on the same product coexist (i.e., on different product’s modules) and they must be controlled through specific change control policies that are beyond the scope of this paper. Defining and using such policies, due to the framework’s intrinsic complexity and the necessity of cultural changes, is its main weak point.

Project Baseline

The project baseline includes the same artifacts as the product baseline. Its changes occur according to the project plan and it is useful only within the project, allowing configuration and change control. Through the iterative and incremental life cycle, its versions may trigger the start of activities and define the end of phases or iterations, etc.

When the project is finished and a new final stable build is ready, it triggers a major change in the product baseline (Exhibit 8).

Project finished and a new final stable version

Exhibit 8: Project finished and a new final stable version

Dependency Rules Summary

A set of dependency rules must be obeyed to keep the baselines consistent:

  • A product version will always be related to a vision version.
  • Whenever the previous rule is not broken, the product and vision versions can evolve independently.
  • It is possible that a vision version does not have any related product version.
  • A product version does not have to be linked to the most recent vision version.
  • The most recent product version is the preferential start point for any related project.
  • A project follows a project plan and is not linked to any vision version.
  • The result of a project, after being promoted to a product version, must be compatible to a vision version (not necessarily the last one).
  • A minor change in the product baseline triggers a project revision to incorporate the “bug fix.”
  • During a project, if any of the related products’ vision versions changes, a reevaluation of the project’s continuity is needed. A project can continue even if it is not compatible with the latest vision version.

Using the Framework

To provide a better understanding, this section presents a set of processes that exemplify a practical use of the framework. The activities described concern only those relevant to the framework itself. A methodology that encompasses PM and software engineering is also necessary, but is beyond this paper’s scope. Even though a project can work in more than one product, the exhibits, only to facilitate graphical visualization, will consider only one product. In the case of more than one product, the project baseline will be linked to various products, which are connected to the respective vision baselines. There are six main processes concerned to the framework use: receive solicitation, check impact, define project scope, create a project baseline, solve conflicts, and close the project.

Receive Solicitation

A client solicitation is the initiative that triggers most of the projects. Occasionally, an internal solicitation can trigger a project, but only when the client’s acceptance of a major change in the vision baseline happens. If necessary, some workshops are done in order to better understand the solicitation and aid in the initial project scope definition. Once the solicitation is accepted, its impact on the whole information system must be checked and the related product vision updated.

Check Impact

After understanding the solicitation, all products are checked to determine which are involved and whether there is any new product (Exhibit 9). This systemic, or holistic, approach must be taken to allow compatibility between individual systems and avoid waste through unwanted or replicated data or functions. This impact analysis is crucial for keeping the model consistent. Only relations within and between projects are observed; aspects such as team skills, technology, etc. are not considered here.

Define scope—sequence diagram

Exhibit 9: Define scope—sequence diagram

Whenever the solicitation incorporates a new product, a product vision must be created. If it involves existing products, each product vision must be compared to the new stakeholders’ and customers’ necessities, system characteristics, and requirements. The impact on the product itself and on the other products must be made clear. Depending on the coupling between products, it is possible that some changes in the product vision may make all previous versions obsolete.

Define Project Scope

A client solicitation, even though it changes the vision, does not necessarily trigger a project. If so, a project scope has to be defined. The project scope must be a set of necessities and related system characteristics from the product vision. It is important to remark that not all that is known of the product (product vision) has to be included in the project scope. Ideally, only well-defined items should be candidates to figure in the project scope. Not following this advice poses a high-risk factor. If it is impossible to avoid the inclusion of any fuzzy items, it is crucial that these items appear in the project’s Risk Document.

To define the scope of the final project, which must have the client’s acceptance, a project plan must be made. The impact analysis and the associated requirement fuzziness and risks are taken into account during the making of the project plan. Once the project plan is ready, it can be negotiated with the client. Now scope, time frame, budget, and risks must be pondered to define the final product scope. Sometimes the initial scope must decrease or increase to fulfill the client’s expectations. If the impact analysis was well made, the project plan will be a powerful negotiation and commitment tool.

Create a Project Baseline

A project baseline is created whenever a final product scope is defined. It has the last product version (if it exists) as a start point (Exhibit 10).

Creating a new project baseline: (a) new product; (b) existing product, current vision version; (c) existing product, previous vision version

Exhibit 10: Creating a new project baseline: (a) new product; (b) existing product, current vision version; (c) existing product, previous vision version

If it is a new product, and no previous product version exists, the product baseline will start empty and will reference the vision version through a project plan (Exhibit 10a). Existing products will start a new project baseline through the last product version (Exhibit 10b), even if it is not related to the current vision version (Exhibit 10c).

Solve Conflicts

Things change inside and outside the project scope. Changes from outside may cause conflicts:

  • If something is added to, or modified, at the vision baseline, a full revision has to be made to avoid inconsistencies. The products developed or under development must be checked for agreement with the new requirements. If the changes conflict with the current development, one should decide whether the project should continue regardless of the changes, incorporate the changes, or discontinue the project.
  • If the product baseline changes due to “bug fix” in an already delivered product version, the project team will decide whether to merge the current development and the fix.

Close the Project

At the project finish, the last stable project version becomes the product baseline (Exhibit 11).

Closing a project: (a) new product; (b) existing product, current vision version; (c) existing product, previous vision version

Exhibit 11: Closing a project: (a) new product; (b) existing product, current vision version; (c) existing product, previous vision version

When the first project on a new product finishes, its final build becomes the first version in its product baseline (Exhibit 11a). If it were an existing product, no matter the related vision version, the promotion would trigger a major change in the product baseline (Exhibit 11b and 11c). In all such cases, the related vision baseline would suffer a minor change, as the set of its target functionalities would modify the status from identified to incorporate.

Preliminary Results

At this moment, the target organization is starting to use the framework. The vision baselines have been created and the first project scope was negotiated and initiated with the framework’s help. The following are the benefits that were derived:

  • Internally, the framework provided a better understanding of the projects themselves and their cross-relations
  • Externally, the framework made negotiations with clients easier. It helped to better explain the dependencies within and between projects. It made clear that what is outside the project scope, but is in the Project Vision, was not forgotten but only prioritized
  • It is now possible to treat the development as a real project (non-fuzzy scope)
  • The projects became shorter, reducing risk and making it easier to estimate time and budget
  • Until now, the schedule and budget estimates were accurate and under control.

The encountered problems concerned the change from a one-to-one project/product paradigm, where each project targeted an entire system, to one with a set project/product, where each project focuses a set of functionalities that can be related to one or more systems and the system will be built through a sequence of projects. Sometimes, people lose their focus about what constitutes a product and what constitutes a project. As with any cultural change, things will settle down only through time and use.

Conclusion and Future Work

The problem studied was to find a way to deal with the soft scope nature of software development and the challenges of delivering projects on time and within budget. To solve this, a framework was designed that allows scope definition, configuration management, and software PM (schedule and cost) assistance for complex company-wide software development.

The project-product framework presented here is a simple but powerful tool to manage complex problems. The framework uses a product-project model, which has a consistency that is maintained by a set of baselines. In the product-project model, each system is called product and the efforts to include functionalities in these products are called projects. In order to keep the product vision evolution and the development’s track, there are three types of baselines: vision baseline, product baseline, and project baseline. The former keeps what is known about the product regardless of the actual product version or projects. The second tracks the stable versions ready to be delivered. The latter guarantees the configuration and change control within the project.

As shown in the benefits achieved, the framework aided not only planning and execution phases, but also helped with client negotiations. It has a psychological power when the stakeholders know that the development team is concerned with the entire product (through product vision), but the scope, schedule, and budget commitment is related only to the project scope. The framework helps in applying PM generally accepted knowledge and practices, as suggested in the PMBOK® Guide (2000), in complex, company-wide software development. The framework also guarantees better compatibility between coupled products and potentially increases the quality of schedule and budget estimates.

Even though it is based on the work on a Brazilian government institution that develops company-wide mission-critical software, it is the opinion of the authors that the framework would be useful to other companies and in other areas besides software development. For example, it may be applicable to research and development of innovative products. Further research, however, must be made to confirm that. This work’s main contribution was to lay out a way to achieve the benefits of PM’s best practices in complex, company-wide software development. This article is of particular interest to project managers, software project managers and software project staff.

A guide to the project management body of knowledge (PMBOK® Guide) (2000 Edition) Newtown Square, PA: Project Management Institute

Abran, A. (Ed.). (2001). SWEBOK: Software engineering body of knowledge [Electronic version]. Retrieved 11 Aug 2003, from

Kerzner, H. (2001). Strategic planning for project management: Using a project management maturity model. New York: John Wiley & Sons.

Lewis, J. P. (2001). Project planning, scheduling and control. New York: McGraw-Hill.

Pressman, R. S. (1995). Engenharia de software. São Paulo: Makron Books.

Rational Software Corporation. (2002). Rational Unified Process—RUP (Version 2002.05.00) [Computer software]. Cupertino, CA:Rational Software Corporation.

Royce, W. (1998). Software project management: A unified framework. Massachusetts: Addison-Wesley.

Settle-Murphy, N. & Thornton, C. (1999, Spring). Facilitating your way to project success. Information Strategy, 15(3), 36–44.

Software Engineering Institute (SEI). (1995). The capability maturity model: Guidelines for improving software process. Reading, Massachusetts: Addison-Wesley.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.



Related Content