Project Operational Readiness

Activities for ensuring a smooth roll-out, operation, and maintenance of solutions produced by projects are often overlooked. The objectives of these activities constitute operational readiness (OR). A good definition of operational readiness (OR) is “the capability to efficiently deploy, operate, and maintain the systems and procedures.” The main purpose of OR is to reduce operational risks, which is defined as “the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events.”

OR is often neglected because OR activities are usually not part of the project lifecycle. Indeed the job of the project manager and of the project team is essentially completed when the solution is ready for deployment. At this point, another entity such as “solution delivery” or “release management” takes over. I can’t count how many times I’ve seen IT projects linger for several months and incur significant (unplanned) costs in release management, before being finally delivered to users. In most organizations, the transition from project work to operations is not streamlined.

I believe everyone would benefit if OR was fully part of the project lifecycle. It would enforce real value delivery, improve solution continuity, reduce operational risks, and provide a more accurate picture of project costs, schedule, and scope from inception to benefit realization.

The following are important OR considerations that should be taken into account in project management.

Users are ready to use the solution

• Users are trained and have access to documentation.
• The user support procedure is documented and operational.

Staff is ready to operate and maintain the solution

• Staff is trained to operate and maintain the solution’s systems.
• Operating procedures are documented.
• The operational cockpit allows staff to monitor and control system performance and behavior with minimal effort.
• The operations and maintenance team must be autonomous, independent from the project team.

Staff is ready to manage operational risks

• There is an initial operational risk management plan. Staff has taken ownership of this plan. The operational risks management plan includes recovery and contingency procedures in case operational risks materialize (e.g. system crash, security breach).
• The operational cockpit includes permanent audit with alerting system

OR costs are taken into account in the business case

• When building the project’s business case, OR costs must be considered. Too often, OR activities are left outside the project budget although they can amount to a significant part of the budget, which might influence project selection, prioritization, and overall resource allocation at the portfolio management level.
• The cost of quality is estimated, including cost of conformance (quality planning, quality assurance, and quality control activities) and cost of non-conformance (cost incurred in case of quality issue).

OR and roll-out activities are part of the project

• Activities and deliverables pertaining to all OR items mentioned above, including solution roll-out, are in project scope, schedule, and costs.

OR criteria are included in the quality management plan

• OR activities must be part of the quality management plan, for quality assurance as well as for quality control. OR acceptance criteria must be included in the “definition of done.”
• Whenever possible OR criteria should be tested as early as possible, at gates or for intermediate deliverables for example.
• Some OR criteria are expressed as service level agreements (SLA) when the solution provides services.

OR risks are taken into account in project governance

• It is not unusual that at some point a decision has to be made where OR criteria would not be satisfied, for example as a trade-off between time-to-market and quality. Indeed trade-off decision making tends to put pressure on quality and OR because they are perceived as “less tangible” than cost, schedule, and scope. In this case, the project manager has to enable project governance by presenting the possible consequences of not satisfying some OR criteria, in terms of risks and consequences if risks materialize, and recommend scenarios where risk exposure remains acceptable. The cost of an OR risk materializing is estimated by multiplying its probability of occurrence by its cost impact. For example, not testing system performance as planned generates a 20% risk of system unresponsiveness, which would incur $1M of cost (or forfeited revenues). The cost of this risk is thus $200,000. Contingency costs should also include damage to reputation in case of external failure (i.e. failure visible for clients).

Similarly, stakeholders accountable for roll-out and operations must be part of the governance body (e.g. project board).

It is no surprise that organizations strive to hire project managers who led projects “end-to-end.” They understand how difficult it is to transition from deliverables to a solution that is effective in operation.