Resources » Governance » IT Executive Council » ITEC Policies & Standards

ITEC Policy 2530 - Project Management

1.0 TITLE: Project Management

1.1 EFFECTIVE DATE: October 14, 1999

1.2 TYPE OF ACTION: New

2.0 PURPOSE: To establish a policy for management of information technology projects.

3.0 ORGANIZATIONS AFFECTED: All Branches, Boards, Commissions, Departments, Divisions, and Agencies of state government, hereafter referred to as entities.

4.0 REFERENCES:

4.1 K.S.A. 1998 Supp. 75-7203 authorizes the ITEC to: Adopt information resource policies and procedures and provide direction and coordination for the application of the state's information technology resources for all state entities.

5.0 DEFINITIONS/BACKGROUND:

5.1 Cumulative cost means the total expenditures, from all sources, for any information technology project by one or more state entities to meet project objectives from project start to project completion or the date and time the project is terminated if it is not completed.

5.2 Information technology project means a project for a major computer, telecommunications or other information technology improvement with an estimated cumulative cost of $250,000 or more and includes any such project that has proposed expenditures for: (1) new or replacement equipment or software; (2) upgrade improvements to existing equipment and any computer systems, programs or software upgrades therefore; or (3) data or consulting or other professional services for such a project.

5.3 ITEC - Refers to the Information Technology Executive Council, duties defined in K.S.A. 1998 Supp. 75-7202, 75-7203.

5.4 CITO - Chief Information Technology Officer, duties defined in K. S. A. 1998 Supp. 75-7205, 75-7206, 75-7207.

5.5 Project change or overrun means any of the following:

(1) Any change in planned expenditures for an information technology project that would result in the total authorized cost of the project being increased above the currently authorized cost of such project by more than either $1,000,000 or 10% of such currently authorized cost of such project, whichever is lower;

(2) any change in the scope of an information technology project, as such scope was presented to and reviewed by the joint committee or the chief information technology officer to whom the project was submitted pursuant to section 9 and amendments thereto

(3) any change in the proposed use of any new or replacement information technology equipment or in the use of any existing information technology equipment that has been significantly upgraded.

5.6 Project change request means any agreement between the entity and a contractor that will result in a change to the currently authorized cost of the project.

6.0 POLICY

6.1 The following six project management component statements, sections 6.2, 6.3, 6.4, 6.5, 6.6, 6.7 below, taken together, form the core of the state's policy for management of information technology projects. They are compatible with and fully support the Information Technology Executive Council's (ITEC) project management methodology:

6.2 Requirements Management: All projects must include a well-defined problem statement with well-defined business and technical requirements that assure the IT solution satisfies the business need. Requirements must be thoroughly documented and understood by the project team. Changes to requirements must be managed throughout the life of the project.

6.3 Project Planning: Each project manager must develop, maintain and follow a written plan that defines project goals, processes, and resource estimates (in terms of schedule, cost and development). The project plan must be updated throughout the life of the project to accurately reflect the current plan.

6.4 Project Tracking: Project managers must continuously track the progress of all projects against the project plan.

6.5 Configuration Management: Configuration Management (CM) must be performed on all projects in accordance with established organizational CM procedures. These processes must ensure that controlled and stable baselines are established for planning, managing and building the system; the integrity of the system's configuration is controlled over time: and the status and content of the baselines are known.

6.6 Risk Management: Risks associated with each IT project must be identified, analyzed and prioritized. Identified risks must be controlled through the process of project planning and monitoring. Risk identification and management must be integrated components of project management and will be continuously assessed and analyzed during the life of the project.

6.7 Project Closeout: State organizations must maintain procedures for conducting lessons learned on IT projects during a project closeout process. Closeout is determined when project objectives have been met and users have reviewed and accepted the system. The process includes preparation of a Post Implementation Evaluation Report (PIER) to capture lessons learned and archival of project records.

7.0 PROCEDURES: Implementation guidelines and other supporting information and procedures for each policy statement can be found in Attachment 1. The supporting information includes:

  • requirements
  • references to the specific areas of the ITEC Project Management Methodology document in which the policy is discussed restatement of the policy
  • purpose
  • overview
  • objectives
  • responsibilities
  • evidence of compliance

8.0 RESPONSIBILITIES:

8.1 Heads of entities are responsible for establishing procedures for their organization's compliance with the requirements of this policy. The project manager has the basic responsibility for implementing the policy.

8.2 The Chief Information Technology Officer, Executive Branch, is responsible for the maintenance of this policy.

9.0 CANCELLATION: None

ATTACHMENT 1

REQUIREMENTS MANAGEMENT

Summary of Requirements Management Policy

The requirements management policy requires that all information technology (IT) projects must include a well defined problem statement with well-defined business and technical requirements that assure the IT solution satisfies a business need. Requirements must be thoroughly documented and understood by the project team. Changes to requirements must be managed throughout the life of the project.

Implementation Guidelines for Requirements Management

Requirements definition is one of the most crucial steps in the process of creating a project. Without well-defined requirements, managers cannot plan a project, developers and integrators do not know what to build, customers do not know what to expect, and there is no way to validate (i.e. test) that the system satisfies the needs of the organization.

The project manager is responsible for ensuring that technical requirements are defined and the program or business manager is responsible for ensuring that the business/operational requirements are met.

Requirements Specification Requirements

At each stage of the project, additional information is derived and documented. Requirements specification will vary from project to project, based on size, complexity, and business impact of the project.

State organizations ensure that requirements are documented and understood for IT projects, but the degree of specification and the formality of the specification may vary. At a minimum, each project must have a business needs statement. The remaining specifications and requirements traceability tools are applied as necessary, based on organization-specific management and development procedures.

References to Requirements Guidelines

Guidelines for requirements management are provided as part of the ITEC Project Management Methodology document in the Project Management Planning Top Level Requirements Specifications section.

REQUIREMENTS MANAGEMENT POLICY

Policy Statement:

All projects must include a well-defined problem statement with well-defined business and technical requirements that assure the IT solution satisfies the business need. Requirements must be thoroughly documented and understood by the project team. Changes to requirements must be managed throughout the life of the project.

Purpose:

To ensure that project requirements form the basis for all planning and development efforts and that changes to requirements are managed throughout the life of the project.

Overview:

Requirements establish and maintain an understanding and agreement of the capabilities of the project. Requirements statements, which will evolve over the life of the project, form the basis for estimating, planning, performing, and tracking the project=s activities and are critical to obtaining acceptance of the product at the end of the project. Control of the requirements is directly related to control of the project.

Objectives:

  • Ensure that system requirements provide a clearly stated, verifiable, and testable foundation for development and management of the project, based on business and technical requirements.
  • Ensure that the scope of a development effort is defined by the system requirements and that these requirements form the basis for all plans, products and activities.
  • Ensure that project team members thoroughly understand requirements prior to developing a product or procuring commercial products for the project.
  • Record initial project requirements and review and assess the impact of all changes to the initial requirements throughout the life of the project.
  • Track and document all changes to requirements and update all necessary technical and management project documentation affected by the change.
  • Define, collect, and store metrics (measurements) associated with the requirements phase.

Responsibilities:

The project manager has primary responsibility for implementing this policy.

Evidence of Compliance:

To demonstrate compliance with this policy, the following documentation must be available at a minimum:

  • Project statement and objective (all projects)
  • Project Requirements Document (all projects)
  • Requirements Control Methodology (medium to high risk projects)
  • Requirements Traceability Matrix (high risk projects)

PROJECT PLANNING

Summary of Project Planning Policy

The project planning policy requires that each project manager must develop, maintain and follow a written plan that defines project goals, processes, and resource estimates (in terms of schedule, cost and development). The project plan is updated throughout the life of the project to accurately reflect the current plan.

Implementation Guidelines for Project Planning

Project planning defines the work and describes how the tasks will be executed. Planning begins with the definition of the specific work to be performed and other constraints and goals that define and bind the project. The planning process includes the steps to estimate:

  • the size of a project
  • the technological scope of the effort: and
  • the resources required to complete the project.

The planning process results in the production of a schedule, identification and assessment of risks, and negotiation of commitments. Repetition of these steps is necessary to establish the project plan and to ensure Abuy-in@ by those responsible for the project. Typically, several iterations of the planning process are performed before a plan is actually completed.

Project Planning Requirements

The project plan forms the basis for management efforts associated with the project. It represents the basic tool for successfully executing a project. The plan includes the following types of elements, with the degree of definition varying between projects of different scope:

  • Sequence of tasks to be performed
  • Deliverables associated with the project
  • Dependency relations between tasks
  • Resources required to perform a task
  • Schedule of tasks to be performed
  • Budget for performing tasks
  • Organization used to execute the project
  • Risks associated with executing the project
  • Process for ensuring quality
  • Process for configuration management

The project manager has primary responsibility for implementing the project plan and maintaining it over the course of the project. Project planning requirements will vary by project and are typically determined by the size, cost, complexity and impact on the business. State organizations set standards for good project management and methods for IT projects and ensure appropriate management processes are applied. State organizations are encouraged to add to, and tailor the methodology to include additional elements as the size, complexity, cost and impact increases.

References to Project Planning Guidelines

Guidelines for project planning are provided in the ITEC Project Management Methodology document in the Project Management Planning section.

PROJECT PLANNING POLICY

Policy Statement:

Each project manager must develop, maintain and follow a written plan that defines project goals, processes, and resource estimates (in terms of schedule, cost and development). The project plan must be updated throughout the life of the project to accurately reflect the current plan.

Purpose:

To ensure proper planning is performed for successful project completion.

Overview:

Project planning includes developing estimates for the work to be performed, establishing the necessary commitments, and defining the plan to perform the work. The development plan addresses the commitments in terms of resources, constraints, and capabilities of the project. Finally, the plan provides the basis for guiding the management and the performance of the project and evaluating the work progress.

Objectives:

  • Develop a plan for each project that appropriately and realistically covers the activities and commitments (based on documented requirements) and breaks down the development effort into manageable components.
  • Ensure that all affected groups and individuals (e.g., developers, external users, internal customers, stakeholders, etc.) Understand the planning estimates and Assignments and commit to support them.
  • Document all approved estimates and plans for tracking activities and commitments. Project estimates are refined throughout the project phases. As issues are better understood, estimates for later project phases are updated based on project specific data rather than formula-based assumptions.
  • Perform project planning in accordance with organizational procedures and in a manner that is consistent with the complexity and risk of the effort.

Responsibilities:

The project manager has primary responsibility for implementing this policy.

Evidence of Compliance:

Low risk projects will prepare a project plan that includes, at a minimum, the following: a project statement, a project schedule with milestones, and a project budget. Medium risk projects will also provide project resource estimates, a deliverables list, a project risk assessment, and a configuration management process. High risk projects will additionally be required to provide a detailed work breakdown structure, a quality plan, a project requirements list and issues list.

PROJECT TRACKING

Summary of Project Tracking Policy

The project tracking policy requires that project managers continuously track and monitor the progress of IT projects against the plan.

Once a project has advanced to the execution phase of performance, a project team and the necessary resources should be in place ready to perform, and the project plan should have been developed and baselined. The project manager is responsible for implementing the project tracking policy.

Implementation Guidelines for Project Tracking

During the implementation phase, the focus shifts from discovery to participating, observing, and ensuring that the plan is being successfully executed. The project plan serves as the basis for the project's monitoring, controlling, and reporting activities. By following the plan and gathering relevant data for status meetings and reports, information will be available to accurately identify issues and problems early, minimize project risks, and monitor, control, and report progress.

Project Tracking Requirements

Projects often fail due to inattention to basic control principles. Too many times a project team is so busy getting on with completing the project that not enough time is spent tracking the status and anticipating potential problems that might arise. Then, once a problem is suspected, the team may act too slowly to resolve the problem. Project tracking can help avoid this scenario by defining processes to:

  • Track and monitor project activities to compare actual performance to planned performance
  • Review and communicate status and future actions on both a formal and informal basis.
  • Monitor and mitigate potential problems, thus reducing their likelihood of occurrence.
  • Establish a change management process to control changes to the project's objectives, specifications and overall definition.
  • Establish an issue tracking process to ensure that there is a central repository for project issues that are addressed in a timely fashion.
  • Establish a corrective action process to document and track plans to correct an issue that impacts the stated plan and to establish guidelines for re-planning.

Project tracking requirements will vary by project, based on size, cost, complexity and impact on the business. State organizations ensure standards exist so that good project tracking methods for IT projects are followed. A state organization may tailor the methodology so it is appropriate to that organizations specific environment.

The management of a project includes processes for successfully tracking and communicating project status and performing risk assessments. The formality of this tracking process may change based on the specific project. The project manager has responsibility for tailoring all elements of the methodology to meet the specific needs of a project.

References to Project Tracking Guidelines

Guidelines for project tracking are provided in the ITEC Project Management Methodology document in the Project Execution section.

PROJECT TRACKING POLICY

Policy Statement:

Project managers must continuously track the progress of all projects against the project plan.

Purpose:

Project managers will ensure that the project is continuously tracked and that appropriate action are taken.

Overview:

Project tracking involves monitoring and reviewing the project accomplishments and results against documented estimates contained in the development plan, and adjusting these estimates based on the actual accomplishments and results. A documented and up-to-date plan for the effort is used as the basis for tracking activities, communicating status and revising plans. Changes in project scope and status have a cascading effect on testing, documentation and roll-out planning. Regular technical and management reviews are conducted to ensure that the management and staff are aware of the project status and plans, and that issues receive appropriate attention.

Objectives:

  • Ensure that actual results and performance of the project are regularly tracked against documented and approved plans.
  • Ensure that risk assessment is performed during key points in the project.
    • Ensure that corrective actions are taken when the actual performance of the project deviates from the plans.
    • Ensure that changes to commitments (e.g., assignments, budget, schedule) are understood and agreed to buy all affected groups and individuals.

Responsibilities:

The project manager has responsibility for implementing this policy.

Evidence of Compliance:

To demonstrate compliance with this policy, the following documentation must be available, at a minimum.

  • Actual vs. budgeted cost reports
  • Planned vs. actual schedule
  • Updated risk analysis
  • Deliverable status list
  • Corrective action plan (as required)
  • Requirements traceability matrix (high risk projects)

CONFIGURATION MANAGEMENT

Summary of Configuration Management Policy

The configuration management policy requires that configuration management (CM) must be performed on IT projects in accordance with organizationally established CM procedures to ensure that controlled and stable baselines are established for planning, managing, and building IT systems. As part of this process, the integrity of the system=s configuration is controlled over time, and the status and content of the baselines are known.

Implementation Guidelines for Configuration Management

Configuration management is a formal discipline that provides developers and users with the methods and tools to identify the product developed, establish baselines, control changes to these baselines, record and track status, and audit the product

During the planning process, the procedures and required resources for CM are defined and the control items that will be tracked are identified. The goals for configuration management planning are to:

  • Explicitly assign authority and responsibility for CM for the project.
  • Ensure that CM is implemented throughout the project's life cycle by setting standards, procedures and guidelines that are produced and distributed to the full project team.
  • Ensure that configuration management has a repository for storing configuration items and associated CM records.
    Ensure that reviews of baselines and CM activities occur on a regular basis.
  • Ensure that changes are controlled and that the impact of changes on the hardware and software configuration are understood prior to approving a change.

Configuration Management Requirements

A CM plan is included as part of the project plan, or it can appear as a separate document or as sections within an overall quality plan. The degree of specification of the CM plan is dependent on the size, cost, complexity and impact on the business.

State organizations ensure that good CM methods for IT projects within their IT environment are applied. State organizations are encouraged to tailor the ITEC project management methodology and to develop CM processes that are appropriate to the specific project.

References to Configuration Management Guidelines

Guidelines for configuration management are provided in the ITEC Project Management Methodology document in the Project Management Planning section.

CONFIGURATION MANAGEMENT POLICY

Policy Statement:

Configuration Management (CM) must be performed on all projects in accordance with established organizational CM procedures. These processes must ensure that controlled and stable baselines are established for planning, managing and building the system; the integrity of the system's configuration is controlled over time: and the status and content of the baselines are known.

Purpose:

To ensure that the project baselines are managed and changes to the baseline are controlled.

Overview:

CM involves identifying project baseline items, controlling these items and changes to them, and recording and reporting status and change activity for these items. Changes to the baseline items are controlled systematically using a defined change control process. The configuration of a system or any of the controlled intermediate or support products can be distinctly identified at any point in time.

Objectives:

  • Explicitly assign responsibility for CM for each project.
  • Ensure that each project has a CM plan.
  • Ensure CM work is performed according to the project plan.
  • Ensure that CM is implemented on products throughout the project=s life cycle.
  • Ensure that CM is implemented for externally-delivered products and for appropriate products used inside the organization.
  • Ensure that all projects have a repository for storing configuration items and associated CM records.
  • Ensure that quality assurance audits of the baselines and CM activities are performed an a regular basis.

Responsibilities:

The project manager has primary responsibility for implementing this policy.

Evidence of Compliance:

To demonstrate compliance with this policy, the following documentation must be available, at a minimum.

Organizational configuration management plan or project configuration management plan.

RISK MANAGEMENT

Summary of Risk Management Policy

The risk management policy requires that risks associated with IT projects must be identified, analyzed and prioritized. Identified risks must be controlled through the process of project planning and monitoring. Risk identification and management is an integrated component of project management and must be continuously assessed and analyzed during the life of a project. When significant risks are identified for a project, a risk manager should be assigned to assist the project manager in risk management.

Implementation Guidelines for Risk Management

A risk is any factor that may potentially interfere with successful completion of the project. The existence of risk is not a bad thing; the absence of risk analysis and mitigation measures is, however, not a good thing. Every project has risks. The challenge is to fully identify risks and invest in working them rather than ignoring them.

Part of controlling a project during the performance life cycle phases is to have an established risk management process that is unique to the project. Risk management deals with the following risk phases:

  • Risk identification
  • Risk analysis and quantification
  • Risk mitigation planning
  • Risk response

The risk management plan documents the procedures that will be used to manage risk throughout the project. In addition to documenting the results of the risk identification and analysis phases, it covers who is responsible for managing various areas of risk. How risks will be tracked throughout the life cycle, how contingency plans will be implemented, and how reserves will be allocated to handle risks.

Risk assessment is used as an assessment tool in project oversight. The ITEC has adopted a Risk Assessment Model (RAM) tool to assist departments in assessing the risk of its project quickly and in automated fashion. The RAM must be completed on all IT projects and submitted to the branch Chief Information Technology Officer (CITO) at project initiation when seeking project approval and as requested by the CITO in a project oversight role.

Risk Management Requirements

The procedure that the project team will use to manage project risk is defined in the planning stage, documented in the project plan, and executed throughout the life of the project. The scope of the risk management plan is dependent on the size, cost, complexity and impact on the business. State organizations will practice good risk management methods for IT projects and apply risk management processes that are appropriate to the specific project.

References to Risk Management Guidelines

Guidelines for risk management are provided in the ITEC Project Management Methodology document in the risk management plan and Risk Monitoring and Mitigation sections.

RISK MANAGEMENT POLICY

Policy Statement:

Risks associated with each IT project must be identified, analyzed and prioritized. Identified risks must be controlled through the process of project planning and monitoring. Risk identification and management must be integrated components of project management and will be continuously assessed and analyzed during the life of the project.

Purpose:

To ensure that risks associated with a project are well understood so they can be managed, planned for and mitigated during the execution of the project.

Overview:

Assessing a project=s risks will help project managers make more informed decisions and ensure more successful outcomes. Risk assessment is not problem management but is a process that reduces the likelihood of problems occurring. The risk management process must be integrated with the other elements of project management to ensure consistency in process. Project risks involve exposure to events such as: failure of the project to obtain anticipated benefits, costs that exceed planned levels, extended project schedules and poor performance of a system.

Objectives:

Risk identification will be led by the project manager, with the assistance of team members with various perspectives, such as technical, user, and management. Risks are listed, analyzed for probability of occurrence and potential impact on the project, and prioritized. Risk identification occurs at the beginning of the project and continues throughout the project=s life cycle. Management must ensure that the project team openly and routinely discusses and analyzes risks throughout the life of the project.
Risk management planning produces plans for addressing each major risk item and coordinates individual risk plans to the overall plan. Risk planning assures that project schedules and cost estimates are adjusted to ensure that adequate time is allocated to properly develop and execute risk mitigation measures when required.

Risk management monitoring and control involves tracking the progress toward resolving high risk items and taking corrective action when appropriate. The top risk items are highlighted as part of the project reviews.

Responsibilities:

The project manager has primary responsibility for implementing this policy. Oversight contractors, if assigned, can help support the risk management effort.

Evidence of Compliance:

To demonstrate compliance with this policy, the following documentation must be available, at a minimum:

  • List of project risks and the completed ITEC Risk Assessment Model (RAM) report
  • Assessment of risks associated with the project assumptions

PROJECT CLOSE-OUT

Summary of Project Close-Out Policy

The project close-out policy requires that IT projects must follow a project close-out process upon completion of the project that includes development of a Post Implementation Evaluation Report (PIER) to capture lessons learned and archival of project records based on organizationally defined requirements.

Implementation Guidelines for Project Close-Out

The key elements associated with project close-out include re-disbursement of resources, completion and archiving of project records, documentation of the successes and issues associated with the project, celebrating success of the project and conducting a lessons learned session.

The purpose of conducting a formal project close-out is to document lessons learned, This means that problems that were encountered by the project team must be able to be openly presented so that process improvements can occur to eliminate the cause of the problems. It is important that the discussions do not merely point a finger away from the project team; responsibility for problem areas must be completely discussed. It is helpful to conduct an interactive session to gather the lessons learned.

Summary information about the project should be collected and archived, based on organizationally defined procedures. Typical information that is archived includes a description of the project, a project organization chart, budgeted and actual cost, budgeted and actual schedule and the project close-out report. Assumptions associated with the project values and changes that were documented throughout the project are also useful to archive.

Project Close-Out Requirements

It is the responsibility of the project manager to ensure that a project is properly closed out and that a PIER is completed and submitted to the appropriate entities for review and approval.

References to Project Close-Out Guidelines

Guidelines for project close-out are provided in the ITEC Project Management Methodology document in the Project Close-Out section.

PROJECT CLOSE-OUT POLICY

Policy Statement:

State organizations must maintain procedures for conducting lessons learned on IT projects during a project close-out process. Close-out is determined when project objectives have been met and users have reviewed and accepted the system. The process includes preparation of a Post Implementation Evaluation Report (PIER) to capture lessons learned and archival of project records.

Purpose:

To ensure that lessons learned from projects are captured for use in continual process improvement.

Overview:

The formal closing of a project reflects the temporary nature of a project. A project is closed when the objectives for the project have been met. Upon completion of the project, resources are reassigned, project records are archived (per organizationally defined procedures), and the lessons learned on the project are determined and documented.

Objectives:

  • Ensure that continuous organizational improvements can be achieved through recognition of the successes and problems associated with execution of the project.
  • Develop a repository of project metrics that can be used to facilitate future project cost and schedule estimation.
  • Develop organizational standards for archiving project data so that consistent information is saved for all projects.

Responsibilities:

The project manager has primary responsibility for implementing this policy. The entire team participates in lessons learned.

Evidence of Compliance:

To demonstrate compliance with this policy, the following documentation must be available, at a minimum:

  • Post Implementation Evaluation Report
  • Project archive update