Information Technology Project Planning Standards – 1.2                    Information Technology                   Projec...
Information Technology Project Planning Standards – 1.2TABLE OF CONTENTS1.   INTRODUCTION ...................................
Information Technology Project Planning Standards – 1.2     6.7        Schedule (Management Plan) ...........................
Information Technology Project Planning Standards – 1.21. IntroductionThis Information Technology Project Planning Standar...
Information Technology Project Planning Standards – 1.2discipline. Complementing that set of models is PMI’s Guide to the ...
Information Technology Project Planning Standards – 1.2      Stakeholder communication requirements and plan.      Selec...
Information Technology Project Planning Standards – 1.2The project plan’s key elements are graphically represented in Illu...
Information Technology Project Planning Standards – 1.2supporting realistic schedule and cost estimates. To support the “w...
Information Technology Project Planning Standards – 1.2       Work Breakdown Structure, WBS (Section 5.3.3.2)       Perf...
Information Technology Project Planning Standards – 1.25.1       Project Authorization (Charter) DocumentationProject auth...
Information Technology Project Planning Standards – 1.25.2      Project ScopeThe project scope defines all authorized work...
Information Technology Project Planning Standards – 1.2The architecture/engineering process analyzes, classifies, aligns (...
Information Technology Project Planning Standards – 1.2Non-Functional business requirements must be identified and defined...
Information Technology Project Planning Standards – 1.2                                                                   ...
Information Technology Project Planning Standards – 1.25.3.1 Scope Management PlanScope management identifies the project ...
Information Technology Project Planning Standards – 1.2includes the project cost estimates and baseline. This management s...
Information Technology Project Planning Standards – 1.25.3.6 Project Communication Management PlanCommunication management...
Information Technology Project Planning Standards – 1.2           Request for Proposal (RFP) and Others (RFI and RFQ)    ...
Information Technology Project Planning Standards – 1.2“Cost estimates are typically based on limited information and ther...
Information Technology Project Planning Standards – 1.25.5.1 Referencing Related DocumentsIf possible and appropriate, the...
Information Technology Project Planning Standards – 1.2      10. Appendices (Full Project Stakeholder Roles and Responsibi...
Information Technology Project Planning Standards – 1.2      3.          WBS Dictionary      4.          Approvals / Recor...
Information Technology Project Planning Standards – 1.2     1.6      Tools and Techniques Selected to Accomplish the Proce...
Information Technology Project Planning Standards – 1.2      4.3.1   Project Schedule (Baseline)      4.3.2   Project Netw...
Information Technology Project Planning Standards – 1.2                  4.9.6   Contract                  4.9.7   Contrac...
Information Technology Project Planning Standards – 1.2                  3.3.2   WBS Dictionary                  3.3.3   S...
Information Technology Project Planning Standards – 1.21.         Introduction     1.1      Purpose     1.2      Objective...
Information Technology Project Planning Standards – 1.26.9        Quality Management PlanFollowing is the recommended outl...
Information Technology Project Planning Standards – 1.2        2.2      Acquiring the Project Team        2.3      Project...
Information Technology Project Planning Standards – 1.2         4.1      Stakeholder Analysis               4.1.1   Needs ...
Information Technology Project Planning Standards – 1.2              3.4.1   Risk Ownership Assignment              3.4.2 ...
Information Technology Project Planning Standards – 1.2      4.1      FAR      4.2      Vehicles      4.3      Agency     ...
Information Technology Project Planning Standards – 1.2   15.         Logistics Considerations         15.1     Assumption...
Information Technology Project Planning Standards – 1.2   3.         EVM Implementation Activities        3.1      Project...
Information Technology Project Planning Standards – 1.27.1        Alternatives AnalysisFollowing is the recommended outlin...
Information Technology Project Planning Standards – 1.2      3.          Change Management Process            3.1      Gen...
Information Technology Project Planning Standards – 1.2            1.1      Purpose            1.2      Objectives      2....
Information Technology Project Planning Standards – 1.2      4.          Solution Overview            4.1      Patterns fo...
Information Technology Project Planning Standards – 1.2            2.1      Assumptions            2.2      References    ...
Information Technology Project Planning Standards – 1.2     4.7      Test Metrics5.         Test Methodology     5.1      ...
Information Technology Project Planning Standards – 1.28. Prepared by         __________________________________         F...
Upcoming SlideShare
Loading in …5
×

IT Project Planning Standards V 1.2

1,309 views

Published on

Standards Document for IT Project Planning artifacts.

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,309
On SlideShare
0
From Embeds
0
Number of Embeds
9
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

IT Project Planning Standards V 1.2

  1. 1. Information Technology Project Planning Standards – 1.2 Information Technology Project Planning StandardsAuthor: Faisal AhmedMission Area: PlanningProcess: StandardsVersion ControlVersion Date Author Change Description1.0 11/25/2011 Faisal Ahmed Initial version1.1 01/10/2012 Faisal Ahmed Content Update1.2 01/12/2012 Faisal Ahmed / Danielle Integrated input from Danielle Smith and Smith / Colleen Hageman Colleen Hageman Page 1
  2. 2. Information Technology Project Planning Standards – 1.2TABLE OF CONTENTS1. INTRODUCTION ................................................................................................................................... 42. PURPOSE ............................................................................................................................................. 43. DESCRIPTION AND CATEGORY ........................................................................................................ 44. STANDARDS ........................................................................................................................................ 4 4.1 Standard Reference ................................................................................................................ 4 4.2 Standards Definition .............................................................................................................. 55. GENERAL GUIDANCE ......................................................................................................................... 6 5.1 Project Authorization (Charter) Documentation ............................................................... 10 5.2 Project Scope ........................................................................................................................ 11 5.2.1 Product Scope .............................................................................................................. 11 5.2.2 Project Management (PM) Scope ................................................................................. 13 5.3 Integrated Management and Control Plan ......................................................................... 13 5.3.1 Scope Management Plan ............................................................................................. 15 5.3.2 Schedule (Time) Management Plan ............................................................................. 15 5.3.3 Cost (Budget) Management Plan ................................................................................. 15 5.3.4 Quality Management Plan ............................................................................................ 16 5.3.5 Project Human Resource Management Plan ............................................................... 16 5.3.6 Project Communication Management Plan .................................................................. 17 5.3.7 Risk Management Plan ................................................................................................. 17 5.3.8 Procurement Management Plan ................................................................................... 17 5.4 Project Baselines (Schedule and Costs Estimates) ......................................................... 18 5.4.1 Schedule Estimate ........................................................................................................ 18 5.4.2 Cost (Budget) Estimate ................................................................................................. 18 5.5 Supporting Documentation ................................................................................................. 19 5.5.1 Referencing Related Documents .................................................................................. 206. RECOMMENDED OUTLINES FOR PLANNING DOCUMENTS ....................................................... 20 6.1 Project Authorization (Charter) ........................................................................................... 20 6.2 Scope Statement (Product and Management Scope) ....................................................... 21 6.3 Work Breakdown Structure (WBS) ..................................................................................... 21 6.4 Performance (Measures) Baseline ...................................................................................... 22 6.5 Integrated Management and Control Plan (Master Project Plan) .................................... 22 6.6 Scope Management Plan ..................................................................................................... 25 Page 2
  3. 3. Information Technology Project Planning Standards – 1.2 6.7 Schedule (Management Plan) ............................................................................................. 26 6.8 Cost (Budget) Management Plan ........................................................................................ 26 6.9 Quality Management Plan .................................................................................................... 28 6.10 Staffing (HR) Management Plan .......................................................................................... 28 6.11 Communication Management Plan ..................................................................................... 29 6.12 Risk Management Plan ........................................................................................................ 30 6.13 Procurement Management Plan / Acquisition Plan .......................................................... 31 6.14 Earned Value Management Plan ......................................................................................... 337. SUPPORTING DOCUMENTATION .................................................................................................... 34 7.1 Alternatives Analysis ........................................................................................................... 35 7.2 Change Management Plan ................................................................................................... 35 7.3 Configuration Management Plan ........................................................................................ 36 7.4 Enterprise Architecture ........................................................................................................ 36 7.5 Solution Architecture ........................................................................................................... 37 7.6 Master Schedule ................................................................................................................... 38 7.7 Version Control Plan ............................................................................................................ 38 7.8 Test Plan ................................................................................................................................ 398. PREPARED BY ................................................................................................................................... 41 Page 3
  4. 4. Information Technology Project Planning Standards – 1.21. IntroductionThis Information Technology Project Planning Standards is a standards guide that establishes aplanning baseline for all the Information Technology Projects. This standards guide will beapplicable to all IT projects within the scope of the practicing organization(s).2. PurposeThis document summarizes the major elements and artifacts of a project management plan andhow they are developed. Although its use is not intended to be 100% prescriptive, it is intendedto offer a framework for organizing the project plan’s elements and artifacts. When an artifact isnot included, there should be some rationale given for its omission. This guide is a synthesis ofproject management best practices (see Standards) and the standardized practices in theUnited States and other countries directives on managing IT Projects.Through the optional independent Integrated Baseline Review (IBR) process, these standardsare used to evaluate and validate the project’s plans for quality, completeness and alignment tothe organization’s records of decisions and acquisition regulations. As per US OMB Circular A-11, an IBR or an external program assessment is a requirement for all Major Investments totransition from a planning phase to an execution phase.3. Description and CategoryThere are two types of Information Technology (IT) investments. An investment may containmore than one project and the project category is defined by the parent investment type.  Major: Major IT Investment means a program requiring special management attention because of its importance to the mission or function of the agency, a component of the agency, or another organization; has significant program or policy implications; has high executive visibility; has high development, operating, or maintenance costs; is funded through other than direct appropriations; or, is defined as major by the agency’s capital planning and investment control process.  Non-Major: All agency investments not considered "major" are "non-major.”4. Standards4.1 Standard ReferenceThese standards are based on the Project Management Institute (PMI), Project ManagementBody Of Knowledge (PMBOK), Third Edition, ANSI/PMI 99-001-2004; SEI- CMMI®; Office ofManagement and Budget (OMB) and key references come from the PMBOK’s Chapter 4.1 andGlossary.Two leading organizations—the Software Engineering Institute (SEI) and the ProjectManagement Institute (PMI)—have developed guidelines and models for managing projects thathave become widely accepted in both private industry and the public sector. SEI has developedthe Capability Maturity Model Integration (CMMI®)1, which is a set of integrated referencemodels that can be used to improve and appraise an organization’s ability to perform a1 CMM, CMMI, and Capability Maturity Model are registered in the U.S. Patent and Trademark Office. Page 4
  5. 5. Information Technology Project Planning Standards – 1.2discipline. Complementing that set of models is PMI’s Guide to the Project Management Body ofKnowledge (PMBOK®).2The SEI’s CMMI® provides a structured view of process improvement in a specific discipline(e.g., software engineering, systems engineering) across an organization. SEI states that a“focus on process provides the infrastructure necessary to deal with an ever-changing world andto maximize personnel and technology to be more effective.”3PMI‘s PMBOK® describes proven, as well as innovative and advanced practices for projectmanagement.4 PMI defines project management as, “the application of knowledge, skills, tools,and techniques to project activities to meet project requirements.”5 PMBOK® defines 39 projectmanagement processes that are mapped to five process groups (Initiating, Planning, Executing,Controlling, and Closing).International Organization for Standardization (ISO) 9000 is a family of standards for qualitymanagement systems and maintained by ISO, the International Organization forStandardization.Six Sigma is a disciplined, data-driven approach and methodology for eliminating defects(driving towards six standard deviations between the mean and the nearest specification limit) inany process.The Information Technology Infrastructure Library (ITIL) is a set of concepts and policies formanaging Information Technology (IT) infrastructure, development, and operations.4.2 Standards DefinitionThe project management plan defines how the project is initiated, planned, executed, monitoredand controlled, and closed. The project plan documents the collection outputs (artifacts) fromthe planning processes of the Planning Process Group. This includes:  Project management processes selected by the project management team.  Level of implementation of each selected process.  Tools and techniques descriptions selected to accomplish the selected processes.  Description of how the selected process will be used for the specific project.  Description of how work will be executed to accomplish the project objectives.  Description of how change will be monitored and controlled.  Description of how configuration management will be performed.  Description of how the performance baseline will be maintained and used.2 “PMI” and the PMI logo are service and trademarks registered in the United States and other nations; “PMP” and the PMP logo are certification marks registered in the United States and other nations;”PMBOK”, “PM Network” and “PMI Today” are registered in the United States and other nations.3 Guidelines for Process Integration and Product Improvement, SEI, 2003.4 ® A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition, Project Management Institute.5 Ibid. Page 5
  6. 6. Information Technology Project Planning Standards – 1.2  Stakeholder communication requirements and plan.  Selected project life cycle for multi-phase project.  Management reviews processes for content, extent, and timing to address open issues and pending decisions.The PMBOK glossary defines a project plan as a “formal, approved document that defines howthe project is executed, monitored and controlled. It may be summary or detailed and may becomposed of one or more subsidiary management plans and other planning documents.”5. General GuidanceThe project plan is used to:  Guide project execution.  Document project planning methodologies (rules) and assumptions.  Document project planning decisions regarding alternatives choices.  Facilitate communication among stakeholders.  Defines key management reviews as to content, extent, and timing.  Provide a baseline for progress measurements and project control.The project plan has several key elements, including:  Project Authorization (Charter)  Project Scope (that includes the product scope and project management scope)  Integrated Management Control Plan  Project Baselines (Schedule and Cost Estimates)  Supporting Documentation Page 6
  7. 7. Information Technology Project Planning Standards – 1.2The project plan’s key elements are graphically represented in Illustration 1, as: 6 Illustration 1: The Project Plan’s Key ElementsThe plan is a consistent and coherent document that guides the project’s execution. Threadedthroughout, the plan references outputs of the other planning processes (including strategicplanning artifacts). The project plan is the product of an iterative planning process. Forexample, the initial draft may include generic resource requirements and a sequence ofactivities; while the final versions of the plan will include specific resources information andexplicit activity dates.Project Management and Governance Commentary: For an organization’s Investment ReviewBoard (IRB) to make an informed decision, it is expected that the project plan is mature,6 Updated by Faisal Ahmed from Project Planning Standards – Originally by William Brimberry Page 7
  8. 8. Information Technology Project Planning Standards – 1.2supporting realistic schedule and cost estimates. To support the “why” a project should beallowed go from the “Development/Modernization/Enhancement (DME) Plan” phase to the“DME Develop” phase, the IRB’s decision depends on quality planning information. The matureplan is assessed for standards adherence and reasonableness via the Integrated BaselineReview process. In the context of integrated life cycle (ILC) techniques, the IBR must becompleted at the end of DME Plan phase, Illustration 2. 7 Illustration 2: Interior’s Integrated Life Cycle (ILC) and Project PlanningThe project planning process facilitates the development of a realistic mature project plan that isaccepted by the organization (bought into). Generally, the project management planningprocess produces the product scope, management scope, and cost & schedule estimatesleading to a mature project plan to be evaluated by an IBR.The major artifacts (PMBOK reference) that make up the plan include:  Project Authorization Statement or Charter (Section 4.1)  Project Management Approach or Strategy (Section 4.3)  Scope Statement (Section 5.2.3.1) o Activity Sequence Analysis/Network Diagram (Section 6.2)7 Updated by Faisal Ahmed from Project Planning Standards – Originally by William Brimberry Page 8
  9. 9. Information Technology Project Planning Standards – 1.2  Work Breakdown Structure, WBS (Section 5.3.3.2)  Performance (Measures) Baseline o Schedule Estimate (Selection 6.5.3) o Major Milestones (Section 6.1.3.3) o Cost Estimates (Selection 7.1.3.1) o Cost Baseline (Selection 7.2.3.1) o Performance Metrics  Integrated Management Control Plan  Scope Management Plan (Section 5.1.3.1)  Schedule (Management Plan) (Section 6.5.3.8)  Cost (Budget) Management Plan (Section 7.1.3.4)  Quality Management Plan (Section 8.1.3.6)  Staffing (HR) Management Plan (Section 9.1.3.3)  Communication Management Plan (Section 10.1.3.1)  Risk Management Plan (Section 11.1.3.1)  Procurement (and Contract) Management Plan (Section 12.1.3.1)Within the plan, special attention should be given to the Work Breakdown Structure (WBS)and Earned Value Management System8 (EVMS). The WBS is use as a planning and control& monitoring tool for all aspects of the project. EVMS is a set of integrated processes used forproject monitoring & control. EVMS processes include planning, organizing, authorizing,accounting and monitoring & control.The following sections describe and detail the key groupings of major artifacts of the projectplan:Section 5.1: Project Authorization (Charter) Documentation;Section 5.2: Project Scope;Section 5.3: Integrated Management Control Plan;Section 5.4: Project Estimates (Schedule and Cost Baselines);Section 5.5: Supporting (Background) Documentation; andSection 6 : Recommended outlines for various planning documents.8 American National Standards Institute (ANSI) Government Electronic Industry Technology Association (EIA)Earned Value Management Systems (EVMS) Standards, November 2006 Page 9
  10. 10. Information Technology Project Planning Standards – 1.25.1 Project Authorization (Charter) DocumentationProject authorization is documentation that officially recognizes the project and its formal start.By convention, the project authorization document is usually the Project Charter. The projectauthorization document is a relatively short document. Stating directly or by summarizedreference, the document should identify:  Business and business need(s). This may be the project’s mission statement that may summarize and/or reference more robust documents.  Proposed solutions (products and/or services) that address the business need. A proposed solution may be in the form of a statement of objective. A proposed solution may reference specific Federal or DOI standards and requirements for adherence.  Acquisition strategy addressing the business need. The acquisition strategy may explain how alternatives will be identified. An example of a proposed acquisition approach/strategy is: “first, perform market research of COTS of solutions, followed by project planning, selection, development, testing, and implementation.”  The authorized use of organizational resources for the project.  Project Manager (PM) and the PM’s authorities.The project authorization document is issued by the Program (Business) Executive of theproject at a level appropriate to the project needs. It authorizes the project manager to start theproject, manage the project, and to apply organizational resources for project activities. When aproject is performed under contract, the signed contract may serve as the vendor’s projectcharter.Formatting: When possible and appropriate, the project authorization section uses theInvestment or Program Charter or text from the Investment / Program Charter. If not, theauthorization section should summarize the organizational documentation that gives the projectauthority. For more formatting information reference Project Management Institute’s (PMI),Project Management Body of Knowledge (PMBOK), Third Edition, ANSI/PMI 99-001-2004. Page 10
  11. 11. Information Technology Project Planning Standards – 1.25.2 Project ScopeThe project scope defines all authorized work of the project. The project scope statement isbased on detailed product scope (orange sphere) and project management scope (magentasphere), Illustration 3. 9 Illustration 3: Project / Program ScopeThe product scope includes all technical outputs and work activities produced throughout thedevelopment phases of the systems life cycle (SLC), Illustration 1. The project’s managementscope includes the planning, monitoring, control and quality assurance work activities producedthroughout the project management life cycle, Illustration 1. Project scope is the output of thescope management processes.5.2.1 Product ScopeThe first body of work, product scope addressing “what is to be done,” is derived from thearchitecture/systems engineering process. Often the product scope includes the solutionsarchitecture that should align to the enterprise architecture (EA) or system engineering analysis,Illustration 4. 10 Illustration 4: Architecture/Systems Engineering Analysis derives Product Scope9 Updated by Faisal Ahmed from Project Planning Standards – Originally by William Brimberry Page 11
  12. 12. Information Technology Project Planning Standards – 1.2The architecture/engineering process analyzes, classifies, aligns (the respective referencemodels), documenting the business performance, business functions, business information,technical services and technical requirements. This process leads to the mature product scopethat may include the solutions architecture. In the project plan, the product scope collects thisinformation into one coherent document. Produced by other efforts, this information mayoriginate in other artifacts, including:  EA and Segment Architecture (including the Business Process Model)  Business Alternatives Analysis  Information and Records Management Plan (including the Logical Data Model)  Privacy Analysis11  FOIA Analysis12  508 Compliance Analysis13  Security Plan  Solutions Architecture (Use Cases, Component, Deployment and Operational Models)  Service and Technical Alternatives Analysis  Requirements (Functional and Non-Functional Business)Functional requirements are identified, defined and validated against business processes, usecases and the logical data model which should be in alignment; represented in Illustration 5. 14 Illustration 5: Product Scope-Requirement Alignments (Business Process ● Use Cases ● Data Model)10 Updated by Faisal Ahmed from Project Planning Standards – Originally by William Brimberry11 Not applicable in all Countries12 Not applicable in all Countries13 United States of America only14 Updated by Faisal Ahmed from Project Planning Standards – Originally by William Brimberry Page 12
  13. 13. Information Technology Project Planning Standards – 1.2Non-Functional business requirements must be identified and defined, adhering toOrganizational standards and national/local regulations (e.g., legal/political requirements).5.2.2 Project Management (PM) ScopeThe second body of work, project management scope addresses “What will get done”. (Seenext section: Integrated Management and Control Plan for process and activity details whichaddress “how it gets done”).The PM Scope includes all of the project’s management planning, monitoring & control andquality assurance events and deliverable. Examples of these events are scope validationexercises, quality assessment & assurance meetings, risk evaluation events, procurementplanning meetings, team orientation meetings, status and budget reports and project statuspresentations.In summary, the project scope includes all product and management (PM) work. Adhering toorganizational policy, all funded work must be “authorized” by the organization’s governing bodyor an Investment Review Board. The IRB performs the important capital planning andinvestments control’s (CPIC) portfolio decision-making function.5.3 Integrated Management and Control PlanThe Integrated Management and Control Plan addresses how the project’s management (PM)operates and why. It details the integrative management processes of:  Change management process and procedures,  Formal acceptance process,  Monitoring & controlling trigger mechanisms, and  How EVMS standards will be applied.This section details the management activities that contribute to the overall integratedmanagement plan. The management activities include:  Scope Management  Schedule (Time) Management  Cost (Budget) Management  Quality Management  Human Resource (Team) Management  Communication Management  Risk Management  Procurement (and Contract) Management Page 13
  14. 14. Information Technology Project Planning Standards – 1.2 15 Illustration 6: Integrated Management and Control PlanThe integration management processes include the 1) project plan development, 2) project planexecution, and 3) integrated change control. Pulling together all of the management practices,these process relationships are represented in Illustration 6. 16 Illustration 7: Integrated Management and Control PlanThe integrated management & control plan details the integration of all management activities.All sub-processes interact with each other.15 OLES Technology Division Project Planning Standards – By Faisal Ahmed16 Updated by Faisal Ahmed from Project Planning Standards – Originally by William Brimberry Page 14
  15. 15. Information Technology Project Planning Standards – 1.25.3.1 Scope Management PlanScope management identifies the project deliverables and all related work to be accomplished.It includes 1) product outputs and work activities and 2) all project management work activities.This management section summarizes how they will be/were determined, including the planningmethodology, assumptions and decisions. The scope management section underpins theverification and change control processes, including formal acceptance process. Key sub-artifacts produced in this section are:  Project Objectives  Product Scope (Functional & Non-Functional Business Requirements)  Management Scope (PM Scope)  Milestones and High Level Deliverables  Work Breakdown Structure (WBS)  WBS Dictionary  Organizational Breakdown Structure (OBS)  Scope Verification Criteria and Verification Procedures  Scope Management Control PlanManagement processes include: 1) scope planning, 2) scope definition, 3) create the WBS, 4)scope verification and 5) scope change control. Note: scope verification, a part of the formalacceptance process, is tightly coupled with integration and quality management’s acceptancecriteria.5.3.2 Schedule (Time) Management PlanTime management addresses the schedule issues and schedule needed complete projectobjectives. It includes the project schedule. This management section summarizes how it willbe/was determined, including its planning methodology, assumptions and decisions. Key sub-artifacts produced in this section are:  Project Schedule (Schedule Baseline)  Project Network Diagram  Other time artifacts (e.g., Gantt chart and milestone chart)  Updated WBS  Schedule Management Control PlanManagement Processes include the 1) activity definition, 2) activity sequencing, 3) activityresource estimating, 4) activity duration estimating, 5) schedule development, and 6) schedulecontrol.5.3.3 Cost (Budget) Management PlanCost management addresses the cost of the resources needed to complete project activities.Additionally, project cost management considers the effect of project’s decisions on theproduct’s overall costs, often referred to as the life-cycle costing or total cost of ownership. It Page 15
  16. 16. Information Technology Project Planning Standards – 1.2includes the project cost estimates and baseline. This management section summarizes howthey will be/were determined, including the planning methodology, assumptions and decisions.Key sub-artifacts produced in this section are:  Resource Requirements  Cost Estimating Methodologies (Ground Rules)  Assumptions17  Cost Estimates (Cost Baseline)  Updated WBS  Cost Management Control PlanManagement processes are 1) cost estimating, 2) cost budgeting, and 3) cost control.5.3.4 Quality Management PlanQuality management assures the product characteristics meet the stakeholders’ expectation.The plan defines how the process assures that the product characteristics will be realized tomeet the stakeholders’ expectation. It includes details of work quality. This managementsection summarizes how they will be/were determined, including the planning methodology,assumptions and decisions. Key sub-artifacts produced in this section are:  Quality Checklists  Quality Metrics  Quality Baseline  Process Improvement Plan  Quality Management Control PlanManagement processes include 1) quality planning, 2) quality assurance and surveillance, and3) quality control.5.3.5 Project Human Resource Management PlanHuman resource (HR) management addresses what appropriate human resources (internalstaffing and external contractors) are needed and how to use them to accomplish projectobjectives. It includes descriptions of the team members and (all) stakeholders. Thismanagement section summarizes how they will be/were identified, including the planningmethodology, assumptions and decisions. Key sub-artifacts produced in this section are:  Stakeholder Analysis  Role & Responsibility Assignments (Responsibility Assignment Matrix)  Project Organization Charts (and project directories)  Staffing Management Control PlanManagement processes include 1) human resource planning, 2) acquiring project team, 3) teamdevelopment, and 4) managing project team.17 See Section 5.4: Project Baselines (Schedule and Costs Estimates) Page 16
  17. 17. Information Technology Project Planning Standards – 1.25.3.6 Project Communication Management PlanCommunication management addresses how the project ensures timely and appropriategeneration, collection, dissemination, storage, and disposition of project information. It includesstakeholder communications requirements. This management section summarizes how theywill be/were determined, including the planning methodology, assumptions and decisions.Special attention should be given to earned value management (EVM) reporting section of thisdocument as an integrated practice to provide a list of key members (and the communicationchannels within and outward) for project control and performance reporting on a regular basis.Key sub-artifacts produced in this section are:  Control Data & Reporting Requirements  Performance Reporting Specifications  Communications Management Control PlanManagement processes include 1) communication planning, 2) information distribution, 3)performance reporting, and 4) managing stakeholders.5.3.7 Risk Management PlanRisk management addresses how risks are systematically identified, analyzed and responded tothroughout the project. It includes descriptions of the project risks. This management sectionsummarizes how they will be/were determined, including the planning methodology,assumptions and decisions. Key sub-artifacts produced in this section are:  Risk Inventory with Thresholds  Ranked and Prioritized Probability-Impact Matrix  Risk owner designation  Response Plan (with workarounds and corrective action plans)  Risk Management Control PlanManagement processes include 1) risk management planning, 2) risk identification, 3)qualitative risk analysis, 4) quantitative risk analysis, 5) risk response planning, and 6) riskmonitoring and control.5.3.8 Procurement Management PlanThe Procurement Management Plan addresses how goods and service are attained fromoutside the performing organization. It includes descriptions of the project procurementstrategies and actions. This management section summarizes how they will be/weredetermined, including the planning methodology, assumptions and decisions. Key sub-artifactsproduced in this section are:  Acquisition strategy  Statement of Objectives/Work (SOO/SOW) or Performance Work Statement (PWS)  Make-or-Buy decisions  Request for changes procedures  Product (Performance) acceptance criteria and procedures Page 17
  18. 18. Information Technology Project Planning Standards – 1.2  Request for Proposal (RFP) and Others (RFI and RFQ)  Contract  Contract change process  Contract Closure criteria and procedures  Procurement Management Control PlanManagement processes include 1) plan purchases and acquisitions, 2) plan contracting, 3)request seller responses, 4) select sellers, 5) contract administration, and 6) contract closure.5.4 Project Baselines (Schedule and Costs Estimates)5.4.1 Schedule EstimateThis section of the project plan details the risk-adjusted schedule baseline, estimate assumptionsand estimating methodologies. The schedule estimate is primarily the product of the Schedule(Time) Management processes.5.4.2 Cost (Budget) EstimateThis section of the project plan details the risk-adjusted cost baseline, estimate assumptionsand estimating methodologies. The cost (budget) estimates are primarily the products of theCost (Budget) Management processes.Particular attention must be given to the Government Accounting Office’s (GAO) CostAssessment Guide. “The objective of the technical baseline is to provide in a single document(artifact) a common definition of the program-including a detailed technical, program, andschedule description of the system-from which all life cycle costs estimates (LCCE) will bederived . . .”18Discussion19: “Developing a good cost estimate requires stable program requirements, accessto detailed documentation and historical data, well trained and experience cost analyst, a riskand uncertainty analyst, the range of confidence levels, and adequate contingency andmanagement reserves. Cost estimating is nonetheless difficult in the best of circumstances. Itrequires both science and judgment. And, since answers are seldom–if ever–precise, the goalis to find a ‘reasonable’ answer. However, the cost estimator typically faces many challenges indoing so. These challenges often lead to bad estimates, which can be characterized ascontaining poorly defined assumptions, no supporting documentation, no comparisons to similarprograms, inadequate data collection, inappropriate estimating methodology, irrelevant or out-of-date, no basis or rationale for the estimate, and no defined process for generating theestimate.”The WBS is the foundation of every project, because it defines in detail the work necessary toaccomplish the project objectives. A typical WBS and WBS Dictionary detail the requirements,resources, and tasks that must be accomplished. The WBS should be defined in terms of theproduct oriented elements. This is considered a best practice in cost estimating because aproduct oriented WBS ensures that all cost are captured.2018 United States GAO Cost Estimate Guide, GAO-05-1134SP, July 2007, Chapter 719 United States GAO Cost Estimate Guide, GAO-05-1134SP, July 2007, Chapter 220 United States GAO Cost Estimate Guide, GAO-05-1134SP, July 2007, Chapter 8 Page 18
  19. 19. Information Technology Project Planning Standards – 1.2“Cost estimates are typically based on limited information and therefore need to be bound bythe constraints that make estimating possible. These constraints are usually in the form of[ground rules and] assumptions that bind the estimate’s scope, establishing baseline conditionsthe estimate will be built from. Because of the many unknowns, cost analysts must create aseries of statements that define the conditions the estimate is to be based on. Thesestatements are usually in the form of ground rules and assumptions (GR&A).”Error! Bookmarkot defined. Ground rules are the agreed upon estimating standards (methodologies) thatprovide guidance and minimize conflicts in definitions. Assumptions are a set of judgmentsabout past, present, or future conditions postulated as true in the absence of positive proof.These assumptions are not arbitrary and should be based on expert opinion. They should betreated as risks.5.5 Supporting DocumentationThe supporting documentation can consist of additional plans as appropriate. Some of theSupporting Documents are:  Alternatives Analysis  Change / Configuration Management Plan  Enterprise Architecture  Solution Architecture  Master Schedule  Version Control Plan  Test PlanIn addition, the supporting documentation quotes, summarizes and/or references documentationthat gives more meaning, understanding, context, authority to the project plan. Supportingdocumentation may also include:  Mission or Strategic Plans.  Organizational Records-of-Decisions.  Budget and Capital Planning & Investment Control (CPIC) documentation.  Organizational Policies and Standards.  Legal Mandates and Legislation.  Technical and Management Standards.  Lessons Learned.  Business Issues Details (resulting in a formal project).  Project Manager’s and Team Credentials.  Prior Business and Technical Studies.  Business and Technical Alternative Studies.  Issues Paper on Business or Project Assumptions and Limitations. Page 19
  20. 20. Information Technology Project Planning Standards – 1.25.5.1 Referencing Related DocumentsIf possible and appropriate, the supporting documentation should be directly quoted. If not, alldocumentation should be accurately concisely summarized and authoritatively referenced. Ifavailable, all documentation may include authoritative internet addresses. All systems of recordsmust be registered with the Federal Registry and a Statement of Records Notice (SORN) mustbe publicly available. If the system contain or have the potential co contain any PersonallyIdentifiable Information (PII) data, the agency Privacy Officer must be contacted to ensure theprivacy protection requirements are either met or being addressed.6. Recommended Outlines for Planning DocumentsThe document outlines below are based on PMI, OPM, GAO and ANSI standards andrecommended for all projects. However recommendation not intended to be 100% prescriptive,it is intended to offer a framework for organizing the project plan elements and artifacts. If anartifact is not included, there should be some rationale given for its omission.6.1 Project Authorization (Charter)As mentioned previously, Office of Management and Budget (OMB) requires three differentcharters for every Major Investment. However OMB does not provide directions on how todevelop all of these charters. In order to minimize workload, the following outline can bemodified to accommodate these multiple charter requirements: 1. Charter Purpose (Investment or Program or Integrated Project Team) 2. Investment / Project Purpose 2.1 Project Vision Overview 2.2 Project Goals and Objectives 3. Project Scope 4. Proposed or Anticipated Solution 5. Project Conditions 5.1 Assumptions, Conditions and Exceptions (ACE) 5.2 Constraints 5.3 Project’s Success Criteria 5.4 Risks 5.5 Issues 6. Project’s Acquisition Approach / Strategy (Contracting Officer) 7. Project Authorization for Allocation and Use of Resources (including Human Capital) 8. Project Team Organization Plans 8.1 Team Composition 8.2 Project Manager’s Responsibility, Authority and Ownership 9. Approvals / Records of Decision (RoD) Page 20
  21. 21. Information Technology Project Planning Standards – 1.2 10. Appendices (Full Project Stakeholder Roles and Responsibilities Table, Full project Team’s Roles and Responsibilities Table, All working team’s Roles and Responsibilities Table, Applicable Legal and Reporting Requirements, Acronyms, etc.).6.2 Scope Statement (Product and Management Scope)Following is the outline for the project’s Scope Statement: 1. Product Scope Statement 1.1 Project Business Need 1.2 Project Objectives 1.3 Product Overview 1.4 Product Lifecycle Deliverables 1.4.1 Design Deliverables 1.4.2 Development Deliverables 1.4.3 Test and Validation Deliverables 1.4.4 Implementation Deliverables 1.4.5 Product Scope Requirements 2. Management Scope Statement 2.1 Lifecycle Management Plan 2.1.1 Integrated Management and Control Plan 2.2 Design Management Plan 2.3 Development / Integration Management Plan 2.4 Test and Validation Management Plan 2.5 Implementation Management Plan 2.6 Management Scope Requirements 2.7 Management Scope Analysis Summary 3. Approvals / Records of Decision (RoD)6.3 Work Breakdown Structure (WBS)Following is the outline for the Work Breakdown Structure and the WBS Dictionary: 1. Introduction 1.1 WBS Description 1.2 WBS Dictionary Description 2. Project WBS 2.1 WBS (Overall Summary Level) 2.2 WBS (Project Management Level) 2.3 WBS (Phase 1) 2.4 WBS (Phase 2)…………to all the phases Page 21
  22. 22. Information Technology Project Planning Standards – 1.2 3. WBS Dictionary 4. Approvals / Records of Decision (RoD) 5. Appendix (Acronyms, reference document listings, etc.)6.4 Performance (Measures) BaselineFollowing is the outline for the Performance (Measures) Baseline: 1. Introduction 1.1 Purpose 1.2 Project Description and Background 2. Estimates 2.1 Schedule Estimates 2.2 Cost Estimates 3. Baselines 3.1 Schedule Baselines 3.2 Cost Baselines 4. Milestones 4.1 Development Phases 4.1.1 Milestones 4.1.2 Deliverables (Every 3 to 6 Months) 4.2 Integration Phases 4.2.1 Milestones 4.2.2 Deliverables (Every 3 to 6 Months) 4.3 Operational Phases 4.3.1 Milestones 4.3.2 Deliverables (Every 3 to 6 Months) 5. Approvals or Records of Decision (RoD) 6. Appendix (Acronyms, reference document listings, etc.)6.5 Integrated Management and Control Plan (Master Project Plan)Following is the outline for the Integrated Management and Control Plan (IMCP) or MasterProject Plan (MPP): 1. Introduction 1.1 Purpose 1.2 Project Description and Background 1.3 Document Organization 1.4 Project Management Planning Process 1.5 Level of Implementation of Each Selected Process Page 22
  23. 23. Information Technology Project Planning Standards – 1.2 1.6 Tools and Techniques Selected to Accomplish the Process 1.7 Description of How Selected Process will be used for Project Planning 1.8 Stakeholder Communication and the Planning Process 1.9 Project Plan’s Management Review Process for Content, Extent and Timing2. Project Authorization 2.1 Project’s Business Needs 2.2 Project’s Objectives 2.3 Project’s Proposed Solution(s) 2.4 Project’s Acquisition Strategy 2.5 Project’s Resource Authorization 2.6 Project’s Resource Organization 2.6.1 Project Manager, Contact Information, and PM’s Authority 2.7 References to Project’s Charters3. Project’s Scope 3.1 Work Breakdown Structure (WBS) and Organizational Breakdown Structure (OBS) 3.2 WBS Dictionary 3.3 Product Scope Statement 3.3.1 Product Life Cycle Deliverables 3.3.2 Product Scope Requirements 3.3.3 Architecture/System Engineering Analysis Summary 3.4 Management Scope Statement 3.4.1 Development or Integration Management 3.4.2 Life Cycle Management Plan4. Integrated Management and Control Plan (IMCP) 4.1 Integrated Control Plan 4.1.1 WBS-OBS Description 4.1.2 EVMS Description 4.2 Scope Management Plan 4.2.1 Project Objectives 4.2.2 Product Scope 4.2.3 Project Management Scope 4.2.4 Scope Verification Criteria and Verification Procedures 4.2.5 Scope Management Control Plan 4.3 Schedule Management Plan Page 23
  24. 24. Information Technology Project Planning Standards – 1.2 4.3.1 Project Schedule (Baseline) 4.3.2 Project Network Diagram 4.3.3 Other Time Artifacts (Gantt Chart etc.) 4.3.4 Schedule Management Control Plan4.4 Cost Management Plan 4.4.1 Cost Management Plan Resource Requirements 4.4.2 Cost Management Plan Cost Estimating Methodologies 4.4.3 Cost Management Plan Cost Estimates (Cost Baseline) 4.4.4 Cost Management Control Plan4.5 Quality Management Plan 4.5.1 Quality Baseline 4.5.2 Quality Metrics 4.5.3 Quality Checklists 4.5.4 Quality Process Improvement Plan 4.5.5 Quality Management Control Plan4.6 Human Resource Management Plan 4.6.1 Stakeholder Analysis 4.6.2 Roles and Responsibility Assignments (Responsibility Matrix) 4.6.3 Project Organization Charts (and Project Directories) 4.6.4 Staffing Management Control Plan4.7 Communication Management Plan 4.7.1 Control and Data Reporting Requirements 4.7.2 Performance Reporting Specifications 4.7.3 Communications Management Control Plan4.8 Risk Management Plan 4.8.1 Risk Inventory with Thresholds 4.8.2 Ranked and Prioritized Probability-Impact Matrix 4.8.3 Response Plan (with Workarounds and Corrective Action Plans) 4.8.4 Risk Management Control Plan4.9 Acquisition Plan 4.9.1 Acquisition Strategy 4.9.2 Alternatives Analysis (Make or Buy Decisions) 4.9.3 Request for Change Procedures 4.9.4 Evaluation Criteria 4.9.5 Request for Proposal (RFP) and Others (RFI and RFQ) Page 24
  25. 25. Information Technology Project Planning Standards – 1.2 4.9.6 Contract 4.9.7 Contract Change Process 4.9.8 Formal Acceptance and Contract Closure Procedures 4.9.9 Procurement Management Control Plan 5. Project Baseline 5.1 Schedule Estimates 5.2 Cost Estimates 5.2.1 Independent Government Cost Estimate (IGCE) 5.2.2 Independent Cost Estimate (ICE) 6. Project Closure Procedures 6.1 Administrative Closure 6.2 Contract Closure 7. Supporting Documentations 8. Approvals or Records of Decision (RoD) 9. Appendix (Acronyms, reference document listings, etc.)6.6 Scope Management PlanFollowing is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Background 1.3 Scope 1.4 Product and Management Scope 1.5 Product Overview 1.6 Goals and Objectives 1.7 Assumptions and Decisions 2. Roles and Responsibilities 2.1 Governance Overview 2.1.1 Governance Authorities and Responsibilities 2.2 Project Team 2.3 Organizational Breakdown Structure 3. Scope management Activities 3.1 Scope Planning 3.2 Scope Definition 3.3 Creating the WBS and WBS Dictionary 3.3.1 WBS Page 25
  26. 26. Information Technology Project Planning Standards – 1.2 3.3.2 WBS Dictionary 3.3.3 Scope Baseline 3.4 Scope Verification 3.4.1 Scope Verification Procedure 3.5 Scope Management and Control 4. Approvals / Records of Decision 5. Appendix (Acronyms, reference document listings, etc.)6.7 Schedule (Management Plan)Following is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Assumptions 1.3 Objectives 2. Roles and Responsibilities 3. Scheduling Process 3.1 Schedule Planning 3.2 Schedule Estimation 3.3 Steps to building the Project Schedule 3.4 Estimating Activities and Resources 3.4.1 Estimating Activities (Control Account to Task levels) 3.4.2 Estimating Resources (By activities and Fiscal Years) 3.5 Schedule Baseline 3.6 Storage Process 3.7 Approval Process 3.8 Update Process 3.9 Staffing Matrix and Profile 3.10 Earned Value Management (EVM) Process 3.11 Variance Review and Analysis 3.12 Schedule Issues 3.13 Schedule References 4. Approvals / Records of Decision 5. Appendix (Acronyms, reference document listings, etc.)6.8 Cost (Budget) Management PlanFollowing is the recommended outline for this plan: Page 26
  27. 27. Information Technology Project Planning Standards – 1.21. Introduction 1.1 Purpose 1.2 Objectives2. Roles and Responsibilities3. Independent Government Cost Estimate 3.1 Overall Approach 3.1.1 Develop Cost Element Structure (CES) 3.1.2 Identify Cost Estimation Methodologies 3.1.3 Conduct Function Point Analysis 3.1.4 Other Cost Assumptions 3.1.5 Develop Life Cycle Cost (LCC) Model 3.2 Project General Assumptions 3.3 Life Cycle Cost Estimation Summary 3.3.1 Without Optimization / Customization / Enhancements (Base Cost) 3.3.2 Without Optimization / Customization / Enhancements (Optimal Cost)4. Project Budget 4.1 Budget Exclusions5. Project Accounting 5.1 Cost Variance Analysis 5.1.1 Cost Variance Response and Reporting Process 5.2 Inter-Agency Agreements 5.3 Reimbursable Services Agreements 5.4 Reporting 5.4.1 Monthly Expenditure Reporting 5.4.2 Quarterly Funding Status Reporting 5.4.3 Quarterly Cost Variance Reporting 5.4.4 Earned Value Reporting 5.5 Working Capital Fund 5.6 Cost Change Control Process 5.7 Risk Management Contract and Management Reserves 5.8 Resource (FTE and Staff Augmentation) Requirements Cost6. Associated Documents and Forms7. Approvals / Records of Decision8. Appendix (Acronyms, reference document listings, etc.) Page 27
  28. 28. Information Technology Project Planning Standards – 1.26.9 Quality Management PlanFollowing is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Background 1.3 Scope 1.4 Quality Goals and Objectives 1.5 Assumptions 2. Quality Management Methodology 2.1 Quality Planning 2.2 Quality Assurance 2.2.1 Process Audits 2.2.2 Product Audits 2.2.3 Audit Performance 2.3 Quality Monitoring / Quality Assurance Surveillance 2.3.1 Quality Assurance Surveillance Approach 2.3.2 Surveillance Methods 2.3.3 Documenting Surveillance 2.4 Quality Control 2.4.1 Verification 2.4.2 Validation 2.4.3 Acceptance 2.4.4 Acceptance Testing 2.4.5 Quality Control Measures 3. Roles and Responsibilities 4. Approvals / Records of Decision 5. Appendix (Quality Checklists, QC Measures, Quality Baselines, Acronyms, reference document listings, etc.)6.10 Staffing (HR) Management PlanFollowing is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Assumptions 2. Project Team 2.1 Project Team Composition Page 28
  29. 29. Information Technology Project Planning Standards – 1.2 2.2 Acquiring the Project Team 2.3 Project Groups formed for Project Activities 2.4 Organizational Breakdown Structure 2.5 Required Skill Sets 2.6 Project Skills Matrix 3. Stakeholder Identification and Analysis 3.1 Project Team Member Identification Process 3.2 Stakeholder Identification Process 3.3 Stakeholder Analysis and Political Mapping 4. Project Human Capital Management Control 4.1 Stakeholder Expectation Management 4.2 Resource Management 4.2.1 Managing the Project Team 4.2.1.1 Roles and Responsibilities 4.2.2 Managing Contracted Resources 5. Non-Labor Resources 6. Resource Risk and Mitigation 7. Associated Documents 8. Approvals / Records of Decision 9. Appendix (Skills Matrix, Staffing Forecast, Staffing Sources, Acronyms, reference document listings, etc.)6.11 Communication Management PlanFollowing is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Approach 1.3 Assumptions 1.4 Constraints 2. Project Communication Framework and Documents 3. Project team Structures and Assignments 3.1 Team Goals 3.2 Team Communications 3.3 Team Roles and responsibilities 3.4 Team Roles – Appointing New Members 4. Project Stakeholders Page 29
  30. 30. Information Technology Project Planning Standards – 1.2 4.1 Stakeholder Analysis 4.1.1 Needs Assessment 4.1.2 Requirements Gathering 4.1.3 Requirements Consolidation 5. Risks and Issues Management 5.1 Escalation Process 5.2 Communication Pathways 6. Change Management Process 6.1 Communication Pathways 7. Performance Measurement Process 7.1 Performance reporting 7.2 Earned Value Management (EVM) Reporting 8. Communication Process Improvement 8.1 Gathering Feedback 8.2 Communicators / Channels 8.3 Recording Feedback 8.4 Evaluating Feedback 8.5 Responding to Feedback 8.6 Process Improvement 9. Approvals / Records of Decision 10. Appendix (Team Listing, Team Member listing with phone/e-mail etc., Roles and responsibilities matrix, Stakeholder Listing, Performance Measurement Table, Communication templates – briefing papers, memos, etc., Acronyms, reference document listings, etc.)6.12 Risk Management PlanFollowing is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Assumptions 2. Roles and Responsibilities 3. Risk Management Methodology 3.1 Risk Identification 3.2 Risk Assessment 3.3 Risk Quantification / Scoring 3.4 Risk Response Planning Page 30
  31. 31. Information Technology Project Planning Standards – 1.2 3.4.1 Risk Ownership Assignment 3.4.2 Risk Mitigation and Contingency Planning 3.4.3 Risk Trigger 3.4.4 Risk Threshold 3.5 Risk Management 3.5.1 Risk Management Process and Activities 3.5.2 System Security Risk Management 3.5.3 Risk Management Budget and Schedule 3.5.4 Risk List and Issue List Management 4. Risk Closure 4.1 Avoidance 4.2 Acceptance 4.3 Mitigation 4.4 Closure process and reporting 5. Approvals / Records of Decision 6. Appendix (Risk List template, Risk Management Reporting table, Risk Management Audit log, Acronyms, reference document listings, etc.)Note: A Risks and Issues List must always accompany the plan and the should be reviewed andupdated monthly6.13 Procurement Management Plan / Acquisition PlanThis plan is also known as the Acquisition Plan and usually is developed by the ContractingOfficer. There may be different documentation requirements for different agencies. However,following is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Background 2. Acquisition Objectives 3. Investment / Program Description 3.1 Authority and Identification 3.2 Statement of Need 3.3 Acquisition Alternatives 3.4 Records of Decision 3.5 Approvals for Operational Use 3.6 Milestone Chart Depicting the Objectives of the Acquisition 3.7 Milestones for Updating the Acquisition Plan 4. Applicable Conditions Page 31
  32. 32. Information Technology Project Planning Standards – 1.2 4.1 FAR 4.2 Vehicles 4.3 Agency 4.4 Other5. Cost 5.1 Lifecycle Cost 5.2 Design-To-Cost 5.3 Application of Should Cost6. Capability of Performance 6.1 Delivery of Performance Period Requirements 6.2 Tradeoffs 6.3 Risks 6.4 Acquisition Streamlining7. Plan of Action 7.1 Sources 7.2 Competition 7.2.1 Component Breakout 7.2.2 Spares and Repair / Recode 7.2.3 Subcontractors 7.2.4 Multiple Sourcing 7.3 Source Selection Procedure 7.4 Acquisition Considerations 7.4.1 Acquisition Type 7.4.2 Warranties/Rework Guarantee 7.4.3 Contract Administration/Management 7.5 Budgeting and Funding 7.5.1 Program Funding 7.5.2 Contract Funding8. Product Descriptions9. Priorities, Allocations and Allotments10. Contractor vs. Government Performance11. Inherently Governmental Functions12. Management Information Requirements13. Make or Buy14. Test and Evaluation Page 32
  33. 33. Information Technology Project Planning Standards – 1.2 15. Logistics Considerations 15.1 Assumptions 15.2 Quality Assurance, Reliability, Maintainability, Warranties 15.3 Requirements for Contractor Data 15.4 Standardization Concepts 15.5 Continuous Acquisition and Life cycle Support (CALS) 16. Government Furnished Elements 16.1 Property 16.2 Information 16.3 Intellectual Property 17. Considerations 17.1 Environmental Considerations 17.2 Security Considerations 17.3 Other Considerations 17.3.1 COTR / COR / Inspector Assignment Process 17.4 Identification of Participants in Acquisition Plan Preparation 18. Sub-Artifact References 18.1 Acquisition Strategy 18.2 Statement of Objectives / Statement of Work (SOO/SOW) 18.3 Alternatives Analysis 18.4 Request For Change (RFC) Procedures 18.5 Evaluation Criteria 18.6 Contract 18.7 Contract Change Process 18.8 Formal Acceptance and Contract Closure Procedures 18.9 Procurement Management and Control 19. Approvals / Records of Decision 20. Appendix (Contractual templates and forms, COTR/COR Assignment memo, Acronyms, reference document listings, etc.)6.14 Earned Value Management PlanFollowing is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Background 2. Assigned Roles Page 33
  34. 34. Information Technology Project Planning Standards – 1.2 3. EVM Implementation Activities 3.1 Project Baseline 3.1.1 Work Breakdown Structure (WBS) 3.1.2 WBS Dictionary 3.1.3 Organizational Breakdown Structure (OBS) 3.1.4 Responsibility Assignment Matrix (RAM) 3.1.5 Control Account (CA) 3.1.6 Work Package (WP) 3.1.7 Planning Package (PP) 3.1.8 Control Account Plans (CAP) 3.1.9 Integrated Master Schedule (IMS) 3.1.10 Cost and Budget 3.1.11 Reporting Thresholds 3.1.12 Work Authorization Document (WAD) 3.2 Earned Value (EV) Status 3.3 Reporting of Actual Cost and Schedule 3.4 Statistical Forecast 3.5 Performance Analysis Reporting 3.5.1 Monthly Contract Performance Report (CPR) Analysis 3.5.2 Integrated Master Schedule (IMS) Review 3.5.3 Formal Reporting of Cost and Schedule Performance 3.6 Statement of Work (SOW) 4. Change Control 4.1 Change Process Schematic Diagram 5. Approvals / Records of Decision 6. Appendix (Earned Value Techniques, EV Calculation Formulas, Acronyms, reference document listings, etc.)7. Supporting DocumentationSupporting documents are not mandatory documents by OMB or by DOI. However, some of thesupporting documentation (Alternatives Analysis, Enterprise Architecture and Draft SolutionArchitecture framework) are considered pre-planning documents and provide the information,analysis, verification and validation needed to develop a robust Business Case for theinvestment/project, as well as provide the initiation point for the Exhibit-300 for the MajorInvestment. The other supporting documents provide the credibility and efficient progress of theproject while minimizing risks and rework. Page 34
  35. 35. Information Technology Project Planning Standards – 1.27.1 Alternatives AnalysisFollowing is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Objectives 2. Executive Summary 3. Recommendation 4. Overview 4.1 Mission 4.2 Architecture 4.3 Expected Useful Life / Sunset 4.4 Objective Based Performance Measures 5. Cost Benefit Analysis (CBA) 5.1 Identification of Viable Alternatives 5.2 Option 0: Status Quo 5.3 Option 1: 5.4 Option 2: 5.5 Option 3: 5.6 Alternative to Options 0-3: (e.g. Government Service Provider) 6. Results 6.1 Cost Estimate Comparison of Alternatives (in millions of dollars) 6.2 Mission driven Functional Comparison of Alternatives 6.3 Benefit Comparison of Alternatives 6.4 Conclusion 7. Approvals / Records of Decision 8. Appendix (References, Source Documents list, Bibliography, etc.)7.2 Change Management PlanFollowing is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Objectives 2. Definitions 2.1 Definition of Change 2.2 Scope Relationships Page 35
  36. 36. Information Technology Project Planning Standards – 1.2 3. Change Management Process 3.1 General Rules 3.2 Change Process Explanation 3.3 Roles and Responsibilities 3.4 Change Request Cycle 3.5 Approval Guidelines 4. Approvals / Records of Decision 5. Appendix (Change Process Diagram, Change Process Walk-Through, Change Request Form Template, Change Log Template, etc.)7.3 Configuration Management PlanThe Configuration Management plan is an extension of the Change Management Plan. Thus aseparate Configuration Management Plan is not often needed for single project basedinvestments. However, if an investment contains more than a single project or the project withinthe investment is of integration or multiple component assimilation type project, an investmentlevel Configuration Management Plan is highly useful. Following is the recommended outline forthis plan: 1. Introduction 1.1 Purpose 1.2 Objectives 2. Definitions 2.1 Definition of Configuration related to the investment 2.2 Scope Relationships 3. Configuration Management Process 3.1 General Rules 3.2 Roles and Responsibilities 3.3 Configuration Governance and Oversight (if multiple component) 3.4 Request and Escalation Cycle 3.5 Approval Guidelines 3.6 Document Management 3.7 Configuration Records Library and Archives 4. Approvals / Records of Decision 5. Appendix (Process Diagram, Process Walk-Through, etc.) 6. Configuration Tracking (reviewed and updated monthly recommended)7.4 Enterprise ArchitectureFollowing is the recommended outline for this plan: 1. Introduction Page 36
  37. 37. Information Technology Project Planning Standards – 1.2 1.1 Purpose 1.2 Objectives 2. Modernization Blueprint 2.1 Segment Architectural Transition 2.2 As-Is Conceptual Solution Architecture 2.3 Intermediate Target Conceptual Solution Architecture 2.4 Target Conceptual Solution Architecture 2.4.1 Specific Architectural Considerations 2.5 Segment Sequencing Plan 3. Segment mappings 4. Service Component reference Model (SRM) 5. Technical reference Model (TRM) 6. High Level Requirements and Alignment to Strategic Goals 6.1 Mission Goals Alignment 6.1.1 Mission Goal 1 6.1.2 Mission Goal 2 6.1.3 Mission Goal 3……… 7. EA Authority and Governance 8. Approvals / Records of Decision 9. Appendix (Architectural Diagrams, Strategic Plan Mapping Table, Mapping of Program Requirement to Mission Goals table, etc.)7.5 Solution ArchitectureFollowing is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Overview 1.3 Relationship to Enterprise Architecture (EA) 2. Solution Objective and Scope 2.1 Business Drivers 2.2 Information Technology Drivers 3. High Level Business Descriptors 3.1 Conceptual Elements 3.1.1 Access and Delivery 3.1.2 Business Services 3.1.3 Resources Page 37
  38. 38. Information Technology Project Planning Standards – 1.2 4. Solution Overview 4.1 Patterns for Enterprise Architecture Assimilation 4.1.1 Status Quo 4.1.2 Intermediate 4.1.3 Target 5. Use Case Model 5.1 System Components 5.1.1 Interfaces 5.2 Architectural Components 5.3 Security Components 5.3.1 Access Control 5.3.1.1 Role Based 5.3.1.2 Domain 5.3.1.3 Discretionary 6. Deployment / Operational Model 6.1 Deployment Unit Mapping 6.2 Walkthrough 6.2.1 Example Walkthrough 7. Architectural Decisions 7.1 Segment Governance Framework 8. Approvals / Records of Decision 9. Appendix (Capacity Characteristics, Use Case template, Deployment mapping to Logical Node Table, Deployment mapping to Physical Node Table, etc.)7.6 Master ScheduleThere is no specific guidance to the Master Schedule format. All project schedules must besubsumed into the Master Schedule. The Master Schedule must have dependencies(predecessor, successor, parallel) identified for all sub schedules. A critical chain managementmethod is highly recommended. Various software (e.g. Microsoft Project ™, Primavera ™, etc.)can be used to facilitate this.7.7 Version Control PlanThe Version Control Plan is usually very specific to the software being developed and themethodology used. It is also highly dependent on the Master Schedule. Following is a genericrecommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Objectives 2. Scope Page 38
  39. 39. Information Technology Project Planning Standards – 1.2 2.1 Assumptions 2.2 References 3. Methodology 4. Tools and Techniques 4.1 Versioning Process 4.2 Version Outlines 5. Evolving Conclusion 6. Approvals / Records of Decision 7. Appendix (Version Specific Installation Documents table, Version Records table, etc.)7.8 Test PlanThe Test Plan is also applicable to a software development project. This plan is generally usedin tandem with the Version Control Plan. Following is the recommended outline for this plan: 1. Introduction 1.1 Purpose 1.2 Background 1.3 Objectives 2. Relationship to Version Control Process 3. Roles and Responsibilities 3.1 Integrated project Team (IPT) 3.1.1 Technical Team(s) 3.1.2 Business Team(s) 3.2 Bureau Level Team(s) 3.3 External Team(s) 3.4 Evaluation Team(s) 3.5 Governance 4. Test Environment 4.1 Test Locations and Equipment 4.2 Testers 4.3 Test Data 4.4 Prerequisites and Assumptions 4.4.1 Prerequisites 4.4.2 Assumptions 4.5 Support Services / Help Desk 4.6 Test Status Meetings Page 39
  40. 40. Information Technology Project Planning Standards – 1.2 4.7 Test Metrics5. Test Methodology 5.1 Survey Format 5.2 Scenario Format 5.3 Test Script Format 5.4 Discrepancy Reporting (DR) 5.5 Support Service / Help Desk Procedures 5.6 Governance Discussion Items6. Test Completion Report7. Approvals / Records of Decision8. Appendix (Test Scripts example, Test Survey example, Test Scenario example, DR Form, DR Log, Test Communication Process Walk-Through, etc.) Page 40
  41. 41. Information Technology Project Planning Standards – 1.28. Prepared by __________________________________ Faisal Ahmed Assistant Director - Technology DOI – Office of Law Enforcement and Security http://www.doi.gov/pmb/oles/technology.cfm faisal_ahmed@ios.doi.gov / faisal_b_ahmed@hotmail.com Faisal Ahmed serves as the Assistant Director for the Office of Law Enforcement and Security leading the Technology Division. He presently provides oversight and guidance for the Office of Law Enforcement and Security (OLES) Technology Programs with primary responsibility of managing the OLES cornerstone program, the Incident Management, Analysis, and Reporting System (IMARS). Mr. Ahmed holds a Bachelor of Science degree in Information Technology from University of Wisconsin, a Master of Science Degree in Technology Management from University of Central Florida. He is a graduate of the Harvard University, JFK School of Government - Senior Executive Fellows (SEF) program in Public Policy and the Office of Personnel Management (OPM) - Leadership Education and Development (LEAD) program at a Senior Executive level. He also holds multiple technical and program management certifications including a Masters Certificate in Project Management from Regis University, Paralegal Diploma in Intellectual Property Law from Ashworth University, Senior Expert level FAC P/PM from the Federal Acquisition Institute (FAI), Project Management Professional (PMP), Program Management Professional (PgMP) and various core technical certificates relating to CMMi, ITIL, Microsoft, Citrix, etc. Assistant Director Ahmed has over 16 years of technology management experience. He began his career as a Systems Analyst with the Fairfax County Government, VA, USA and spent his career life in mixed Government, International Organizations and private industries. Some of his highlight career contributions were with the US Census Bureau, Department of Commerce, the World Bank, Assurenet Limited and Apogen Technologies before joining the Department of the Interior in 2007. Page 41

×