Previous heading | Top | Next heading

4.2 Typical project implementation phases

Typical project implementation phases are:

• project initiation and appointments;
• detailed planning, such as more detail on requirements and implementation activities;
• acquire resources (including procurement);
• development (to fulfill business and ICT requirements, including testing);
• rollout – the initial transfer of the project products into operational use; and
• handover to ongoing operation.

These phases will have been described in the project business case, for example in the project work plan, timeframe and budget. The phases are discussed below.

Previous heading | Top | Next heading

Project initiation and appointments

Following project approval, important contributors to success are formally initiating the project, and making key appointments.

The formal project initiation involves having recorded agreement to key project parameters – such as budget, timeframe, outcomes, and communication strategy – to provide a firm basis for action.³⁴

The appointment of people to the project governance arrangements documented in the business case, and to project leadership and project management roles is a key responsibility of the executive sponsor of the project.³⁵ When making appointments to project management and advisory roles it is useful for the project sponsor to give consideration to the ability of individuals to:

• effectively communicate with, and on behalf of, any groups they represent;
• promptly identify current or impending difficulties during the project; and
• respond decisively to any difficulties so as to best achieve the planned business outcomes.

Given the large number of program implementation and business projects undertaken by some entities, there can be a shortage of people with relevant skills. Accordingly the appointments to key roles are also a valuable opportunity to develop the skills of entity staff.

Useful activities for the project sponsor to consider at project initiation include:

• arranging a project launch activity to introduce key people to each other and gain an understanding of, and commitment to, the project’s goals;
• ensuring those involved in various roles – such as members of the project board – are aware of their roles and responsibilities;
• reviewing the representation in governance processes previously agreed in the business case, and making any adjustments warranted in light of circumstances; and
• arranging independent assurance, particularly for large or higher risk projects.

Previous heading | Top | Next heading

Detailed planning

Generally, agreement to a project is given based on a description of the project requirements in the business case that is sufficiently detailed to develop a reasonable estimate of the project’s costs, business outcomes and timeframe, but which may not be sufficiently detailed to actually implement the project or to seek firm proposals from a procurement process.

In this context, the next major activity is often developing a more detailed description of the project requirements.³⁶ The detailed description of requirements may be used as the basis for procurement activity – for example, as part of the tender documentation. It will also, where applicable, be used to prepare detailed implementation work plans for internal staff which can in turn be used to prepare more accurate estimates of the project cost, timeframe and resource needs.

When undertaken, the more detailed project requirements will expand the project requirements provided in the approved business case and, as appropriate, indicate particular project products needed to fulfill these requirements.

In other cases there may be advantages in approaching the market for solutions based on the broad definition of the requirements already provided in the business case. Specific products may not be described for those requirements to be fulfilled by procurement action. It can be preferable to allow tenderers to offer innovative solutions to meet the requirements.

Even when external providers are being used for much of the project, there are usually many activities involving in house staff that will need detailed planning – such as rollout and preparation for transfer into ongoing operation.

Important activities for the project sponsor during this phase are liaison with key stakeholders who will be affected by the project’s implementation, and management of the project team

undertaking the detailed planning. In many cases the detailed planning will be done by the team which prepared the business case. However, in other cases there may be a delay between preparing the business case and approval, and the business case team may have moved to other work. In these cases, time and effort will be needed to select and brief a new team.

Detailed project planning will provide additional information about the feasibility, cost and benefits of the project. Before proceeding to the next phase – acquire resources – the project sponsor should assure themselves that:

• the project remains feasible, and that the necessary resources are likely to be available internally or in the market-place;
• the project’s benefits, cost, and timeframe remain consistent with those on which project approval was based;
• the detailed requirements have been cleared with relevant stakeholders – including user representatives for any new ICT systems;
• risks and assumptions have been reviewed and remain appropriate;
• the project business case has been reviewed and updated to reflect any new information
• including as a result of any policy adjustments or changed priorities since the approval
• appropriate probity and recordkeeping practices are in place.

Where new information is inconsistent with information provided previously to decision-makers, a judgement will need to be made about whether to seek approval for a variation to, or in extreme cases, cancellation of, the project.

Previous heading | Top | Next heading

Acquire resources

Having undertaken detailed planning, and confirmed the project remains consistent with the approved business case, the next phase is to acquire the resources needed to implement the project.³⁷ Typically these resources will provide capabilities associated with the actual work of the project, and for direct project management, probity advice and independent assurance. Where practical, it is useful to undertake forward planning and to pre-commit resources. However, in some cases the nature of resources needed may not be known until detailed planning is well underway.

Resources may be provided by:

• internal staff and existing contractor resources;
• partner entities; or
• capabilities obtained through a procurement process.

For smaller projects, the project sponsor may have a personal role in acquiring project resources. For larger projects there may be a significant amount of work, and the project sponsor will appoint a person or team to acquire the project resources.

Important activities for the project sponsor during this phase are:

• management oversight of resource acquisition – with a particular focus on key governance, procurement and project management roles; and
• investment decisions, that is, whether significant project expenditure and deployment of resources should proceed.

The resource acquisition phase will provide additional information about the availability of resources – and hence the project timeframe, and the likely cost – particularly for capabilities for which a procurement process has been undertaken. Before proceeding to the next phase, the project sponsor should assure themselves that:

• the planned resources, including those identified through procurement action, are sufficient to deliver the planned outcomes;
• the planned project management arrangements will provide them with reliable information on the progress of the project;
• important stakeholders remain committed to the project’s objectives and its priority; and
• risk mitigation activities identified in the business case are being undertaken and there are reliable arrangements to manage risk during project implementation.

Before committing resources to undertake the development work of the project, including the signing of contracts following procurement action, it is good practice for the project sponsor to meet with the relevant project governance group, to gain assurance on the value and feasibility of the project and document the reasons for proceeding, or not, with the project. For major projects, the entity chief executive, the Minister, or central agencies may need to be involved in the investment decision to commit funds.

Previous heading | Top | Next heading

Development

With resources available, the next step is the development phase – that is, creating the products of the project.³⁸ Even in those cases where the products are being obtained though a procurement process, it is prudent for the project sponsor to closely monitor the development stage.

Important issues for the project sponsor during the development phase are:

• monitoring progress – including being alert to possible difficulties or timeframe slippages, or the occurrence of any triggers for reference to the decision-maker on possible project exit; and
• focusing on the active involvement of all stakeholders – this will help ensure the details of development are in accordance with stakeholder expectations and that testing is thorough and at a practical level.

For many common APS projects, the development phase will include the two major strands of work:

• business-oriented project products requiring development including detailed policy (for example, expanding on broad policy agreed by government), associated legislation and regulations, and training for staff and other affected groups.
• ICT development work that may involve developing project-specific software, tailoring of off-the-shelf software packages, integration of new software with existing software, developing databases, and populating them with information. There may also be associated acquisition of ICT equipment, either for use in a data centre or for wide deployment (such as data input devices in public spaces).

Where the project involves two or more strands of work, it is important for the project sponsor to ensure there are arrangements to coordinate these activities.

From a senior executive perspective, it is useful to observe that development of the full range of products for a particular project may involve concepts and language that are specialised and unfamiliar to the executive. Gaining an understanding of these concepts, or obtaining advice from an independent adviser, is important in helping the executive fully understand project status reports and the implications of any project difficulties.

Achieving the right quality, of the right products, in a timely manner will be assisted by the project sponsor giving attention to:

• oversight of product testing;
• managing requests for changes to the project; and
• a pre-rollout review.

Previous heading | Top | Next heading

Oversight of product testing

Testing involves gaining assurance that the products being developed meet their specification and work effectively. Testing of some sort is applicable to most project products, including for example, publications, computer systems, legislation or new call centres. Testing can be applied at different levels, such as at the level of individual parts or components, and at the level of the system or all parts working together as an integrated product. It is possible that the components of a project will successfully pass acceptance tests but that the overall system or product does not work as intended.

Effective testing will use several approaches. For example, component level testing is quick and cheap but narrowly focused; while system testing is more expensive but provides overall assurance that all the components work properly together (see Appendix G – Types of testing on page 114 for more details). In particular, testing of any new system or product can be expected to be more effective if it includes representatives of the proposed users of the system or product.

To help provide effective testing, the project sponsor should gain assurance that:

• the range of tests planned and undertaken are appropriate for the size, complexity and importance of the project;
• reports of testing to governance committees focus on business implications and user perspectives (rather than technical aspects), and include the type and scope of tests; and
• there are arrangements to track and resolve problems identified by testing.

Previous heading | Top | Next heading

Managing requests for changes to the project

During the development stage, it is common for requests to be made for additional features or for new requirements to be met. To rule out any additional requests may mean that important lessons from the development process are ignored. Conversely, to allow many requests, resulting in what project managers call scope creep, can significantly increase the cost and duration of a project.

An important principle for managing such requests is to make a robust assessment of the value of the proposed change in relation to its cost. In this context it is worth noting that some apparently small changes may have a disproportionate cost due to the need to make adjustments to other parts of the project. In addition, there can be a significant cost in simply assessing requests for changes.³⁹

Another important issue in assessing change requests is maintaining a focus on the approved business outcomes to reduce the risk of any inadvertent shift in emphasis away from those outcomes.

Finally, a large number of change requests during implementation may indicate shortfalls in the identification of project requirements. If these change requests are a sign that the approved timeframe and budget will not be sufficient, then the project sponsor needs to consider whether to reduce the scope of the project, or to seek an increase in the timeframe and/or budget.

Previous heading | Top | Next heading

Pre-rollout review

Following a successful development phase and before implementation or rollout of the project products, the project sponsor should assure themselves that:

• the products meet the full range of project requirements, such as functionality, reliability, and operating cost;
• key stakeholders support a move to implementation and remain committed to their role;
• there is a pre-implementation measurement (‘the baseline’) of the business outcomes and associated performance indicators;
• plans and resources for an effective rollout are in place;
• where a procurement process has been used, there is appropriate protection of the Commonwealth’s position as the work is coming to an end (for example, ensuring all operational testing is completed in accordance with the contract prior to final payments or lapsing of guarantees and indemnities); and
• where there have been changes to the original project scope (such as added features, or deferral of features) relevant stakeholders are aware of the changes and their implications, and communications strategies are amended as appropriate.

Previous heading | Top | Next heading

Project rollout

Having developed the products required to fulfill the requirements of the project, the products need to be put to use. This is usually treated as a distinct project phase, covering such activities as:

• measuring performance indicators immediately prior to introduction of new project products (to help assess the specific impact of the project);
• installation of equipment and software, as needed;
• training for those who will use the new products in their work;
• publicity or communication to those who will be affected by the project;
• transferring data from obsolete or legacy systems to new systems;
• ceasing use of previous products; and
• monitoring and responding to difficulties during implementation.

These activities can take significant resources, and require detailed planning to avoid disruption or inconvenience. During this phase, it is likely that many people with little or no experience of the project will become involved or will be affected. Reflecting this, two main priorities during implementation are ensuring that the project products perform as expected when used in real life, and assisting people affected by the changes introduced by the project.

Important areas for involvement by the project sponsor immediately before and during the project rollout phase are:

• Being confident that the project team has the resources and detailed plans for a smooth implementation. This includes providing guidance to the project team on the expected performance levels and the limit for any disruption during implementation. Given the cost implications of setting very high expectations, it is reasonable that different projects may use different resource levels to support rollout, depending on the risks and nature of potential impacts.
• Reviewing the expectations of those who approved the project in comparison with the likely short-term results, and providing appropriate briefings to avoid any surprises. These expectations can relate to the expected direct benefits of the project and to the manner of implementation.
• Reviewing implementation risks, and allocating sufficient resources to provide appropriate mitigation, including the availability of options to pause or roll back the implementation elements of the project if serious difficulties emerge.
• Managing senior-level relationships with any additional groups of people who become involved in the project following its implementation. These additional groups may be those who will use the project products, those who will benefit from the project, and additional resources engaged to support implementation.
• Close monitoring of the progress of the rollout, with prompt responses to any serious issues and a methodical approach to recording issues for less urgent resolution.
• Active oversight of the communications strategy, including the timely provision of well-targeted information to those affected by the project, and effective feedback arrangements so the sponsor is aware of any issues or concerns.

Following a successful implementation / rollout phase, before closing the project and transferring the products to ongoing operational use the project sponsor should assure themselves that:

• the products, in the context of full operational use, meet the full range of project requirements, such as functionality, reliability, and operating cost;
• any issues identified during implementation have been resolved, or have had responsibility for resolution transferred appropriately; and
• legal and contractual matters for the project are properly completed.

Previous heading | Top | Next heading

Project closure and handover

The completion of the project rollout brings the project to the point of closure. In most cases there are project products – such as ICT systems, program guidelines and legislation – which will be transferred to ongoing operations.

Important areas for attention by the project sponsor during the handover stage are:

• arranging the transfer or allocation of responsibility for achieving the ongoing business outcomes which were agreed at the time of project approval;
• assisting with setting budgets for ongoing operations and maintenance – using information from the development and rollout stages;
• establishing performance measurement arrangements, to support ongoing management and, as appropriate, post-implementation evaluation of the project;
• transferring any residual work, for example, disposal of surplus assets;
• providing a completion report on the project to the decision-maker, including the results, time and costs of the project in comparison to the approved business case; and
• project closure, including both administrative requirements, and taking the opportunity to celebrate the achievements of the project team.

For more complex projects or for programs of projects, there may be important benefits which arise from the interaction of the products of several projects. It may not be practical or appropriate to nominate the operational manager of a particular product as being responsible for these broader benefits. In such cases it is good practice to assign to an appropriate executive the responsibility and necessary authority to realise these broader benefits.⁴⁰

After a period of use of the project products, it is good practice to conduct a post-implementation review of the extent to which planned business outcomes and other benefits have been achieved.⁴¹

---

Previous: Project sponsor’s role during implementation

Next: Concluding remarks