The Simplified Project Management Process

One of the challenges of explaining project management to people who are unfamiliar with the approach, is that descriptions are often either so high-level as to be meaningless, or so detailed that they are overwhelming. Over the years, I have come to use a model as a framework for introducing and discussing project management tools and techniques. It can be used as the basis for a five-minute explanation of what is involved in project management, but also as an outline for more detailed discussions. (The actual model can be found on the Key Consulting website under free templates and info.)

A brief description of each step follows:

Assemble Team

The project planning team will be assembled, including appropriate representation from customers/clients, and sometimes subcontractors and vendors. Initial roles and responsibilities will be defined.

Deliverables: Initial project setup documentation.

Define Project Objective

With the project team in place, the overall project purpose will be verified and detailed project objectives developed. A phase-exit review will be conducted to ensure that the project is ready to move into the next phase, which is planning.

Deliverables: project charter, phase-exit review checklist.

Define Project Scope

An appropriately detailed Work Breakdown Structure (WBS) will be developed to ensure the project scope is properly agreed to and understood by all stakeholders. This also allows the complete project to be split into appropriate sub-projects and/or phases.

Deliverables: Project work breakdown structure.

Construct an Initial Plan

Once tasks of an appropriate level have been identified in the WBS, they will be organised by the project team into logical network diagrams, with estimated durations. This allows the project manager to predict when activities will be complete, assess the feasibility of target dates, and identify the critical path for the project.

Deliverables: Initial work plan.

Add Resources, Costs, Risks, etc.

Certain project resources may be defined as critical resources. In particular, the project manager may suspect that key project staff may be faced with too much work. If so, estimated resource usage information can be added to the project plan to allow resource forecasting. Cost is obviously also critically important, and expenditures can be added to the plan to create estimated cash-flow requirements. Risk management can also be utilised on projects to provide a framework to better manage events that occur beyond the control of the project team.

Deliverables: Resource availability and commitment profiles, risk identification and control strategies, cash-flow forecasts.

Obtain Stakeholder Buy-in

To ensure the project is implemented as smoothly as possible, with the support of the involved parties, it will be necessary to review the initial plans with all the major project stakeholders and to solicit buy-in from each one. A phase-exit review will be conducted to ensure that the project is ready to move into the next phase, which is control.

Deliverables: Approved final plan, phase-exit review checklist.

Publish the Plan

Once the plans are agreed to, they must be effectively communicated to all stakeholders. This can be done in hard copy or via electronic media, depending on the resources available. On most projects, a communications plan will be developed, and distribution of the plans will follow the guidelines laid out in the communications plan.

Deliverables: Plan published to all stakeholders.

Collect Progress Information

On a regular basis, the project manager will collect progress information that has been reported by the project team. This will allow the compilation of progress reports, such as:

• Activities completed within the past two weeks.
• Activities forecast for the next two weeks with a focus on activities on the critical path.
• Funds expended vs. fund expenditure forecast.
• Prioritised issues report.

Metrics can also be developed to measure project progress in other ways, such as earned value, or activity float statistics. If the project manager reviews the progress data and concludes that the project is complete, a phase-exit review will be completed to confirm that all the objectives have been met before moving into the final closure phase.

Deliverables: Set of progress reports, set of exception reports, metrics report, (phase-exit review checklist).

Analyse Current Status

By analysing the progress information received, the project manager will be able to augment the above reports with information about which areas of the project are of concern and where problems are likely to occur in the future. This allows managers to focus on the important/critical areas of the project.

Deliverables: Project evaluation report(s).

Adjust the Plan, and Manage Project Change

Based on the analysis, and with the support of the project team, the project manager will make plan adjustments to help reduce risks, accommodate scope changes, or to compensate for activities that have not occurred on schedule. Once this has happened, the plan will re-published and the cycle repeated until the project is complete.

Deliverables: Change request forms, updated plan.

Close Project

When the objectives of the project have been achieved, the project manager will close down the project. This will involve some financial closure tasks, as well as archiving of the project materials. A lessons-learned document will be developed to benefit future projects, and if possible a project team celebration will be held.

Deliverables: Final project report including lessons learned.

Kevin Archbold, PMP has nearly 20 years of project management experience working with large and small organisations in a variety of industries, including automotive, nuclear, telecommunications, trucking, IT, recruiting, HR, and government.

Project Management Process

Project Management Processes

MPMM™ includes the following project management processes: 
 

Project Management Process Time Management Process Cost Management Process Quality Management Process Change Management Process Risk Management Process

Issue Management Process Tender Management Process Procurement Management Process Acceptance Management Process Communications Management Process

Each project process describes the procedures you would take as a Project Manager, to manage an element of the project. For instance, the Risk Management Process will tell you how to identify, review, mitigate and monitor project risks more effectively. It also describes the roles and responsibilities of each team member, when taking part in project risk management. 
 
In addition to providing a comprehensive set of project procedures, for everyproject management process you will find an Example which gives you a complete practical example of that project process, for a sample project. 
 
Continue reading to learn more about MPMM Project Management Processes: 
 
Time Management Process 
 
By using the Time Management Process included in MPMM, you can easily monitor and control time spent on a project. You will be able to create procedures for completing timesheets, recording timesheet information and gaining an overall view of the status of your project. 
 
Cost Management Process 
 
The MPMM Cost Management Process helps you manage your project expenditure. It explains how to document your expenses through the use of Expense Forms and then implement an expense approval process. It also tells you how you can update your Project Plan with your expense information, to help you to keep an eye on your overall project expenditure. 
 
Quality Management Process 
 
To help you make sure that your deliverables meet the requirements of your customer, MPMM includes a Quality Management Process. By using this process, you can implement Quality Assurance and Quality Control techniques to monitor and improve the level of quality within your project. You can set quality targets, undertake quality reviews and implement measures to improve the level of quality of your deliverables. 
 
Change Management Process 
 
One of the greatest risks in a project is "scope creep". It happens when uncontrolled changes are implemented without formal approval, and it often leads to delays, over-spending and poor deliverable quality. To help you avoid scope-creep, implement the MPMM Change Management Process. This process helps you identify project changes and control their approval and implementation. 
 
Risk Management Process 
 
Every project entails a certain degree of risk. The reason is that you will have a fixed amount of time, budget and resources to achieve a set task. How you manage this risk will determine your level of success. By implementing the MPMM Risk Management Process, you can manage your risks through formal risk identification, quantification and mitigation. 
 
Issue Management Process 
 
Throughout the project, you will encounter a number of project issues. These issues will have the ability to impact on your delivery deadlines, so you need to manage them carefully. If you implement the MPMM Issue Management Process then you can put in place formal procedures for recording and resolving issues before they impact on your project timelines. 
 
Tender Management Process 
 
If you need to appoint suppliers to your project, then you will need a Tender Management Process. This project process allows you to select and appoint external suppliers, through the issue of tender documentation. This process helps you select one or more preferred suppliers, by issuing 3 documents; a Statement of Work (SOW), a Request for Information (RFI) and a Request for Proposal (RFP). 
 
Procurement Management Process 
 
It's one thing to find and hire the best supplier, it's another thing to then manage that supplier and ensure that they deliver everything that you have contracted them to provide. By using the Procurement Management Process, you can formally receive, inspect and approve every product and service that your supplier provides you with. You can then use that information to approve the payment of supplier invoices. 
 
Acceptance Management Process 
 
The determinant of project success is whether or not your customer signs off the project as complete and satisfactory. You will only gain complete satisfaction from your customer if you allow them to inspect and accept every project deliverable that you produce. By using the Acceptance Management Process, you can request that your customer reviews each deliverable produced by your project and signs it off as meeting their requirements. Your deliverables will then be 100% complete. 
 
Communications Management Process 
 
To help you communicate the right message to the right project stakeholders at the right time, MPMM offers a comprehensive Communications Management Process. You can use the communications planning and process templates and examples to keep your stakeholders informed of the progress of the project at all times. 

GLOSSARY

This glossary provides a brief definition of the important terms used in this report. It is arranged in alphabetical order.

TERM                DEFINITION                                                          Building Block      A generic method, practice, tool, or process definition in the                          inventory of software process assets owned and maintained by an                         organization.                                                       Current best        A process and associated implementation procedures that an          practice            organization keeps current  through continuous process                                  improvement.                                                        Lessons Learned     The organization's current best practice for recording a                                project's best practices, experiences with tools, problems, and                         other lessons learned in a postmortem report.                       Metrics             The organization's current best practice for measuring software                         projects, products, and processes.                                  Organization        A documented set of generic software building blocks which          Standard Software   define how a software organization does business.                   Process                                                                                 Product             The organization's current best practice for inspecting (peer       Inspections         reviewing) software documents and code to remove defects.           Programming         The set of programming languages, and organizational standards      Language            for using them, in which the organization is proficient.            Project Defined     The compilation of tailored building blocks, in a software          Software Process    development plan, for a specific project.                           Project Estimation  The organization's current best practice for estimating the                             cost, schedule, resource requirements, and size of a development                        effort.                                                             Project Management  The organization's current best practice for managing software                          projects (includes planning, and  tracking and oversight).          Project Reviews     The organization's current best practice for conducting                                 technical and management reviews.                                   Requirements        The organization's current best practice for eliciting and          Management          managing a project's requirements.                                  Risk Management     The organization's current best practice for assessing and                              managing software project risk.                                     Software            The organization's current best practice for SCM.                   Configuration                                                                           Management (SCM)                                                                        Software Quality    The organization's current best practice for SQA.                   Assurance (SQA)                                                                         Subcontract         The organization's current best practice for managing               Management          subcontractors in the performance of all or part of a software                          project.                                                            Support Tools       The set of management and development tools that support the                            organization's standard process and practices in which the                              organization is proficient.                                         Software Design     The organization's current best practice for performing software                        design.                                                             Software            The organization's current best set of development methods in       Development         current use  (e.g., object oriented, structured, etc.) in which     Methods             the organization is proficient.                                     Software Life       The set of software life cycles (e.g., waterfall, evolutionary,     Cycles              spiral, rapid-prototyping, etc.) for which the organization is                          proficient at executing a software project.                         Software System     The organization's current best practice for performing software    Test                system test.                                                        Tailoring rules     Documented rules that provide guidance for adapting the                                 organization's standard software process to specific project                            requirements.                                                       Technical           The organization's current best practice for managing and           Documentation       producing technical documents.                                      Training            The organization's current best practice for training personnel                         in the use of software development methods, tools, and practices.   Unit Test           The organization's current best practice for performing unit                            test activities.                                                    

---

---

APPENDIX A. PROCESS & PLANNING TOOL SUPPORT

The tools examined for this report were defined to allow users to maintain their organization's standard software process using the tool, tailor that process to the needs of a specific project, develop the project WBS and schedule with the same tool, and track progress during project execution.

It was assumed that these requirements would be implemented in a number of tools. Initially, both custom and commercially available tools were examined. In time, the list of tools was limited to those that were released (or had target dates for release) as Commercial Off-The-Shelf (COTS) products.

A breakdown of the functionality requested for these tools is as follows:

a. Share data with other tools (e.g., spreadsheets and/or scheduling tools).

b. Allow the organization to develop and maintain the organization's standard software process within the tool. The process should be able to be custom designed for the needs of the organization.

c. Provide a combined process definition and project management capability. (Project management here is assumed to include building and modifying WBSs, activity networks, and schedules and tracking progress against the schedules.)

d. Allow a number of user roles to have access to the data in the tool set in different ways.

e. Have a Graphical User Interface (GUI) to support ease of use.

f. Support software process definition and software process modeling.

g. Tie its project management capabilities to software process enactment.

h. Provide both Gantt and activity network (e.g., Program Evaluation and Review Technique (PERT) or Critical Path Method (CPM)) outputs.

i. Provide a relationship between the WBS and the project's defined software process.

Five tools were found that claimed to provide a majority of the requested capabilities. These tools and their advertised capabilities are listed in Table A-1 along with vendor, point of contact, and minimum system configuration information. None of the tools were examined in detail since the vendors contacted were not able to provide demonstration versions (or limited time examination copies) on request.

At the time of this research, it appeared that tools with the requested capabilities were just beginning to reach the market. This initial set of tools was unable to provide the full set of requested capabilities, and in dealing with vendors, it appeared that this type of tool set is still quite immature and not ready for use in a production environment.

It will be interesting to see the next generation of these tools and how they mature to support process driven project planning and project management.

Table A-1. Integrated software process and project management tools.

Tool	firstCASE	PEAKS
Vendor	AGS Management Systems 1012 West Ninth Ave. King of Prussia, PA 19406	Cedar Creek Process Engineering P.O Box 308 Cedar Creek, TX 78612
Point of Contact	Valerie Palamountain 610-265-1550	Terrel 800-303-8468 terrelj@source.asset.com
Data Import/Export	Import Text Files Export Text Files, Report Writer to Excel/Lotus files. Can copy and paste between applications.	ASCII text files. Import/Export Plans API Data Access
Flexible Process	Can be customized by your organization to incorporate your standards and procedures	Yes
Combination of Process Definition and PM	Yes, suite of tools	Combined
Role Driving?	Can define roles and responsibilities	Process Driven
Ease of Use	Windows based	GUI, point and click
Process Definition and Modeling	through fcprocess	Yes
PM tied to Process Enactment	Yes	Supports low level enactment in conjunction with other tools
Gantt & PERT or CPM	Gantt, PERT, CPM includes resources	Gantt
WBS tied to Process Structure	Yes	Yes
Platforms	PC/Windows, Windows NT, OS2	IBM RISC System 6000 w/ AIX 3.2.5 porting to Windows NT and Mac 7.x

Table A-1. Integrated software process and project management tools. (Cont.)

Tool	Process Engineer	Tool Project Management (TPM) [12]
Vendor	LBMS 1800 West Loop South, Sixth Floor Houston, TX 77027	Applied Business Technology 361 Broadway New York, NY 10013
Point of Contact	800-345-LBMS	Kristine Kiltz 212-219-8945
Data Import/Export	Bi-directional data transfers for various schedulers including Microsoft Project 3.0, Project Workbench 3.0 for Windows and Timeline 5.0 for DOS	Export to Text files
Flexible Process	Yes, with PE/Process Manager	Yes
Combination of Process Definition and PM	Yes, suite of tools	Yes, suite of tools
Role Driving?	Yes	No
Ease of Use	Reportedly easy to use	GUI, reportedly highly intuitive
Process Definition and Modeling	Yes, with PE/Process Manager	Yes via Methods Architect
PM tied to Process Enactment	Yes
Gantt & PERT or CPM	Gantt, PERT, Resource Charts	Gantt, CPM
WBS tied to Process Structure	Yes
Platforms	At least 386/33, MS-DOS 3.1 or greater, MS-Windows 3.1, 4 MB RAM, 15 MB available on hard drive, mouse and any network operating system	PC/Windows

Table A-1. Integrated software process and project management tools. (Cont.)

Tool	WBS Chart for Project
Vendor	Jim Spiller and Associate (JSA) 3256 Seminole Circle Fairfield, CA 94533
Point of Contact	707-425-2484
Data Import/Export	Import/export to Mircosoft  Project files. (.MPX)
Flexible Process
Combination of Process Definition and PM	No
Role Driving?
Ease of Use	GUI, Windows
Process Definition and Modeling
PM tied to Process Enactment	None
Gantt & PERT or CPM	None
WBS tied to Process Structure
Platforms	PC/Windows

5. CONCLUSIONS

Tailoring an organization's standard software process to the needs of a project is a detailed process that takes time and experience to complete successfully. The gains in streamlining software project planning and management appear to far outweigh the time and effort required to ensure that the project's defined software process (i.e., the tailored process) meets the needs of the project.

Throughout the research for this report, the following concepts emerged as important to the tailoring and planning processes:

a. Whenever possible, an organization's standard software process should be modular. It should consist of a set of building blocks that can be used in a number of ways to fulfill the needs of a software project.

b. While an organization's standard software process may need to fulfill the requirements of a process standard or other form of guidance, the organization's standard software process should be developed to fulfill the needs of the organization rather than simply comply to a specific form of guidance.

c. The organization's standard software process should be written as requirements so that compliance is mandatory and can be audited successfully.

d. The WBS, schedule, and activity network identify the processes to be employed on the project, their sequence, and their critical dependencies.

e. Software development plans contain logical descriptions of the process(es) to be employed on a software project (as exemplified in Table 3-3). These processes can be documented through references to the building blocks that will be used on the project along with descriptions of the modifications and waivers that provide the process tailoring specific to the project.

f. The software development plan forms the foundation for measurement to be implemented on a software project. It is important to ensure that the elements of the plan are measurable.

g. By using a defined, documented process to tailor the organization's standard software process to the needs of a project, a base of information can be developed that will help members of an organization understand the types of variations that can exist between projects and make the adjustments necessary to fulfill the needs of the project prior to project implementation.

The only way to finally prove the value of tailoring the OSSP to the needs of a project is to do it and to measure the results in improvements in the planning process and in project performance.

LIST OF REFERENCES

DOD-STD-2167A       Defense System Software Development, 29 February 1988        GINS95              Ginsberg, Mark, "Tailoring and the CMM," Presentation to                         SEI Symposium, September 1995                                LAKE93              Lake, Jerry, "The Work Breakdown Structure - It's Much                           More Than a Cost-Reporting Structure," pp. 3-9, Program                          Manager, July-August 1993                                    MAIB94              Defense System Software Development DOD-STD-2167A &                              DOD-STD-2168 Tailoring Tips & Software Development Cycle                         Chart, (c) David Maibor Associates, Inc., 1994               MIL-STD-498         Software Development and Documentation, 5 December 1994      MIL-STD-881A        Work Breakdown Structures for Defense Materiel Items         MIL-STD-882C        System Safety Program Requirements, 19 January 1993          MIL-STD-1521B,      Technical Reviews and Audits for Systems, Equipment, and     Change 1            Computer Programs, 19 December 1985                          PAUL93              Paulk, Mark C., Bill Curtis, Mary Beth Chrissis, and                             Charles V. Weber, Capability Maturity Model for Software,                        Version 1.1, CMU/SEI-93-TR-24, Software Engineering                              Institute, February 1993                                     

---

---

LIST OF ACRONYMS

4GL                 Fourth Generation Language                                   ANSI                American National Standards Institute                        ATE                 Automatic Test Equipment                                     CDR                 Critical Design Review                                       CDU                 Control Display Unit                                         CFD                 Control Flow Diagram                                         CMM                 Capability Maturity Model                                    COTS                Commercial Off-The-Shelf                                     CPM                 Critical Path Method                                         CSCI                Computer Software Configuration Item                         CSSR                Cost and Schedule Status Report                              DFD                 Data Flow Diagram                                            DID                 Data Item Description                                        FP                  Function Points                                              GPS                 Global Positioning System                                    GUI                 Graphical User Interface                                     HUD                 Head-Up Display                                              HWCI                Hardware Configuration Item                                  IDD                 Interface Design Description                                 IPT                 Integrated Product Team                                      IRS                 Interface Requirements Specification                         ISM                 Integrated Software Management                               KPA                 Key Process Area                                             MIS                 Management Information System                                OCD                 Operational Concept Document                                 PDR                 Preliminary Design Review                                    PDSS                Post-Development Software Support                            PERT                Project Evaluation and Review Technique                      SCM                 Software Configuration Management                            SDD                 Software Design Description                                  SEE                 Software Engineering Environment                             SEI                 Software Engineering Institute                               SEPG                Software Engineering Process Group                           SLOC                Source Lines of Code                                         SPD                 Software Process Definition                                  SPI                 Software Process Improvement                                 SQA                 Software Quality Assurance                                   SRS                 Software Requirements Specification                          SSDD                System/Subsystem Design Description                          SSS                 System/Subsystem Specification                               STD                 Software Test Description                                    STP                 Software Test Plan                                           STR                 Software Test Report                                         STrP                Software Transition Plan                                     SVD                 Software Version Description                                 SW                  Software                                                     WBS                 Work Breakdown Structure                                    

4.4 Documenting the Project's Defined Software Process

4.4.1 Documenting the Tailoring Decisions

The changes to the organization's standard software process are relatively minor for this project. As discussed in Paragraph 3.4.1, the deviations can be documented by exception in a compliance agreement. In this case, the following tailoring is applicable:

a. Choose the waterfall model from the three available software life cycles.

b. Delete the allocated baseline (SRS and IRS) from the SCM practices and refer to internal control processes.

c. Add external control of the software development plan to the SCM practices.

d. Modify review requirements to reflect only in-process reviews with the acquirer.

e. Modify the metrics practices to add external distribution of metrics data to the acquisition organization.

In practice, these modifications need to be made with references to the document names and paragraph numbers that will need to be modified or deleted to reflect the tailoring. Additions can be made through descriptions of the changes and document references.

4.4.2 Incorporating the Project's Defined Software Process in a Plan

4.4.2.1 Organizing the Work

The first step in developing the software development plan is to examine the system WBS and determine the level of detail needed to identify the processes that will be employed to run the project. In the case of the GPS/CDU Upgrade program for XDEVEL, program's products can be decomposed as shown in Figure 4-2 to get to the GPS Interface and Communications Software Project, which is the project name for the example presented in this section.[11]

The software project then is decomposed into the processes that will be employed to run the project. In this case the major processes are project management, software development support, software development, software qualification, and post-development support. Then these processes are broken down into their respective elements to show more detail in how the project will be run. For example, the software development and qualification items show a decomposition that is consistent with the waterfall life cycle chosen for this project, as discussed in Paragraphs 4.3 and 4.4.1. The WBS decomposition is complete when it is determined that resource allocation, costs, and schedules can be tracked based on the work definitions shown in the WBS and an associated work breakdown description.

4.4.2.2 Documenting the Schedule

At this point, a schedule estimate needs to be documented based on the WBS. Figure 4-3 is a Gantt chart based on the WBS decomposition of the GPS Interface and Communications Software Project (starting with WBS element 1222).

4.4.2.3 Developing the Activity Network

When the schedule is completed, the activity network can be documented to show the dependencies among the activities identified in the WBS. Figure 4-4 is a simplified activity network based on the WBS and schedule provided in Figures 4-2 and 4-3.

The final planning steps are to record the processes, activities, and plans in the software development plan as discussed in Paragraph 4.4.2.4.

4.4.2.4 Completing the Software Development Plan

Paragraph 3.4.2.4 discussed the options for documenting the modifications to the building blocks in the software development plan. For the GPS Interface and Communications Software Project, three building blocks will be modified and a fourth will use one of the three life cycle options documented in the XDEVEL organization's standard software process. All other building blocks will be used as is.

Figure 4-2. GPS Interface and Communications Project WBS.

Figure 4-3. GPS Interface and Communications Project Gantt chart.

To document the project's defined software process in a software development plan using the outline identified in Table 3-3, the tailoring for the XDEVEL building blocks can be documented in the following ways:

a. Reference to the life cycle adopted for this project from the standard building blocks could be made in the software development plan, Paragraphs 3.3 or 4.1 (or their subparagraphs).

b. Modifications to the SCM practices to cover deletion of the allocated baseline and addition of external configuration control for the software development plan should be documented in the software development plan, Paragraph 5.14 (or its subparagraphs).

Figure 4-4. GPS Interface and Communications Project activity network.

c. Modifications to the review requirements to reflect only in-process reviews should be documented in Paragraph 5.18 (or its subparagraphs).

d. Modifications to the metrics practices for external distribution of metrics data should be documented in the subparagraphs for Paragraph 5.19 that deal with metrics.

Where no building block exists to cover a specific process area in the software development plan, that information will need to be generated. For example, XDEVEL does not have a process building block for establishing the software development environment; this will need to be documented in Paragraph 5.2 of the software development plan. Building blocks used as is should be referenced from the appropriate paragraphs in the software development plan (e.g., the SQA practices will be referenced from Paragraph 5.16 rather than repeated).

The WBS, schedule, and activity network provide inputs for Paragraphs 3.4, 4.2, and Section 6. The remainder of the plan is developed specifically to address the unique requirements of this project, e.g., the overview of the work and constraints on it that are covered in the paragraphs of Section 3 and the organization information presented in Section 7.

The plan, when completed, defines the work to be done, constraints on the work, and the processes used to complete the work. This information then is used to manage the project and to provide the foundation for measuring project progress, process conformance, and selected product measures.

4.2 Identifying Project Characteristics

The basic information about the example is:

a. Size ~ 9000 SLOC.

b. 1 CSCI on aircraft. 1 CSCI on GPS to be modified through subcontract.

c. >= 5 interfaces external to the GPS.

d. 150 aircraft in the inventory to be upgraded; one user for each aircraft. It is assumed that the aircraft will remain in service for at least another decade.

e. ~ 800 pages of documentation (based on the definition in Paragraph 4.1.1).

f. Subcontract for modifications to GPS code and for new (or modified) GPS documentation.

g. Minimal technical complexity.

h. Life critical application.

i. Moderate need for management visibility.

j. Testing needs to be used to assure the reliability required to fulfill the requirements for the aircraft.

The first tailoring step is to list the known project characteristics in the project characteristics form to support further analysis, as shown in Table 4-1. The areas for concern are human safety, the level and formality of documentation, implementation of MIL-STD-498 and its changes in philosophy from previous standards, lack of formal reviews, and the unknown complexity that could exist in the interface code.

Table 4-1. Project characteristics for GPS example.

Characteristic	Quantification
Size and Complexity:
Software Product (estimated SLOC or FP)	~9,000
Documentation (estimated # of pages)	800 pages, 275 from subcontract
Development Team (estimated # of people)	7 - 3 developers, 2 testers, 1 doc., 1 mgr
System Product Mix:
Number of HWCIs	1
Number of CSCIs	2 - 1 new, 1 mod
Number of Interfaces (External)	5
Type of Software (Command & Control, Embedded, MIS, ATE)	Embedded
Type of System (Centralized, Distributed, Mission Critical, Weapons System,etc.)	Weapon System
Intent (Feasibility study, research, operational system, incrementally developed operational system, upgrade to an existing system, etc.)	Upgrade
Criticality (Life Critical, Safety Critical, etc.)	Life Critical
Users
Number of Users	1 per Installation
Type of Users	pilots
Local or Distributed	Local
Number of Installations	150
Life of Product (Number of months or years)	10 Years
Upgrade Interval	Unknown
Formality
Development requirements	MIL-STD-498 (Upgrade from DOD-STD-2167A)
Formal reviews and audits	In-Process Reviews
Formal approval of deliverables and baselines	Formal approval of plans and all artifacts delivered after CSCI test and revised after flight test
Control
Management visibility level required
Development Organization	Moderate
Acquirer Organization	Unknown
Project Risk Management
Cost	Moderate
Schedule	Moderate
Technical	Low - Known Problem

This is the project information that provides one of the primary inputs for tailoring the XDEVEL's standard software process to the needs of the project.

4.3 Choosing and Tailoring the Building Blocks

From the description of how XDEVEL does business, as presented in Paragraph 4.1.2, it is obvious that the organization has a well-defined software process. The building blocks identified in Figure 4-1are either mentioned or strongly implied in Paragraph 4.1.2.

Figure 4-1. XDEVEL's building blocks.

Based on the project characteristics identified in Table 4-1, the guidance in Table 3-2, and XDEVEL's building blocks, Table 4-2 identifies the XDEVEL building blocks that may need to be tailored for the GPS software project.

On examining the project characteristics and candidate affected building blocks, the project manager notes the following regarding the issues related to the building blocks in question:

a. Adding the GPS to an existing aircraft is a known problem and the system will be small; thus a waterfall life cycle will be used.

b. Reliability modeling and testing are already documented in the unit test and software system test practices.

c. Reliability metrics will be stressed during testing. These metrics are already documented in the metrics practices for use with life-critical or safety-critical systems.

d. The SCM practices are focused on a standard set of deliverables with relatively standard reviews. Modifications may need to be made for the different baselines that will be established for this project.

e. The review practices stress a formal review process for projects using a waterfall life cycle; this will need to be modified for the in-process reviews used for this project.

f. Since use of MIL-STD-498 documentation is new to the organization, it will be important to track progress on document development for this project. These practices are already documented in the project management and metrics building blocks, so no change will be required.

g. The metrics practices are internal; they do not cover sharing data with the acquisition organization. This is a modification to the metrics building block, and it may want to be added to the metrics building block in the next release. (Sharing metrics data also may become interesting as part of the lessons learned at the end of the project.)

h. Although the risk management practices will be used, there is nothing in the approach to risk management for this application that is out of the ordinary. Use the risk management building block as written; no change.

The project manager is responsible for developing the compliance agreement for the project's defined software process and for developing the software development plan.
Table 4-2. Candidate XDEVEL building blocks to be tailored.

Key Area	Quantification Factors	Heuristics	Candidate Affected Building Blocks
Size and Complexity	Small but life critical application to be installed on at least 150 aircraft, 10-year operational life, Unknown software upgrade schedule.	· Plan a safety program using MIL-STD-882C Safety Standard as a guide · Use reliability modeling and testing	· Software Lifecycles · Metrics · Unit Test · Software System Test
Formality	· MIL-STD-498 (Upgrade from DOD-STD-2167A) · In-Process reviews · Formal Documentation · Formal approval of plans during development · Formal approval of all other items after CSCI testing	· Plan for strong internal SCM for developmental artifacts to ensure traceability of changes to documents and code · Use full implementation of MIL-STD-498 Data Item Descriptions (DIDs) for required documents · Use a metrics program to track project progress and conformance to estimates	· Project Management · Reviews · Software Lifecycles · Software Configuration Management
Control	· Unknown acquirer's management visibility needs · Moderate cost and schedule risk	· Share metrics data with acquirer · Choose simplest life cycle to implement for a known problem · Documentation set in contract - unable to modify · Use C for new system: No language change	· Software Life Cycles · Metrics · Risk Management

4. TAILORING AN ORGANIZATION'S STANDARD SOFTWARE PROCESS - AN EXAMPLE SOFTWARE PROJECT

4.1 Introduction to the Example

This example illustrates the issues that need to be addressed to tailor an organization's standard software process to the needs of a specific project. It includes both a sample project scenario and a set of software process characteristics. The example project and process characteristics are highly simplified to help show how software processes can be tailored to the needs of a project.

4.1.1 Project Scenario

A software developer, known as XDEVEL, has been tasked to build an upgrade to one of the fighter aircraft used by the U.S. Air Force.

This aircraft needs to update its navigation system with Global Positioning System (GPS) capabilities. The GPS model chosen for this aircraft has been used in a similar application for a Navy aircraft, so it is considered to be an off-the-shelf item. Modifications to the GPS software will be required to integrate the GPS into the Air Force aircraft. Aircraft software will need to be written (and/ or modified) to support the following needs:

a. Integrate the GPS into the existing navigation system.

b. Display updated navigation information on the pilot's Head-Up Display (HUD).

c. Allow the pilot access to the modified navigation data through the Control Display Unit (CDU).

d. Communicate GPS information to ground control and to other aircraft in a mission. (No equipment upgrades are planned to support the increased communications requirements.)

The requirements for this modification are well known. The current navigation system and interface software for the aircraft is written in C, and due to the limited nature of the changes to the navigation software, no change in language will be required. MIL-STD-498 will be used as the software development and documentation standard for this acquisition.

The contractor that developed the GPS system for the Navy aircraft will make the GPS software modifications on a subcontract to XDEVEL. XDEVEL will provide a specification of the modification requirements to the subcontractor. This will reduce the cost and risk associated with modifying the GPS software.

XDEVEL has determined that about 9,000 SLOC will need to be developed and/or modified to implement this new capability in the aircraft. The condition of the existing navigation software is not known and the customer wants formal documentation, so it was assumed that the productivity for the development team will be about that of new development.

The acquirer will supply a System/Subsystem Specification (SSS), a System Design Description (SSDD), and an Operational Concept Document (OCD). The acquirer will modify the OCD during development to reflect the changing needs of the system.

The developer will be responsible for the following technical documents:

a. Software and Interface Requirements Specifications (SRS & IRS).

b. Software and Interface Design Descriptions (SDD & IDD).

c. Software test documents, including:

1. Software Test Plan (STP).

2. Software Test Description (STD).

3. Software Test Report (STR).

The developer will be responsible also for the following management and support documents:

a. Software Development Plan.

b. Software Transition Plan (STrP).

c. A Software Version Description (SVD).

This means that the software effort will take approximately 3.25 man-years over a period of 12 months. The development, test, and technical documentation effort will be approximately 2.25 man-years; the remaining 1.0 man-year will be dedicated to software project management, the support documents, SQA, and SCM. User documentation will be produced as part of the new CDU development effort. The GPS subcontractor will develop the SRS and SDD for the GPS from existing materials created for the Navy.

The pilots for this aircraft dislike the CDU and want a replacement. The current CDU has a very small keypad, and the display is only 4 lines by 40 characters. The pilots would like to at least double the display capacity, increase the display visibility, change the keypad, and add new query capabilities. The pilots want an opportunity to help determine the requirements for the CDU and to have significant inputs to the changes to the user interface.

Since the pilots want so much input to the new CDU, XDEVEL feels that prototyping will be useful to support the user interface development. Also, it is not known how many new capabilities will be added to implement the pilots' query requirements.

XDEVEL is assuming that the new CDU will have all new software. The Air Force wants the new CDU to be implemented in Ada, and the existing code is in assembly language so it is assumed that there will be no software code reuse. MIL-STD-498 also will be used for the CDU development, and as with the GPS integration, the customer is requesting significant amounts of formal documentation.

Based on XDEVEL's knowledge of the existing CDU and a rational appraisal of the possible new requirements, XDEVEL assumes that the new CDU will require about 20,000 SLOC to implement. Given the unknown nature of the new requirements, this is a soft estimate. The customer wants the new CDU to be a significant improvement from the current version, so there may be some flexibility to renegotiate the terms of the contract when the first sets of prototypes are completed and approved by the pilots.

In both parts of this aircraft upgrade, software supportability is a primary concern for the customer. Thus, planning for the software transition to the Government and for Post Deployment Software Support (PDSS) is stressed in the acquisition. This may add labor to the existing software estimates from XDEVEL.

This report uses the GPS example. The CDU example is described for the reader to use to explore the process tailoring concepts independently.

4.1.2 Introduction to the XDEVEL Standard Software Process

XDEVEL is a respected, successful development organization. The organization has a well defined, flexible process for planning for and developing software. It is known also as being an open and innovative place to work. XDEVEL received its CMM assessment as a Level 3 organization approximately one year ago.

Early software project planning is stressed, and the plans are developed to integrate effectively with the other engineering plans for each project. There is strong communication among all the engineering disciplines, and each new project is managed from an integrated system view.

The software development plans are reviewed and approved by all affected engineering groups and upper management before implementation. Software estimates are derived through expert analysis and documented for use throughout the project's life. These estimates are backed up with outputs from estimation tools that are used to give a "reality check" to the experts' initial ideas. Actual project data is retained to support an estimation improvement effort under way at XDEVEL.

Software project management metrics are used to provide visibility into project performance. When performance deviates from the initial plans, the project manager is responsible for either making changes to the way the project is being handled to bring the project back into conformance with the plan or replanning, as necessary. Software subcontracts are managed using a set of defined policies and procedures.

Software requirements, design, and code inspections are used to support development. Defect metrics from the inspections are maintained. Other product related metrics are identified and maintained for each development effort to help keep reasonable visibility into the development effort. These metrics also are used to support software project management and risk assessment.

SQA and SCM are part of all software development and maintenance efforts. Metrics from SQA product and process audits are used to help improve product quality and software process efficiency. SCM is used both in its classical role and as a support mechanism for software requirements management.

All software engineering personnel have and maintain a personal training plan that helps them keep up-to-date on their requisite engineering skills. Based on project needs, extra training may be required for special needs.

XDEVEL has three basic software life cycles that are approved for use within the organization. They are: waterfall; incremental development, which uses a basic waterfall within each "block release cycle" for an evolving product; and a spiral model that relies heavily on prototyping for the first iteration or two through the spiral. Alternatives to these life cycles are allowed as long as the alternatives are documented and approved by upper management and the SEPG. The "approved" engineering processes for XDEVEL are maintained on-line for easy access.

Testing also has defined processes from the unit level through to software system testing. All testing that comprises the formal qualification testing is performed by independent test personnel.

During the last three years, XDEVEL has implemented a "lessons learned" policy that requires that at the end of a software project, the project team meets to discuss the successes and problems encountered during project execution. The lessons learned are documented and maintained to help new projects avoid problems and to support software process improvement. The lessons learned, metrics data, approved software and management processes, and other useful information is maintained in a software engineering library for the corporation. Much of the information is accessible on line. The information that exists only in hard copy is catalogued and referenced in the on-line library. All information about each project is cross referenced for easy retrieval. SCM developed and maintains the library.

A team of engineers and managers from the software engineering organization are responsible for maintaining the building blocks in a library, keeping the approved software management and engineering processes up to date, and identifying new opportunities for improvement. This team reports to the manager of software engineering and to the corporate vice president of engineering. The vice president of engineering maintains a keen interest in the software engineering processes for the corporation. The manager of software engineering and the vice president of engineering are responsible for providing quarterly reports to the company president on the state of software engineering and software process improvement.

3.4 Documenting the Project's Defined Software Process

3.4.1 Documenting the Tailoring Decisions in a Compliance Agreement

A compliance agreement typically is used within an organization to document a project's defined software process. This agreement documents the tailoring decisions derived through the process described in Paragraph 3.3. In general, compliance statements document tailoring decisions by exception using statements of the form: "Project X will conform with the organization's standard software process except for the following provisions."

A waiver is generated when required building blocks are deleted from the project's defined software process, when the contents of any building block(s) are modified in significant ways (as defined for each organization), or when new or previously unapproved building blocks are used in a project's defined software process.[7] When reviewing waiver requests, it is important to ensure that measurement is not deleted from the project's defined software process. Measurement helps ensure that the organization will have visibility into the software project for project oversight, product tracking, and process compliance.

The compliance agreement is reviewed and approved by managers who have the authority to grant tailoring decisions for the organization's standard software process and/or, typically, the SEPG. The compliance agreement then forms the process-related foundation for the software development plan.

3.4.2 Documenting the Project's Defined Software Process in a Plan

The final step in documenting the project's defined software process is to record the process in a software development plan. Both military and commercial standards provide templates for software development plans. An organization usually chooses (or develops) a software development plan template and uses the template as a standard outline.[8]

Three items that help with the plan are Work Breakdown Structures (WBSs), schedules, and activity networks. These items support the evolution of the plan, and ultimately become part of it. When the work is identified and defined in the WBS, schedule, and activity network, the software development plan can be completed based on the work definitions, the process to be implemented, and the resource plan for project completion.

3.4.2.1 Organizing the Work

The work to be done usually is organized into work packages that are mapped into a WBS [LAKE93]. A WBS traditionally was used as a cost-reporting structure, but it is more effective when used as a road map for managing a project. A WBS has two parts: a product part and a process part. The product part is defined through the breakdown of a system into subsystems, configuration items, and other subelements of the system. The product is usually defined top down through the WBS. Processes are defined to support each level of the product breakdown. The processes usually are shown as an activity-based decomposition of the product at a level that will be defined and managed as a project. Each level of the WBS shows more detail concerning parts of the product and the processes that will be executed to produce (or support) the product (from the system level down to the smallest subelement identified on the WBS). When shown as a block diagram, as in the simplified example in Figure 3-3, the WBS can provide a decomposition of the products and processes at whatever level is required to develop, produce, and support a system. Guidelines for building a software project WBS follow (derived from [LAKE93]):

a. Show all software project work at a level that can be used for software project tracking and reporting. The WBS must provide the information that allows the project manager to extract progress measurement (technical, cost, and schedule) for the project's required status reporting.

b. Include products, events (e.g., reviews and audits), and processes (e.g., software qualification) that will show visibility into software development, testing, deployment, training, and life cycle support (as required).

c. Assign WBS elements so that they can support risk assessment, engineering change proposal evaluation, contract change evaluation, interface management, data management, and configuration control.

d. Provide the ability to extract costs for separate types of software work effort (e.g., prototype, full scale development, maintenance).

e. Ensure that the WBS is compatible with the available project resources (e.g., staff) and organization (e.g., independent qualification testing).

Additional guidance on constructing and using a WBS can be found in MIL-STD-881B.

Figure 3-3. Simplified example software WBS.

3.4.2.2 Documenting the Schedule

The most popular representation of a project schedule is in the form of a Gantt chart. This form provides a visual description of the duration and sequence of project activities. (Figure 3-4 shows a Gantt chart that reflects the WBS presented in Figure 3-3.) Schedules like this one depict the time ordering of events but lack the ability to show interrelationships and dependencies explicitly. When kept updated with progress information, the project schedule provides inputs for specific forms of project tracking such as earned value and the Cost and Schedule Status Report (CSSR).

Figure 3-4. Example software schedule with WBS elements.

3.4.2.3 Developing the Activity Network

When the schedule is related to the WBS, as in Figure 3-4, the schedule sequence begins to show possible relationships and dependencies among project activities. These relationships and dependencies are shown explicitly in an activity network like the one shown in Figure 3-5. Activity networks are an outgrowth of the Project Evaluation and Review Technique (PERT) and the Critical Path Method (CPM) which, in addition to showing time dependencies, highlight sequence dependencies on a critical path. The value of showing an activity network with the critical path is that activities that rely on other activities for completion and/or have special time or resource limitations are highlighted for management tracking and oversight.

3.4.2.4 Completing the Software Development Plan

Section 3.3 identified four options for using individual process building blocks for a specific project. For each option, the following rules should be applied to document the project's defined software process in the software development plan:

a. When using a building block as is, reference it from the plan rather than repeating it to ensure the project's consistency with the organization's standard software process.

b. When a building block needs to be tailored, apply the specific guidance from the compliance agreement, and either

1. Document the exceptions to the building block in the plan, or

2. Rewrite the building block in the plan and explicitly mark the modifications.

Also, reference the compliance agreement in the plan.

Figure 3-5. Example activity network.

c. When a building block is waived, note in the applicable paragraph of the plan that the building block is "not applicable" and reference the compliance agreement.[9]

d. When a building block is replaced by a nonstandard building block, write the replacement building block in the plan at the applicable paragraph or reference the replacement building block.[10] Also, reference the compliance agreement in the plan.

The project's defined software process is documented or referenced in the software development plan. In general, software development plans present software process information in a logical order. Table 3-3 is a two-level table of contents for a software development plan based on the requirements of MIL-STD-498. This software development plan is organized as follows:

a. An introduction to the system and the document. (Section 1)

b. References. (Section 2)

c. Project information, constraints, and external requirements. (Section 3)

d. An overview of the software process and general plans for the project. (Section 4)

e. Detailed process descriptions for the software project, i.e., the project's defined software process. (Section 5)

f. Details of the schedule and activity network. (For clarity, the schedule and activity networks should be tied to the WBS.) (Section 6)

g. Project organization and resource information, e.g., organization charts, personnel, facilities, etc. (Section 7)

Table 3-3. Example SDP Table of Contents.

1. SCOPE 1.1 Identification 1.2 System Overview 1.3 Document Overview 1.4 System Overview 2. REFERENCE DOCUMENTS 2.1 Government Documents 2.2 Non-Government Documents 3. OVERVIEW OF REQUIRED WORK 3.1 System and Software Requirements and Constraints 3.2 Project Documentation Requirements and Constraints 3.3 Project Position in the System Life Cycle 3.4 Selected Program/Acquisition Strategy or Associated Requirements and Constraints 3.5 Project Schedule and Resource Requirements and Constraints 3.6 Other Requirements and Constraints 4. PLANS FOR PERFORMING GENERAL SOFTWARE DEVELOPMENT ACTIVITIES 4.1 Software Development Process 4.2 General Plans for Software Development 5. PLANS FOR PERFORMING DETAILED SOFTWARE DEVELOPMENT ACTIVITIES 5.1 Project Planning and Oversight 5.2 Establishing a Software Development Environment 5.3 System Requirements Analysis 5.4 System Design 5.5 Software Requirements Analysis 5.6 Software Design 5.7 Software Implementation and Unit Testing 5.8 Unit Integration and Testing 5.9 CSCI Qualification Testing 5.10 CSCI/HWCI Integration Testing 5.11 System Qualification Testing 5.12 Preparing for Software Use 5.13 Preparing for Software Transition 5.14 Software Configuration Management 5.15 Software Product Evaluation 5.16 Software Quality Assurance 5.17 Corrective Action 5.18 Joint Technical and Management Reviews 5.19 Other Software Development Activities 6. SCHEDULES AND ACTIVITY NETWORK 7. PROJECT ORGANIZATION AND RESOURCES 7.1 Project Organization 7.2 Project Resources

The WBS, schedule, and activity network show the process relationships and the implementation sequence to be used for the project, as shown in Figures 3-3 through 3-5; they provide the basis for measuring project progress in relationship to the project plans. In its totality, the software development plan provides the foundation for measuring project progress, processes, and products.

3. TAILORING THE ORGANIZATION'S STANDARD SOFTWARE PROCESS

3.1 Introduction to Tailoring

Software projects have unique requirements. The products (or modifications to products) that result from a project generally are unique. Traditionally, the unique aspects of a project rather than a common set of building blocks has been the driving force behind software development planning. This focus often translates to using different sometimes conflicting processes for projects within a single organization, which means that the lessons learned in how to "do business better" for a given project can be very difficult to apply to new projects.

One of the factors that supports developing and using an organization's standard software process is that using common building blocks for all projects within the organization will help make planning and management easier through supporting the use of materials, methods, lessons learned, etc., from previous projects. Still, given the unique nature of most software projects, some tailoring needs to be made to the organization's standard software process to apply it to almost any new project. The steps used to tailor the organization's standard software process to the needs of a specific project will be somewhat different for each organization. In general, however, the following concepts can be used to help think through how to develop a project's defined software process.

New software project definitions often include the following information:

a. Project goals.

b. Project technical work requirements.

c. Performance requirements and standards.

This information is combined with the organization's inputs and external inputs, such as:

a. The organization's business goals,

b. The organization's standard software process,

c. Rules for tailoring the organization's standard software process,

d. Acquisition regulations, and

e. The acquisition organization's management philosophy,

to develop the project's defined software process. In its simplest form, tailoring an organization's standard software process to a specific software project can be thought of as shown in Figure 3-1.

Figure 3-1. Tailoring an organization's standard software process (overview).

Previous work in tailoring processes and standards has identified "axes for tailoring" organization's standard software processes [GINS95] that include formality, accuracy, scope, precision, and complexity and "key areas to tailor" for DOD-STD-2167A [MAIB94] that include documentation, product requirements, formal reviews, testing, and customer approval.

This report confines tailoring to a small, focused set of areas that have a high payoff in terms of cost and schedule. The areas that provide a focus for the tailoring method described in this report are:

a. Project Size and Complexity.

b. Formality.

c. Control.

3.2 Identifying Project Characteristics

Often, the answers to the questions in Table 3-1 can help define the characteristics of a project to the level of detail required to make informed tailoring decisions. Table 3-1 is roughly divided into three groups of questions to correspond with the three high payoff areas.[4] The development manager is expected to answer all the questions with rough order of magnitude answers before proceeding to the next tailoring step.

Once the project's characteristics are quantified at this level, the next step in tailoring the organization's standard software process to the needs of a project is to choose and tailor the process building blocks that will be used for the project.

3.3 Choosing and Tailoring the Building Blocks

Choosing and tailoring building blocks for a specific project is a two-step process. Step one involves selecting the appropriate building blocks from the inventory. This step involves adherence to some basic options for using individual building blocks, usually based on organizational policy, such as the ones that follow:

a. Some building blocks are always implemented as is.

b. Some building blocks may be tailored according to a set of guidelines. (Specific rules need to be documented for each tailorable building block. Generally, the guidelines will state whether the building blocks may be altered or whether only parts of the building blocks may be used.)

c. Some building blocks may be waived with appropriate approval.[5]

d. Some building blocks may be replaced with appropriate approval.

e. New building blocks may be added with appropriate approval.[6]

In all cases, the customer's needs and management philosophy provide major inputs to the tailoring decisions.

Step two involves tailoring the individual building blocks. The project characteristics, including technical and acquisition requirements, are the primary inputs needed to choose and tailor the correct set of building blocks for the project. Paragraph 3.3.1 defines the general approach to tailoring, and Paragraph 3.3.2 discusses making detailed tailoring decisions based on the project characteristics identified inTable 3-1.

Table 3-1. Sample project characteristics.

Characteristic	Quantification
Size and Complexity:
Software Product (estimated SLOC or FP)	.
Documentation (estimated # of pages)	.
Development Team (estimated # of people)	.
System Product Mix:
Number of HWCIs	.
Number of CSCIs	.
Number of Interfaces (External)	.
Type of Software (Command & Control, Embedded, MIS, ATE)	.
Type of System (Centralized, Distributed, etc.)	.
Intent (Feasibility study, research, operational system, incrementally developed operational system, upgrade to an existing system, etc.)	.
Criticality (Life Critical, Safety Critical, etc.)	.
Users
Number of Users	.
Type of Users	.
Local or Distributed	.
Number of Installations	.
Life of Product (Number of months or years)	.
Upgrade Interval	.
Formality
Development requirements	.
Formal reviews and audits	.
Formal approval of deliverables and baselines	.
Control
Management visibility level required
Development Organization	.
Acquirer Organization	.
Project Risk Management
Cost	.
Schedule	.
Technical	.
Key: ATE - automatic test equipment CSCI - computer software configuration item FP - function points HWCI - hardware configuration item MIS - management information system SLOC - source lines of code

3.3.1 The Tailoring Process

Tailoring rules are part of the organization's standard software process building blocks as shown in Figure 2-1. These rules provide directions on how to tailor the specific building blocks that comprise the organization's standard software process to the needs of a project. As previously mentioned, some of the building blocks always will be used, e.g., project management, SCM, etc. Other building blocks may be used only as required, e.g., peer reviews may only be required for projects with greater than three developers. Figure 3-2 expands on Figure 3-1 to show the basic steps required to tailor an organization's standard software process to the needs of a specific software process.

As shown in Figure 3-1, project information, organization inputs, and external inputs are all needed to tailor a software process for a specific project. Figure 3-2 shows that these inputs are required to identify the characteristics of the project. Then, in addition to the project characteristics identified during the first step of tailoring, subsets of the information shown in Figure 3-1 are needed as inputs to choose and tailor the correct set of building blocks for the project.

Figure 3-2. Tailoring a process for a software project.

For example, the building blocks that comprise the organization's standard software process and the rules for tailoring the building blocks to the needs of a project are the organization inputs required to help derive the project's defined software process.

3.3.2 Making Tailoring Decisions

Tailoring an organization's standard software process takes guidance from the organization's tailoring rules, information about the incoming project, knowledge of the requirements used by the acquisition organization, and software project management experience to make informed decisions. As an organization begins tailoring its standard software process, it is important to use experienced individuals to help mold the tailoring process and provide guidance as new project managers become involved with incoming projects. This will help reduce the amount of confusion and rework that often accompany an organization's first attempts at modifying/tailoring their processes for the needs of a project.

Table 3-2 provides examples of tailoring guidance based on the information obtained by filling out the project characteristics form identified in Table 3-1. The tailoring process for individual building blocks (Step 2) is as follows:

a. Quantify the project characteristics identified in Table 3-1.

b. Interpret the quantification of the project characteristic using the heuristics identified in Table 3-2 (or locally defined tailoring rules).

c. Identify the set of building blocks to modify (or use part of), waive, or replace.

d. Decide on the exact tailoring decisions for each selected building block.

It is assumed that the building blocks that are not identified in the tailoring process will be used for the project without change.

When the tailoring process is complete, the project's defined software process is first documented as an agreement between the project team and the organization regarding how the organization's standard software process will be tailored for this project. Second, the software development plan is developed to reflect the process to be implemented on the project. These two topics are addressed in Paragraph 3.4.

Table 3-2. Example tailoring guidance.

Key Area	Quantification	Heuristics	Examples of Affected Building Blocks
Size and Complexity	Large and complex. Many hardware and software elements that need to interact. Generally built by many distinct organizations.	· Formalize requirements traceability and cross-organization communication. · Use standardized documents. · Where possible combine documentation and testing across organizations. · Share SEEs and tools across organizations.	· Software Lifecycles · Support Tools · Risk Management · Technical Documentation · Software System Test
	Application or installation critical.	· If additional safety requirements, plan a safety program using MIL-STD-882C Safety Standard as a guide. · Use reliability modeling and testing. · Use secure development and test environments (as applicable).	· Software Lifecycles · Reviews · Metrics · Technical Documentation · Unit Test · Software System Test
	Medium size and complexity. Some interfaces with other software. Coordination with other software projects required.	· If interim software but still operational, need to worry about reliability, availability, testing, etc.	· Requirements Management · Software Lifecycles · Technical Documentation · Reviews · Metrics · Unit Test · Software System Test
	Special purpose. Limited application. Small number of users. Essentially an independent prototype.	· If a throw-away, minimize documentation; use engineering notes only. · If small team, limit inspections. · No formal, independent testing. · No specific language requirements. · Still need SCM control, but with limited formality.	· Requirements Management · Software Configuration Management · Inspections · Software Lifecycles · Unit Test · Technical Documentation · Reviews · Metrics · Software System Test · Programming Languages · Project Management
Formality	Military Standards	· If a system upgrade or existing system replacement, should you change standards for the new software, e.g., from DOD-STD-2167A to MIL-STD-498?	· Risk Management · Reviews · Technical Documentation · Software Lifecycles · Software Configuration Management · Support Tools · Project Management
	Commercial Standards	· Know what to expect in advance.	· Possibly All Available for Tailoring
	Subcontractor Defined Standards	· Don't do it without fully understanding the subcontractor's standards and ensuring they meet the project's needs.	· Only the Building Blocks Affected by other Project Criteria
	Traditional Acquisition Requirements	· Use traditional reviews (e.g., PDR, CDR, etc.) using MIL-STD-1521B as a guide. · Use traditional project management rather than IPTs.	· Reviews · Software Lifecycles · Software Configuration Management · Project Management
	Integrated Products Teams	· Use in-process reviews and open developer/ acquirer relations and agreements.	· Reviews · Software Lifecycles · Technical Documentation · Software Configuration Management · Project Management
	Loose	· Don't do it, except for throw-away prototypes.	· Software Lifecycles · Metrics · Building Blocks Affected by Other Criteria
Control	Cost Risk(s)	· Minimize deliverable documents, formality of reviews.	· Reviews · Software Lifecycles · Technical Documentation · Project Management · Risk Management
	Schedule Risk(s)	· Choose simplest adequate life cycle. · Use parallel implementations. · Language choices e.g., 4GL/rapid prototyping. · Reduce documentation.	· Reviews · Software Lifecycles · Programming Languages · Technical Documentation · Project Management · Risk Management
	Technical Control and Risks	· If the problem and solution not well understood, choose either rapid prototyping, incremental deliveries, or evolutionary model. · If requirements expected to be unstable, plan for rework, provide metrics for requirements stability. · If the project will reuse legacy or reusable software, ensure strong SCM. · If the project is expected to produce reusable code, enforce coding standards and ensure strong SCM. · If technical risks, use prototyping or COTS as risk mitigation.	· Possibly All Available for Tailoring
Key: CDR - Critical Design Review COTS - Commercial-Off-The-Shelf 4GL - Fourth-Generation Language PDR - Preliminary Design Review SEE - Software Engineering Environment