OPSASTO, An approach to enhance operational readiness


How we can  get more value out of our IT Services through sourcing them with secure and reliable operations in mind. Berlin, June-2016

When the going gets tough

Have you ever experienced a situation where after Go Live of a new application, all hell breaks loose? There are stability issues, the application is not doing what the users expect it to do and the support organisation is not sufficiently equipped to do their job. When the project is called on for a solution, it is discovered the project has closed down and the people with the knowledge to resolve the issues have gone elsewhere. In such a case an organisation is likely to be found struggling with the stability and reliability of their service for months, – or even years after its introduction.

It is evident this does not provide the best conditions for a good return on investment.  It is common knowledge that when things are not done right the first time the costs of repairing the issues will significantly increase as time passes. But not only do the costs increase, business value also diminishes because a lot of the organisation’s energy gets sucked into stabilization efforts and working around a hampered service, energy that otherwise could have flowed towards further developing the service or could have been spent on new value generating initiatives.

Download fully formatted pdf document Sourcing for secure and reliable operations or read on below.

­­­­­sourcing A new service

You might wonder, why? why?.. why! Does this keep happening?

Actually there is a good explanation.

Sourcing and service transition projects have a limited horizon, it is difficult for them look past their own shadow and prepare for the period after they are gone. When left unmanaged, this risk often leads towards a less-than-optimal or a far-below-optimal operation of the service.

Inclusion of Operations Assurance and Transition Management can reduce this risk significantly and produces a higher quality service.

Thinking Ahead, Looking past the projectS shadow

Every IT sourcing and service transition project is constrained in money, scope and time. A service doesn’t generate any value until it has gone live. Up until this point, a project consumes resources without providing any tangible value to its organisation. When the pressure on a project increases, the risk that trade-offs on quality are made that will lead to less secure and reliable operations also increases.

Common examples are critical design flaws that are accepted into production, missing security controls, insufficient support and McGyver like hacks that become permanent solutions. These breakdown risks are often accepted because of time or budget pressure and because of insufficient understanding of the long term impact.

The conundrum is that from a project’s perspective, with its limited lifecycle horizon, the tradeoffs often seem reasonable and the risks limited. However, when the tradeoffs are put against the horizon of the whole service lifecycle and operational considerations are also included in the evaluation, the outcome often will be different.  What is needed is a counter balance.Most stakeholders don’t make these value decreasing decisions because they are not engaged or have other motives than the organisation’s best interest in mind. They make these decisions because of not having the right operational insights available.

Operations Assurance and Transition to Operations (opsasto)

It is not an exception that the operational parts of an organisation are engaged in a late stage of a sourcing or transition project. It also not uncommon that its then discovered there are a number of operational requirements that have not been included in the design and project plan.

Opsasto is a structured, risk based, scalable approach for assuring the quality of an IT Service and its operation. It proposes to start the development of the service management requirements early on in the lifecycle and to include verification and adjustment activities throughout the sourcing and project delivery stages.

The methodology enhances “Operational Readiness” at point of Go Live and gives the IT operations interests a strong voice. The method proposes to include a role in the project team that has the mandate to represent operations. This will cause some healthy tension because of the different horizons and balance out the project’s shorter term focus. In addition, an organisation should also outline assurance activities and deliverables for a project to include in their scope.

The EIGHT Opsasto Assurance Areas

In the detailed project plan of a large waterfall project there can be up to and over a hundred line items for the Opsasto work stream. When using an agile delivery approach, you will include project backlog items in the backlog and include operations assurance acceptance criteria in the definition of done of other PBI’s.

The activities and deliverables that are in scope and the level of scrutiny on quality assurance applied, will depend on the nature of the project and the risk to the organisation of a security or reliability incident occurring.

Opsasto identifies eight assurances areas. All Opsasto line ‘items in the project plan can be related back to these eight assurances areas.

Budget: Ensure the end-to-end, multiyear operational costs are clear and that it is known how these costs will be (re)covered.

Architectural Assurance: Verify that the service can deliver on the non-functional requirements through test, simulation and production verification.

Support Model: Design and implement an end-to-end support model that describes the needed functions, the Service Level Objectives and selected providers that are involved in delivering the support for the service.

Knowledge Capturing & Transfer: Ensure documentation required by the support teams is in place, is accessible and can be found. Ensure training of the users and support teams has taken place.

Contracts: Ensure that SLA’s, OLA’s,3rd party support contracts, SOW’s, and any other contracts needed to deliver the end to end operational service are in place.

Tooling and Processes: Design and Implement relevant support tools and processes

Cutover Plan: a plan that describes how after Go Live the support is transferred from the project organisation to the support organisation and what the criteria are for operations to accept operational accountability.

Information Risk Management: Verify that required IT controls are in place and are working as expected (Design Effectiveness tested)Cutover Plan: a plan that describes how after Go Live the support is transferred from the project organisation to the support organisation and what the criteria are for operations to accept operational accountability.

Service LIfecycle phases where Opsasto can be applied

Not every service delivery project will have a preceding sourcing phase. Opsasto is also well suited to be applied only in the in the project phase of lifecycle.

When a service is to be sourced with an external provider, there are significant benefits in including Opsasto requirements in RFI and RFP documents. Additionally, for larger contracts it is advisable to include someone in the selection committee with a strong connection to the operational part of your organisation. From the long-term perspective, a key success factor of an outsourced service is the quality of the relationship with the

service provider. This becomes even more important when services are business critical, because these are often more tailored and you will need to rely on your service provider to understand your needs and ability to deliver.

The sourcing activities are the first steps on a path of a mostly long term and close relationship with a service provider. It’s often also the first opportunity to exchange expectations, to verify assumptions and the point where you start building a common understanding of the agreement that is being put in place.

Request for Information (RFI/sourcing phase)

After the initial market scan where you have researched which services / products there are in the market that can fulfill your needs and which companies can deliver these, you probably have a long list of possible candidates. The RFI (Request for information) step is used to separate the likely less successful BID candidates from the possible more successful BID candidates and to bring the long list back to a shorter more manageable list. You will invite the remaining candidates to enter into a more detailed and more effort intensive RFP selection round.

The common RFI approach is to request high-level information that enables you to assess if the prospected provider would in principle to be capable to deliver and can satisfy the knock-out criteria, and (when relevant) if a sustainable relationship can be built up.  (e.g. you might want to know if the company has experience with a similar product, has global presence and holds certain industry standard certifications)

There is no set standard for the RFI, however my advice is: “less is more”” Try to ask a few broad questions that enable you to assess maturity, capability on key requirements and alignment on key principles, instead of asking for a lot of details. Consider, you also have to review all the answers.

Request for Proposal (RFP, sourcing phase)

In the RFP step you will go in more detail with a limited set of vendors. What you want to ask the vendors will depend on the situation. Questions should focus on trying to ensure secure and reliable operations, that there will be facilities in place to manage the service provider’s performance and to verify that non-functional requirements will be fulfilled. The output of the RFP can be used as input for the projects service transition package, it provides the service scope and acceptance criteria.

Service Preparation (delivery phase)

scoping, planning, delivery and verification of the opsasto assurance areas.

Service Go Live (delivery phase)

Undertake production verification steps, monitor the completion of the exit criteria. The project remains accountable for operations during cutover period.

Agreement to Operate (delivery phase)

Formalized handover                  to operations, follows earlier agreed upon exit criteria. Project can release resources.

Continuous Improvement (operational phase)

Get feedback on SLA performance. Analyse the amber and red scores after six months to identify possible improvements in the opsasto process. Get feedback from projects to ensure the process stays relevant and identify learnings from changes in other processes or services.

understand what you need before seeking it

  • Do a Business Impact Assessment (BIA) to determine the impact of a major security or reliability incident?
  • Determine the Criticality, Availability and Integrity (CAI) needs using the BIA insights.
  • Determine the Service Level Requirements using the CAI insights and other business needs
  • Determine the Non Functional Requirements
  • Indicate a preference for a delivery model (SaaS, Managed Service, In-house hosting, etc.)
  • Determine if there is a need to integrate/ interface with other systems.
  • Decide if the service provider is expected to be responsible for managing the end-to-end IT Service (i.e. take on the role of Service Integrator).
  • Decide who in your organisation will be end-to-end accountable for the Secure & Reliable operation of the Service. Whoever is to be end-to-end Accountable, also will need be to be contract & budget holder. This is important to enable successful management of contract performance. One has far less leverage if one is not paying the bill.

Benefits of opsasto

  • After introduction of a new service, an organisation can focus on harvesting business value and further maturing service stead of fixing operational issues
  • More secure & reliable operation of the service
  • More reliable estimates of operational costs
  • Higher organisational readiness at point of Go Live


  • Fit for purpose approach using Risk Analysis to determine initial Opsasto scope
  • Is Scalable with project and organisation needs.
  • Can be run as an independent work stream in waterfall projects or included as product backlog items and definition of done requirements in agile projects.

Contact me

About the author


In my 20+ years of IT experience, I have mainly gained experience in the project management, service management, consultancy and IT service development areas.

Doing something sensible that also has an impact inspires me. Doing it with integrity keeps me healthy.  Analyzing a complex situation and devising an approach energises me. Getting other people engaged and seeing the whole becoming more than the parts makes me happy.  

My key areas of expertise are:

  • Consultancy
  • Project management
  • Business analysis
  • Service management
  • Bid management & sourcing
  • Solution & service development
  • Supportability and the transition management of IT services into operations.
  • SaaS/ASP and cloud services


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.