Section 5 Project Management Processes

Principle

Guideline

This phase of project management is when the project is defined, and is accepted to proceed by the department.

Form a Steering Committee comprising the sponsor (Chair) and a small group (see Section 4) to guide the process at a Governance level.

Appoint the sponsor - a senior business manager (preferably not the Chief Executive) who will be most actively involved in the outcome of the project.

The Project Definition is an 'overview' document, retaining this perspective of the whole project.

The Project Definition sets out the agreed vision that is the basis of a common understanding of the overall project goals and objectives, and its scope. It includes:

• Purpose and objectives of the project.
• Scope (including what is out of scope).
• Assumptions and constraints.
• Critical success factors.
• Risk analysis.
• Deliverables and acceptance criteria.
• Expected benefits.
• High Level Plan - including timescales, resourcing, estimated budget.

The Project Definition is the catalyst for Steering Committee approval.

After the Steering Committee accepts the Project Definition, the detailed Project Plan becomes the main management document of the project.

Approval of the Project Definition signifies the beginning of work on the project.

Planning begins!

Principle

Guideline

Thorough planning gets reflected in the smooth running of the project.

In this phase of project management:

• The project is defined in more detail.
• The project team is formed.
• The detailed Project Plan is prepared, including budget and resourcing needs.

The planning phase identifies the size of the project and enables the project to be broken into manageable 'chunks.'

Major IT projects should be broken down into modules or sub-projects, each lasting no more than six to twelve (6-12) months. Each module or sub-project is considered as an independent business case within the department's overall IT strategy.

Smaller stages are managed concurrently where appropriate.

The two part project plan has:

• A high-level overview plan for the entire project.
• Detailed working plans for the current and next phase of the project and sub-projects.

The level of detail required in both the Project Definition and the Project Plan should be scaled to reflect the size and complexity of the project.

If the project is broken into modules or sub-projects, the high level plan shows how each module is integrated into the overall picture.

At the beginning of the planning phase:

• The initial modules or sub-projects are planned in detail.
• Later dependent modules or sub-projects are planned at a high level.

Realistic resourcing helps projects to be successful.

It is important to be realistic about how much time each individual can put into a project. Total work utilisation of 75-80% is the maximum anyone should be allocated to work - on projects. Any more than 80% means there is no room for contingencies like unplanned work and projects inevitably will not be completed on time.

The detailed project plan sets out all tasks with timeframe, allocated resources and milestones.

Phasing projects into distinct and manageable stages with deliverables at the end of each phase enables the project team, and stakeholders, to see and acknowledge the achievements.

The detailed project plan is developed in conjunction with the supplier and includes:

• A description of each task.
• Resources needed to undertake each task.
• Milestones - expected dates of deliverables.

Accompanying the project plan is:

• An approved budget, financial plan and cash flow statement (month by month).
• A project quality plan that:
• Includes the quality control processes to be used on the project, such as peer review, design demonstrations and testing.
• Sets overall quality target for the project deliverables.
• Specifies quality assurance roles for both the team members and an external quality assurance specialist.
• A communications plan that sets out:
• The message.
• Who needs to hear the message and when.
• How the message will be delivered.
• Who prepares and delivers the message.
• Date action was taken.
• A risk management plan that includes a detailed risk assessment that identifies all risks that could jeopardise the project outcomes.
• The risk assessment report should cover budget variances, resource problems, inadequate management support, unrealistic timeframes and "scope creep".
• Use the risk assessment to prepare a risk management plan that recommends treatment for the identified risks. The risk management plan will include options for accepting, eliminating or managing risks and will be signed off by the project sponsor.
• Training plan.
• Installation plan.
• Testing plan.

A plan for the programme of related projects links them together.

The programme plan identifies:

• Scope of the programme.
• Dependencies between projects.
• Estimates for the entire programme.
• Fixed costs for individual projects, rather than the entire programme.
• All contingency costs associated with individual projects rather than the programme as a whole.

• As well as reflecting the expected timing of costs and benefits, the analysis in the business case should estimate and reflect uncertainty and risk.
• Projects, which update technology without introducing business changes, may not appear to offer tangible benefits. These are often referred to as "Infrastructure Projects". However, such a project may be an essential stepping stone to:
• Establishing an environment in which modular projects are able to be introduced.
• Reducing the total cost of ownership of technology.
• Reducing the business risk, or exposure to IT failure, or loss of data or system availability.

Risk management is an important part of the planning phase.

During project planning it is desirable to manage risk by specifying exit points (or "off-ramps") where the project can be terminated early while still obtaining identifiable and worthwhile benefits (if any) or at least minimising further costs that produce little or no benefits.

These off-ramps to terminating the project (and funding) early may be triggered by:

• Significant changes in the environment which affect the project; or
• Specific issues or failures to achieve milestones during the project.

Where possible, criteria for these exit points should be set in advance, included in the business plan, and monitored by the Steering Committee.

Principle

Guideline

Implementation is planned in detail.

This ensures that the agreed deliverables will be produced, while at the same time managing the risk elements.

The methodology selected for implementation fits the purpose of the system to be developed and implemented.

A systems development methodology provides a disciplined approach to the in-house work required to implement the IT project.

The methodology defines the milestones where the project is reviewed and approval given to proceed to the next stage.

Completion of the project is marked by formal closure.

This covers the orderly termination of the project and makes sure that:

• The business unit involved is satisfied with the results of the project.
• Processes are in place for system maintenance.

During this stage the project operation is closed down and responsibility for ongoing tasks is handed over to the appropriate function within the department.

The business unit formally accepts the system and confirms that:

• The project is complete and the systems are available for use.
• The systems are operational and meet requirements and specifications.

Principle

Guideline

Government must be seen to be getting best value for money spent. There is an obligation to ensure contestability in procurement.

The procurement process follows the Guidelines for Contracting for Services (CO (92) 15) or relevant departmental guidelines, and is consistent with the Government Purchasing Policy which took effect from 1 July 2001².

A common approach to procurement that is open to external scrutiny is to request proposals from vendors.

Once a viable approach has been identified, vendors capable of meeting the requirements need to be identified.

It is best to follow a staged approach, eliminating unlikely candidates at each stage, while at the same time ensuring transparency and contestability.

The staged process includes:

• ROI - Registration of Interest.
• RFI - Request for Information.
• RFP - Request for Proposals.

The ROI process:

• Develops a high level outline of the project.
• Offers vendors the opportunity to indicate their interest by sending contact details.

The RFI process:

• Prepares a more detailed outline of the project.
• Offers those vendors who responded to the ROI the opportunity to respond.
• Evaluates responses according to pre-defined criteria.

The RFP process:

• Prepares a fully documented set of requirements.
• Is sent to vendors whose RFI responses were evaluated as being able to meet the requirements for the new system.
• Evaluates responses.

Consider the vendors in the RFP process.

Vendors form a critical part of the RFP process. They need sufficient time to prepare a proposal that will take into account the client's needs.

• Allow sufficient working days for a response to the RFP.
• Consider an appropriate process that enables clarification of the content of the RFP prior to the preparation of the proposal.

The RFP process is transparent and is able to assure Government of open contestability by enabling a fair and thorough comparison of vendors' proposals so the department can choose the best option to meet its needs.

Develop and document the evaluation strategy and identify the evaluation team as part of preparing the RFP.

Evaluate the proposals in a two-stage process.

The first stage evaluates each proposal against key criteria and eliminates those tenders that do not meet requirements.

Successful tenderers are short listed at this point.

The second stage is a detailed evaluation of the qualifying proposals that were short-listed to select the best solution.

This evaluation of the final contenders will include presentations and/or product demonstrations and detailed reference checks with current and previous clients of the preferred vendor(s).

The evaluation report is the deliverable from this process. It contains a recommendation for the preferred supplier.

The evaluation report is approved by the Steering Committee.

Principle

Guideline

Measuring performance is an ongoing project management task.

Regular progress reporting enables quick identification of deviations to the plan.

Use the project implementation plan to track progress on tasks. Update this plan to meet progress reporting requirements.

The project manager prepares a progress report to the sponsor (cc to project team) weekly. The Steering Committee gets a summarised progress report less frequently (monthly or quarterly - depending on the length and complexity of the project).

The project milestones will form the basis for the review dates.

Progress reports will include:

• A management summary on progress against the plan, especially milestones reached and major issues.
• Tasks completed in period under review.
• Tasks for coming period.
• Variances and planned corrective actions for slippage.
• Issues and actions to remedy (for issues register).
• Analysis of risks resulting from slippages.
• Actual costs vs budget.
• Progress against communication plan.

Variances between actual and anticipated progress may require changes to the project plan.

Formal reviews throughout the project ensures common understanding of progress.

Consider a Project Control Review within two months of the project initiation to confirm that:

• All plans are in place.
• Financial policy and details are set up.
• There is adequate resourcing.

A Midpoint Review enables a further overview check on progress. This review should confirm:

• The expected business outcomes will still be met.
• Any changes to the expected business outcomes over the period under review.
• The impact of such changes on the project.

Principle

Guideline

The contractual relationship with the supplier is critical to the success of the project.

Contract negotiation is an early task in the project plan.

The contract(s) is/are finalised or an interim agreement is signed covering contractual arrangements before the work actually commences.

The most successful projects consolidate the supplier and client risk processes, sharing the identification and management of all project risks.

Activities related to managing risk may be made the sole responsibility of either party, but both parties should be aware of all risks and the manner in which they are being managed.

The contractual relationship is a win-win situation for both parties.

Important components of the contract include:

• A clear statement of the responsibilities on each party for roles, deliverables, timeliness, resources and project and risk management. These will cover each phase of the project.
• A payment schedule that links progress payments to completion of specified deliverables and/or major milestones that need Steering Committee sign-off.
• A payment schedule that includes an amount to be retained until the end of the warranty period.

The contract for a large project should be divided into distinct phases. It will provide no commitment to proceed to the next phase without approval from the Steering Committee.

It is essential that the Chief Executive or another senior executive approve all contracts with external organisations or vendors before signing.

The strategy for the relationship with vendors is focused on performance during the implementation, not the business outcomes.

Partnership contracts are developed where risk is jointly managed.

Exceptions gaps are flushed out during contract negotiations.

Partner relationships are clearly defined in the beginning.

Consequences of non-performance by either party are clearly defined in the contract.

A formal arrangement for on-going support minimises risks from poor or non-performance of the system.

After the warranty period, a Service Level Agreement is required to ensure the vendor provides timely, and technically sound support for the system.

Good partnership relationships become very worthwhile following implementation.

Fixed price contracts work best where the requirements are well defined and the time required to implement is relatively short.

Fixed price contracts can minimise time and cost over-runs. Features include:

• A fixed price demands fixed requirements that will not change (strong change control will be needed by both client and vendor).
• Clients have an assured cost of development up-front.
• Expectations are set for both parties.
• A single vendor takes total responsibility for the success of the project.
• Suppliers face penalties if the project is not completed on time.
• Vendors tend to build in a risk premium into their pricing.

Incremental contracts can be provided on a fixed price basis for large projects where the components are broken down into a series of smaller projects, each of which is priced separately.

Features of incremental contracts include:

• Emphasis is on improving business processes through the use of information technology.
• The vendors have accurate information at each phase on which to prepare pricing.
• Need for risk premium eliminated.
• Hardware is not purchased until it is needed, thus taking advantage of the latest technology.
• The project is able to be undertaken in more manageable modules.
• Clients are not tied into one vendor throughout a lengthy project.

However, the client will not know at the beginning of the project what the total cost will be. It may be more difficult to get financial approval.

Principle

Guideline

Effective risk management is concerned with opportunities (positive outcomes) as well as hazard management (negative outcomes).

The Governance in the management of risk lies in assessing and treating risks.

High-level potential risks are identified in the Project Definition. In the Project Plan, they are assessed for potential impact, and effect on other projects.

The Steering Committee will define the areas of risk, eligible risks and the boundaries for elements of risk.

In setting these boundaries, Governance will take into account wider considerations than the specific project.

Political considerations, financial implications on other areas of the business, and various project priorities will affect the definition of risk areas for a project.

An analysis of risks and a risk management plan undertaken at the beginning of the project, highlights areas of concern that will need close attention during the project.

The risk assessment report should cover budget variances, resource problems, inadequate management support, unrealistic timeframes and "scope creep".

The risk management plan:

• Includes a detailed risk assessment that identifies all risks that could jeopardise the project outcomes.
• Recommends treatment for the identified risks.
• Includes options for accepting, eliminating or managing risks.
• Is signed off by the project sponsor before the project commences.

Principle

Guideline

Quality assurance (QA) is an integral part of the project, not an add-on at the end.

• On all major IT projects, departments will be required to provide regular, independent quality assurance reports to the Chief Executive on key issues and risks arising from the project.
• Departments will be required to forward a higher-level version of the independent assurance reports to the SSC and Treasury for monitoring purposes.
• Make provision for external QA of off-track projects, reporting to the monitoring team but charged to the department.
• The Ministers of State Services and IT will receive a regular report on the risks associated with IT projects across the Public Service.

A review programme for monitoring the communication with all stakeholders should be agreed during the formative stage:

• These project statements will summarise the progress of the project to that point.

External QA is included, that role reporting directly to the Chief Executive.

QA recommendations are implemented.

Provisions made in the implementation plan are undertaken.

Departments consult with monitoring agencies on the Independent QA assessor and the Project Definition for the Independent QA.

Principle

Guideline

Good consultation and communication protocols will increase the commitment to, and acceptance of, the recommendations and actions of the project.

Communication is about managing the relationships within and external to a project. These require planned formal and informal communication with all stakeholders - internal (including project team members, other staff in the department) and external.

These protocols are paramount in project management.

Consultation may be part of the activity of the project) or aspects of project management (e.g. information gathering). The effect of some types of consultation on the project timeframe is important.

Be realistic about how long it is likely to take for the consultative process, and build the necessary time into the project plan.

Relevant information is communicated to the appropriate people through an appropriate medium in a timely manner.

Details of the project must be communicated throughout the project.

A communications plan is produced for every stage of the project including the development of the business case.

A communications plan sets out the message, its intended audience and mechanism for timing and delivery.

It is a simple yet effective technique for ensuring openness and for implementing the communication aspects of 'damage control' should your projects require such action.

Changes to the project must be communicated to the different management and Governance levels of the project.

Project communication may be formal (e.g. brief, mandatory regular meetings) or informal (e.g. 'chats in the corridor'), written or oral, paper-based or electronic (e.g. on the Intranet).

Principle

Guideline

Good change management practice ensures that the impacts upon the organisation and its people are identified and managed.

Develop a change management strategy and plan at the initiation phase. This plan should include:

• Identification of the main organisational impacts or potential impacts of the project and how these will be addressed.
• Identify the processes that will be used to assess during the design phase the scale of changes to processes, future skills, structures and ways of working.
• Identify the consultation requirements to satisfy employee contractual arrangements and the department's human resources policies.
• Specify the processes for managing and communicating the impact of changes upon departmental clients or other key stakeholders.
• Link the change strategy to the communication and consultation processes by stating the principles that will guide these activities.
• Set out the approach to training and how this will be developed and delivered.
• Allocate responsibility within the project team for oversight of change management issues.

Obtain Steering Committee and Project Sponsor sign off to the change management strategy.

Communicate change management issues and their resolution to the Steering Committee, to the project sponsor and in normal project reporting.