Project Management for Mission Critical Systems

A Handbook for Government Executives


© 1997 The Information Technology Resources Board

Last edited June 1, 1998

---

About the ITRB

In July 1996, Executive Order 13011 established the Information Technology Resources Board (ITRB) to assist agencies in the procurement, development and management of major information systems. ITRB members are practitioners drawn from civilian and defense departments and agencies who bring management, technical, and acquisition perspectives to the table. Under the sponsorship of the Office of Management and Budget, the ITRB conducts independent peer assessments of selected Federal information systems. The ITRB’s activities promote measurable improvements in mission performance and service delivery to the public through the strategic application of information technology.

 

Members of the ITRB Mary Ellen Condon, Chair Kathleen Adams Sandra Borden Arnold Bresnick Tim Carrico Kevin Carroll Kay Clarey Mark Day Ken Heitkamp George Hyder Myron Kemerer Mike Laughon Jean Lilly Emory Miller Valerie Wallick ITRB Staff Jake Asma Sandra Hense Ginni Schaeffer

Department of Justice Social Security Administration U.S. Coast Guard Department of Labor Federal Aviation Administration U.S. Army Department of the Treasury Environmental Protection Agency U.S. Air Force Office of Personnel Management NASA Department of the Interior Internal Revenue Service General Services Administration U.S. Navy General Service Administration General Services Administration General Services Administration

 

About this Handbook

This handbook is derived from actual reviews of mission critical Federal information systems projects. It sets out a concise, high-level framework for project management. Within this framework is provided a series of practical suggestions for Federal executives involved in management of mission critical information systems.

The following pages are not intended to be exhaustive. Rather, they provide a quick, sensible overview of useful practices and tools for the effective management of information systems projects.

The ITRB is committed to results. We hope you find this handbook to be useful.

 

Mary Ellen Condon
Chair
Information Technology Resources Board

 

---

Contents

Executive Summary: Making Projects Work

Meeting the Mission

Align the Project Mission with the Agency’s Mission
Know the Project Stakeholders
Amplify the Voices of Your Customers
Maintain High-Level Communication About the Project Mission

Strategies

Set Realistic Business Objectives
Define a Sound Architecture
Gain Agreement on the Project Plan

People

Organizational Leadership
Project Leadership
Project Team Members

Processes

Planning
Managing Technology
Controlling Tasks

Appendix: Tools for the Toolbox

---

Executive Summary: Making Projects Work

Project management delivers results. The practice of project management can focus efforts on your mission by aligning priorities, leveraging resources, and delivering services to customers. A successful project translates a broad public mission into concrete results and outcomes. The following issues are critical for making projects work.

Meeting the Mission: Why are you undertaking this project in the first place? Who are the stakeholders and the customers? What are their expectations for the project? How does the project mission fit into your agency’s mission?

All activity on a successful project supports a well-bounded, agreed upon mission. As a project progresses, it is often necessary to take a step back and realign individual project elements with one another and with the project mission. Successful projects strike a balance among strategies, people, and processes.

Strategies: What do you want to accomplish with this project? Articulate the business objectives, the technical environment, and the project plan.

People: Who are the project participants, and how are they organized? Communicate with the organizational leadership, the project leadership, the team members, the stakeholders and the customers.

Processes: How will the project accomplish its objectives over time? Define the planning processes, the technology management, and the control of tasks.

Project management provides a proven way to set priorities and achieve results. Make use of project management to gain a realistic perspective on the "big picture," to maintain focus on priorities as they evolve, and to help sort out what must be done to make the project a success.

Table of Contents

Beginning of Document

Meeting The Mission It’s why you’re here Align the Project Mission with the Agency’s Mission What is your agency’s mission? What is the relationship of your project to your agency’s mission? Project activities need to support this mission. Know the Project Stakeholders A strong project mission can not be created in a vacuum. Who are the people with an interest in the outcome of the project? What are their common expectations? Stakeholders’ expectations are rarely spelled out in legislation, executive orders, or formal memoranda. Amplify the Voices of Your Customers Who will be paying for this project? Who will actually be using the systems and processes being designed? Clarify the business priorities of these customers and their criteria for success. Actively and emphatically communicate this information. Do this for customers inside the organization as well as those outside the organization. Maintain High-Level Communication About the Project Mission Communicate steadily with stakeholders and customers throughout the project. This will help to manage their expectations and requirements over time. Design project development so that requirements and expectations can be reconfirmed at regular junctures. Periodically check to see that stakeholders and customers understand and support changes, delays, and new developments. Table of Contents Beginning of Document Strategies What do you want to accomplish? Set Realistic Business Objectives What are the common business needs of the organizations that will depend on the system? What accomplishments will be critical for the project to be considered successful? Define project boundaries at the outset, and use this definition to manage requirements throughout the project. A clear definition of business success will also help ensure that project efforts support the agency’s strategic plan. Define a Sound Architecture Drive Toward an Enterprise-Wide Business Model Ensure that the business model meets business objectives while remaining within the project’s scope. Publish a detailed concept of operations which distinguishes clearly among the business model, the layout and relationship of systems and communications, and the technical architecture. These should be anchored in an enterprise-wide IT strategy. Implement Systems Incrementally Work toward a systems implementation that will deliver, in twelve months or less, incremental, useable levels of functionality which support specific business objectives. The detailed concept of operations should explain how the architecture will satisfy these objectives and how it will prioritize them. It should also communicate responsibilities for implementing and managing the architecture. Coordinate Technical Standards Which standards are essential to ensure that the technical architecture ultimately supports business objectives? Define these, paying particularly close attention to technical interfaces. Develop a plan to ensure compliance with architecture standards. The technical architecture must be documented to ensure its consistency with the overall agency-level design. Gain Agreement on the Project Plan The project plan formally captures and documents agreements among customers, stakeholders and project participants. Secure an informed agreement up front, and maintain this agreement throughout the project life. This will ensure that the project meets expected results. This will also help align the project with the organization’s business plans and supporting IT plans. Over time, manage the project scope carefully, since there will be a tendency for different areas of the project to acquire their own divergent momentum. Table of Contents Beginning of Document People Understand the project participants Organizational Leadership Listen to the Customer and Create a Vision The project sponsor manages high-level customer relationships, translating key customer expectations into a practical vision for the project. To be effective, this vision must be broadly communicated. Commit to the Project The most frequent cause of project failure is the lack of involvement of the organizational leaders. Ongoing involvement is crucial. It is critical to structure the project in such a way that go/no-go decisions may be made at highly visible milestones. Leadership commitment stabilizes the project so that it can accommodate changes over time. Leverage the Existing Organizational Structure The roles and responsibilities of the project and its partners are most effective when they correspond with the way in which the overall agency is managed. For example, in an organization in which field offices have a great deal of autonomy, a centralized approach to IT management could bring about unnecessary conflict. Empower the CIO The Chief Information Officer (CIO) position requires extraordinary qualifications in both IT management skills and general management skills. The CIO needs authority and visibility to guide the organization in key decisions. The CIO focuses on three things: Synergy. Bring realistic synergy to IT strategy by focusing disparate IT activities on their contribution to the organization’s mission. Ensure that business objectives take precedence over technological advances. Direct architectural compliance across the enterprise. Create a formal strategic IT plan that reflects business priorities. Sharing. Leverage the centralized technical authority to reduce redundancy across different organizational units. Enable them to share systems and data, as well as IT training, approaches, and other commonly needed resources. Coordinate a coherent strategy for commercial off-the-shelf software. Seek to make the enterprise technologically seamless. Support. Establish complementary managerial and technical structures to provide support for critical enterprise functions. Do this in a way that provides different organizational units with the flexibility they require. Project Leadership Select a Strong Project Manager Empower a central point of responsibility for project decisions, and clearly distinguish this role from functional program management roles. Clarify the risks which the project manager is expected to manage strategically. "Leadership ability" is difficult to articulate, and even more difficult to find. At a minimum, it includes the following characteristics: Drive. Does the project manager have a strong desire to succeed? Ability to Build Consensus. Can the project manager get key individuals to work together towards common ends? Ability to Take Risks. Can the project manager recognize opportunities and find ways to seize them? Ability to Communicate. Is the project manager able to communicate clearly and convincingly to all parties? Experience. Does the project manager have a track record of success? Look for characteristics and experiences that relate directly to the project at hand. Technical Knowledge. Does the project manager possess demonstrated knowledge in the appropriate technical fields? Sense of the Big Picture. Does the project manager understand the project from a broad business perspective? Enable a Cooperative Environment Nurture cooperation among members of the leadership, including the project sponsor, functional program manager, project manager, contracting officer and contractor. Create a learning environment which attracts individual skills to the table. Actively encourage team members to innovate by rewarding judicious risk-taking. Ensure Accountability The project manager is responsible for results. Successful project managers actively encourage team members to make minor challenges known before they become major problems. The project needs a "truth culture" – let the messenger live. Stress the importance of accountability by systematically introducing constructive criticism into current practices. One recommended technique is to outsource for independent validation and verification (IV&V) support. It is critical for the executive leadership to listen to IV&V advice. Another technique is to create an anonymous channel for reporting problems. Project Team Members Get What’s Needed to Succeed What are the competencies of the team? How does the staffing plan distribute these competencies against project tasks? Assess the team’s particular strengths, then get the additional expertise needed. There may be a need to outsource for additional skills to round out the team. Balance the mix of management and technical expertise, and the mix of contractor and government personnel. Distinguish between critical strategic activities and tactical activities. Make use of consultants to leverage the team’s capabilities. Keep the Core Team Together Maintain a commitment to the integrity of the core team. The project should include the project manager, the functional program manager, the contracting officer and other key players from project conceptualization through implementation. Empower a central point of responsibility for technical decisions, including standards and architecture. Monitor Team Productivity How does the level of effort contribute to project deliverables and results? How is the team progressing against the project plan? Perform periodic cost-benefit analyses and life cycle cost estimates. This information will be needed for go/no-go decisions at major project and contract milestones. Develop Competencies Over Time Invest in building competencies in key people. Institute and follow a formal plan for skills training and career development. Align the competencies of team members with the long-term needs of the project. Table of Contents Beginning of Document Processes Making it happen Planning Define Success Up Front Define project success in terms of specific business objectives. From the customer’s point of view, how should different business objectives be prioritized? Use Metrics to Focus On Outcomes Focus on outcomes rather than outputs. Prioritize the metrics for which project participants will be held responsible. Gain agreement on critical metrics and use them to drive planning and delivery. Integrate Planning Activities Across the Project Formalize planning processes. Assign roles and responsibilities specifically for planning-related activities. The CIO can help anchor project plans in the organization’s business and IT plans. Realign Plans Over Time How will plans need to be modified along the way? Make sure project plans continue to support intended business priorities. If the project encounters significant changes, then the original plans will have to be realigned to ensure desired results. Managing Technology Choose an Appropriate Development Model Base selection of a development model on careful consideration of four factors: Costs. Consider various development alternatives and estimate how they might contribute to project costs. Risks. Consider how much risk the project faces due to: High visibility due to public or political attention or requirements Highly compressed development time High uncertainty associated with the system’s requirements, the technology that the system will employ, or the way that the system will affect business processes Complexity. Consider the project to be complex if it: Affects many organizations or functional areas. Results from business process reengineering, dramatically altering the use of information technology. Requires new or rapidly advancing technology. Requires a long time for development. Type. Consider the general type of the project: A new development A modification of an existing system A system integration Select an Appropriate Life Cycle The life cycle provides an organizing structure with which to align project objectives with appropriate technologies and resources. Different projects require different degrees of rigidity in the sequencing of their phases. Long, complex projects intended to modify familiar systems typically yield to more rigid sequencing. On the other hand, less rigid sequencing may be required to achieve a series of innovations under conditions of high uncertainty. Deal with Shifting Priorities Business needs may change. All requirements must be formally managed. Address downstream changes in the life cycle through systematic risk assessment. Make Progress Visible to All Project participants need a clear idea of how well the project plan is working. Establish a set of key progress indicators and make them visible to all project participants. Know The Limits of Automation Don’t simply automate existing processes. Rethink existing processes instead of simply "paving the cowpaths." If your agency lacks the skills, use consultants to facilitate business process reengineering (BPR) and information modeling prior to defining requirements. Leverage Expertise in Established Management Areas Managing Inputs. Encourage project participants to address evolving technical priorities with appropriate resources. For example, employ contract incentives to deliver the desired results in accordance with the projected cost and schedule. Offer high incentives (18 - 20%) to in-house staff. Managing Activities. Use scope management techniques such as a Work Breakdown Structure (WBS) to organize project activities and tasks. Graphically display the work to be accomplished. Update the display periodically to reflect reality. Managing Outcomes. Encourage all staff to identify potentially problematic outcomes. Use formal risk management techniques to anticipate and mitigate project risks. Controlling Tasks Put Meaning in the Metrics Define requirements so that they may be thoroughly tested and validated at the unit and systems level of granularity. Identify frequent milestones with a defined set of measurable pass/fail performance criteria. Structure related contracts so that they reflect the same units, granularity, and milestones. This enables you to measure earned value throughout the contract life. These criteria should comply with a pre-established test plan. Leverage Expertise in Control Areas Controlling Inputs. Conduct life-cycle cost analysis to evaluate the impact of design implementation alternatives throughout the project. Use agreed upon plans to control the resources applied to the project. For example, periodically review actual project expenditures and compare them to the projected budget. Controlling Activities. Standardize processes which deal with the most routine activities. For example, routine progress reports can be structured to capture and highlight exceptions from anticipated progress. Controlling Outcomes. Use configuration management processes to ensure the project is building what the customer wants. The implications of changes along the way can be understood and incorporated while driving toward the desired result. Table of Contents Beginning of Document

One ITRB-reviewed project was situated within an agency which had recently undergone major budget reductions and large-scale structural changes. Because senior management was unclear about customer expectations, the agency had been unable to articulate a clear strategic view of the project and its role in the new environment. Customers had insufficient information to guide them in improving work processes. The ITRB recommended that the agency work with customers to accelerate development of a new strategic plan, and that it publish a concept of operations to communicate how the system would operate in future years.   One ITRB-reviewed project reversed its declining fortunes by making substantial revisions to project requirements several years into the project. Project leaders had conducted an evaluation of requirements, leading to large but necessary reductions in both scope and requirements. Though initially disorienting, this reduction did much to stabilize the project, leading to a significantly improved outlook for project success.   The ITRB encountered a project which, after eight years of planning, had yet to define an architecture. The project had come to rely heavily upon the functional program knowledge of the technical contractor, and there were insufficient technical resources involved in crucial technology decision-making. The ITRB recommended that the organization establish technical requirements for deliverables, define modular delivery of specified interim products, monitor product delivery, and generally strengthen the role of contract management.     The architecture should provide a focal point for project definition and clarity. Indeed, ambiguity surrounding this fundamental concept may be a clue that your architecture requires attention. One ITRB-reviewed project exhibited a number of inconsistencies in its use of the term "architecture." This led to conflicting expectations when information about the architecture was disseminated among project participants. Upon closer inspection, the ITRB found that the architecture required broad realignment with the organization’s strategic plan and budget.       One ITRB-reviewed project had negligible high-level involvement on the part of its organizational leadership. It turned out that no single individual was accountable for providing such leadership. Among other things, this explained the absence of a formal planning process and clear business objectives. The ITRB encountered one project which had clearly identified the information needs of key stakeholders, but was having great difficulty prioritizing these needs. The centralized organization running the project simply did not have the resources or the authority to provide an enterprise-wide solution to all of its widely distributed lines of business. Among other recommendations, the ITRB noted the need to establish an agency-level CIO who could focus the project architecture on the most critical common needs of the different lines of business.   The Clinger-Cohen Act identifies four core competency areas for CIO’s: 1. Federal Information Resources Management · Policy and Organizational Knowledge · Information Resources Strategy and Planning · IT Acquisition 2. Capital Planning · IT Performance Assessment · Capital Planning and Investment Assessment 3. Change Management 4. Managerial/Technical · Professional Development and Training · IT Topics · IT Trends             Project leadership does not simply appear; it must be nurtured. Among all of the projects reviewed by the ITRB, those with the greatest chance for success were those which sought to grow and develop leadership competencies over the long run. Though many aspects of project management may be reduced to defined processes, the development of project management leadership competencies remains a difficult but worthwhile challenge.               One ITRB-reviewed project exhibited no partnership among functional program leaders, IT managers and contract managers. Significant confusion resulted among both contractor and agency employees as to who made key decisions. In the absence of cooperative leadership, critical analysis of functional requirements was seriously lacking. The ITRB recommended that the project not only clarify the respective roles of project team members, but that it reorganize its executive steering committee to make it truly accountable for all final project decisions. In the majority of reviews it has conducted, the ITRB has recommended that organizations immediately establish a process for independent validation and verification and that executives explicitly consider IV&V recommendations when making decisions. One ITRB-reviewed project found a significant shortage of staff on the agency management team. The ITRB recommended that the management team take all possible actions to expand its staff, concentrating on the addition of technical expertise in computer software and systems. The ITRB also recommended that contract personnel be more effectively used to provide project management support       One ITRB-reviewed project revealed a clear need to integrate IT planning across various organizational units involved in the project. A new business concept of operations required that IT processes be realigned to meet evolving demands. The ITRB recommended that the organization use experts in BPR and information modeling to facilitate the necessary process analysis and redesign                 One agency requested the ITRB review its enterprise-wide architecture. The agency appeared to lack a structured process for testing products within the architecture before placing them into use. The ITRB recommended a centralized test bed which would enable the agency to simulate new functionalities and assess them before placing them into service. One ITRB-reviewed project faced serious risk of failure due to recent major shifts in the agency’s mission. If carried out according to the original plan, the project would simply have automated certain processes which no longer made sense in the new environment. The ITRB recommended that the organization cease development of certain sub-systems, and retain consultants to facilitate high-level process redesign. The ITRB reviewed one project which had recently negotiated movement from a cost reimbursement contract to a fixed price contract. While the ITRB concluded that this was an appropriate step, it noted that the agency would need to consider more thoroughly the different risks entailed by the new contract incentives, and that it would need to balance the risk between the agency and the contractor. For example, the ITRB recommended that the agency tie progress payments to accomplishment of specific milestones.        One recently redesigned project lacked test and acceptance procedures for a large set of new technical requirements. The ITRB recommended that the agency establish test and acceptance procedures at frequent milestones consistent with the project’s work breakdown structure. It further recommended that the requirements be re-baselined, and frozen, in order to ensure an acceptable level of functionality.     The ITRB reviewed a project whose software development process was in a perpetual state of change. The ITRB recommended the establishment of configuration management baselines as well as cost and schedule baselines.

 

Tools for the Toolbox

DO YOU HAVE SUGGESTIONS AND COMMENTS ABOUT THESE TOOLS FOR THE TOOLBOX?
HAVE YOU FOUND ANY TOOLS THAT WE SHOULD CONSIDER ADDING TO THE TOOLBOX?
PLEASE SEND YOUR COMMENTS TO: JAKE ASMA, ITRB STAFF, OR CALL 202-501-2796.

---

The following tools were suggested as important additions:

• National Defense University/IRMC

• Decision Process Guidebook

---

Best Practices

DOD Software Program Managers Network

PO Box 2523
Arlington, VA 22202
(703) 521-5231
http://www.spmn.com/
spmn@aol.com

Federal CIO Council

http://www.cio.gov/
ciocouncil.support@gsa.gov
"Information Technology Investment ‘First Practices’ "
ftp://cio.gov/www/cio/firstpra.doc

General Accounting Office (GAO)

441 G Street, NW
Washington, DC 20548
(202) 512 - 3000
http://www.gao.gov/
documents@gao.gov

Key Managerial Competencies

Federal CIO Council

http://www.cio.gov/
ciocouncil.support@gsa.gov

Project Management Institute

130 South State Road
Upper Darby, PA 19082
http://www.pmi.org/
"Guide to the Project Management Body of Knowledge"
http://www.pmi.org/pmi/publictn/pmboktoc.htm

Training Resources

Defense Systems Management College

9820 Belvoir Road
Fort Belvoir, VA 22060-5565
(703) 805-3666
http://www.dsmc.dsm.mil/

Federal Acquisition Institute Online University

General Services Administration
18th and F Streets, NW
Washington, DC 20405
http://www.gsa.gov/staff/v/mvi/key.htm
acquisition@gsa.gov

George Washington University
Program in Project Management

Department of Management Science
Building AL
2101 F Street, NW
Washington, DC 20052
(202) 994-6145
http://www.sbpm.gwu.edu/Programs/mspm/index.htm

George Washington University
Staff Development Courses

Quality Management Resources
George Washington University
2011 Eye Street, Suite 200, NW
Washington, DC 20052
(202) 973-7670
http://www.gwu.edu/~qmr/qmr_html/qmr1.html
vsa@gwis2.circ.gwu.edu

1000 by the Year 2000 Program

General Services Administration
18th and F Streets, NW
Washington, DC 20405
(202) 208 -2780
http://www.itpolicy.gsa.gov/mkp/1kby2k/1x2intro.htm

GSA Trail Boss Program

General Services Administration
18th and F Streets, NW
Washington, DC 20405
(202) 219-2354 or (202) 501-1136
http://www.itpolicy.gsa.gov/mkp/trailbos/trailbos.htm

National Aeronautics and Space Administration
Program/Project Management Initiative

PPMI Program Officer
Headquarters Code FT
Washington, DC 20546
(202) 358-2182
http://www.hq.nasa.gov/office/codef/codeft/

USDA Graduate School

1400 Wilson Boulevard, Suite 1000
Arlington, VA 22209-2312
http://grad.usda.gov/
pubaffairs@grad.usda.gov

Performance Measurement

DOD Software Program Managers Network

PO Box 2523
Arlington, VA 22202
(703) 521-5231
http://www.spmn.com/
spmn@aol.com

Carnegie Mellon’s Software Engineering Institute (SEI)

4500 Fifth Avenue
Pittsburgh, PA 15213
(412) 268 - 5800
http://www.sei.cmu.edu/
customer-relations@sei.cmu.edu

---

Table of Contents

Beginning of Document

IT Policy On-Ramp

United States Federal Government Document.

Used by Permission.