Kansas Information Technology Executive Council


Information Technology 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; or (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:

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:

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 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 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:

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:

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:

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:

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.

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:

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:

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.

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:

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:

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:

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:

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:

End of Document

 


Page last modified on:
Send us your questions and comments about this site