Outcome Based Procurement

Across all industries, organisations are under an increasing amount of pressure to achieve and deliver more value within a constrained budget. This has resulted in organisations turning towards an Outcome Based Procurement model for a solution.

What is Outcome Based Procurement

Outcome Based Procurement is significantly different from other more traditional procurement models. The contracts derived from this model focus more on the ‘What’ than on the traditional ‘How’, this means that organisations can focus on defining to a service provider what they want instead of trying to provide that themselves and thinking of the how to provide it.

This procurement model works by the organisation providing outcomes that they want met. This removes the need for the organisation itself to come up with a solution, instead the organisation transfers this responsibility to a service provider.

The service provider is then free to develop a solution as they see fit, evolving the solution to any technologies that might suffice Since service providers are equipped to host services it means that an organisation doesn’t have to send huge amounts of money implementing and maintaining a service.

Ever since the early 1960s interest for Outcome Based Procurement has increased to a point where organisations like Rolls Royce have adopted this model into their own support and maintenance contracting model. This was used for the maintenance for their commercial jet engines. Rolls Royce was then able to charge customers per flying hour instead of charging customers for repairs/maintenance and parts required to keep the planes flying.

How does it affect an organisation?

This growing approach to procurement can add some serious benefits to an organisation that decides to migrate to it. The first benefit of Outcome Based Procurement is the potential to save considerable amounts of money because of the way the model works, this means that the development of the solution is shifted to the service provider.

Since the service provider wants to save money whilst earning money too, they will want to come up with the most cost effective solution they can so they can earn the most amount of money possible from the contract. This means that the provided service is the most cost effective solution which meets the set objectives without going over or under the needs of the organisation which could happen with a more traditional approach.

Furthermore, this model allows for benefits that help both the organisation and the service provider. One of the key benefits of Outcome Based Procurement is the fact it supports innovation for service providers which is finally provided to organisations. This allows for faster development of better solutions. This links in with the other benefit that service providers can be extremely flexible with how they deliver a solution, adapting to new technologies without being limited by organisational specifications. Overall this provides an organisation with a better solution to their ‘Wants’ without having to worry about the ‘Hows’.

Challenges facing Outcome Based Procurement

There are however some challenges that face Outcome Based Procurement.

A different mindset is required of those defining the outcomes so that they can be interpreted correctly by the service provider.

This mind set means that instead of going into great detail e.g. “A Customer says that they want a desk built out of a certain material using certain joints and have enough room for a computer” the outcomes would be e.g. “A Customer says that they want a desk strong enough and with enough room for a computer”. This way it’s still meeting the goal of the customer but allows the service provider to be flexible with how they provide that solution (“The Desk”).

Another challenge that faces Outcome Based Procurement is that organisations must choose appropriate service providers for specific services. Many service providers resist having to take on a big risk service if they are not equipped to handle it. This could also link to the previous challenge where the wording of your outcomes is crucially important for when the service provider goes to see if they can meet them or not. Being able to maintain that mindset is critically important to this model.

Pricing can be challenging when it comes to this model because it doesn’t work off of lump sums or fixed fees like normal models. Instead the final fee is based off the achievements that are met by the service that is provided. Even though this drives innovation because the service provider will be driven to provide the best service to earn the most amount of money, it could also cause issues if the service provider doesn’t provide the required achievements.

The biggest challenge when using Outcome Based Procurement is mainly with how employees deal with procurement within their organisation. The key point is that employees who previously ran the services have to relinquish control of services to service providers. This step is critically important as service providers cannot develop the best cost effective solution if the services are still in control by someone within the organisation already. With further training and insight into how the model works, this can be overcome.

 

Summary of Outcome Based Procurement

Organisations are under a lot of pressure to reduce the costs annually and to increase the value of their own services, whilst still producing results and maintaining a competitive attitude using innovation. This has caused a wave of organisations to adopt Outcome Based Procurement to help mitigate the issue of over expenditure and allow them to lower costs whilst keeping services and boosting their value. As more organisations become familiar with the model, the advantages of the model will grow as they get more publicised. This means that this Procurement model is set to grow and expand into many organisations and it’s important that all parties understand the challenges that face it but more so the advantages.

Some benefits of an agile approach to Enterprise Architecture

It is perhaps true to say that the effectiveness of Enterprise Architecture varies from organisation to organisation, and it would appear that the differentiating factor in the success of practices is the level of acceptance from senior management teams.  Organisations which value the contributions enterprise architecture can make in aiding business decisions where IT is a contributing factor, can reap the benefits of a joined up approach when realising institutional goals and ambitions.  Let us not forget that enterprise architecture is not just about IT, it’s about bridging the gap between the services which IT can provide with the needs of the wider organisation and the strategic direction it is taking.  When permitted to do this properly enterprise architecture can be of real benefit and could be considered a strategic differentiator.  No longer will IT do IT for IT sake, instead sound business decisions can be taken in the full knowledge that the support provided extends beyond the tin and wires of 20th century IT into a meaningful, fully-rounded service offering to support and advise the decision makers and strategists navigating the fast-paced world of digital business today.

The practice of enterprise architecture is changing, the perceived ivory towers of enterprise architects are crumbling, this can only be a good thing.  Irrespective of the placement of enterprise architecture within an organisation, either within an IT department or elsewhere, those towers have been a barrier to the adoption and ultimate success of enterprise architecture within many organisations.  The practice of enterprise architecture today is becoming more agile in its approach, knowing when good enough is achieved and being able to build from that is an important tool in the EA’s bag of tricks.  In the past it has taken too long or has cost too much for the entire baseline architecture to be captured, in taking this approach enterprise architecture has failed before it has begun because that task will never be completed, it is an ever moving beast, even with solid change control in place.  Capture just enough to understand the estate and move forward with it.  Additionally, architects should be careful not to fall into the “computer says no” trap, rejecting initiatives which are meaningful to the organisation just because it doesn’t fit the current architecture is a mistake and will only lead to curtailed practices or circumvention of policy etc.  It is really important for enterprise architects to work collaboratively across the organisation with stakeholders who have a vested interest in seeing their own part succeed and seek accommodation wherever possible, delivering to business need whilst attempting not to accrue too much architectural debt.  Architects will never ride off into the sunset after having saved the day, we should be the unsung heroes of organisational success.  As each area of your organisation improves and succeeds adding to the success of the whole, the satisfaction is knowing you have played your part and things are getting better.

Adding Value

There are many areas where enterprise architecture can add value to an organisation both inside and outside of the IT function.

Collaboration

As previously mentioned, the concept of enterprise architecture existing within ivory towers has been a hindrance to adoption and/or acceptance in many organisations.  It is probably fair to say that this perception is brought about by challenges in communication; EA’s communicating in a way they understand which is perhaps overly complicated or not presented in a way which is relevant to their stakeholders.  A fairly new approach in EA circles  would appear to be a collaborative one, rather than just producing reports and other resultant information, work hard to engage stakeholders and take them on the journey with you.  Share the experiences, enable systems and processes within the EA function which not just permits but also encourages participation by those with a vested interest in the outcomes.

Figure 1: Goal to delivery view based on collaborative interactions

Figure 1: Goal to delivery view based on collaborative interactions

This in turn helps promote a more agile and flexible approach to enterprise architecture, engaging early with stakeholders and working with them, taking their ideas on board, examining goals, drivers, requirements etc. will allow a more complete understanding of the need, a more complete architecture being captured for any given transformation and increase the speed of delivery.

Figure 2: Work package delivery roadmap in developed in conjunction with stakeholder

Figure 2: Work package delivery roadmap in developed in conjunction with stakeholder

Strategic Planning

Enterprise architecture is in an ideal position to aid their organisation with strategic planning activities.  The knowledge of how the business and elements thereof interact with each other, information and underpinning technology components is a valuable asset to any decision making body.  The inclusion of people, process, requirements, constraints and goals within the architecture enables a go to resource for information about almost everything.  The presence of business capabilities and competencies along side, documented current state and future state models allows gaps to be identified whether in technology, business process or somewhere in between; it can help with identifying process improvement and efficiency gains for the whole organisation or its sub-components, remember technology is not the answer to all problems.  Disruptive technologies also enter the fray here, constant awareness of what the next big thing is likely to be in your sector, an understanding of its likely benefits to the business and where it could fit within the architecture so as to be used to best effect can aid with planning cycles in terms of “… perhaps it would be wise to delay this initiative until this new technology is available.”  The use of roadmaps outlining business capability and goal realisation are really useful in this scenario, especially when augmented with financial data to provide a cost/benefit view for stakeholders.

In a similar vein the same knowledge can be used to inform more localised business planning processes, to help set the roadmap for individual departments and how they are to realise their own goals.

Demand and Innovation Management

A solid understanding of all aspects of an organisations architecture estate aids with the processes of demand and innovation management.  As described above this understanding needn’t be complete, just good enough to allow sensible judgements to be made as to the resource needed to facilitate inbound requests for new capabilities or services.  Constraints put in place by enterprise architecture around technology, applications and information within the system can be leveraged to see quickly if and idea is likely to fit within the environment, then further simple analysis can be performed to examine how and where it will fit and finally examination of business benefit can be layered on top to give a full picture, given a sensible understanding of your baseline architecture this is not an onerous task.  A collaborative approach can also be taken here, and indeed in my opinion at least, this would be sensible to do. Software tools exist to aid in these areas and can be leveraged to engage stakeholders and other business functions in the development of underpinning IT which may be of interest to them.

Figure 3: Innovation Management Ideation/Gamification View

Figure 3: Innovation Management Ideation/Gamification View

Software tools which allow direct integration of innovation management and enterprise architecture data are beneficial here and provide another collaborative agile edge to the practice of enterprise architecture, such as the one used here from Corso Ltd.

In summary

Modern, agile enterprise architecture techniques enable businesses to harness information sources to help the business make key decisions in and around the IT estate and connected areas.  It should no longer be a function within the business which is only understood by those practicing the dark art.  A collaborative approach will provide better results, but of course that very much depends upon individuals and individual organisations and the governance in place to enable and drive this way of doing things, and if achievable the business will realise a much better service offering from IT than in years gone by.

Public Cloud Strategy – A High Level Approach

The Plymouth University IT Committee challenged Technology and Information Services (TIS) as to the lack of a formal public cloud adoption strategy for the university; ergo TIS has been challenged to commence the migration of PU storage and compute services to a public cloud environment at the earliest opportunity, incurring minimal cost, risk and service disruption.

This is not a trivial objective and must not be undertaken lightly, rather it requires a complete change of ethos and the adoption of a different approach to ICT.  In short it necessitates:

  1. Start thinking an ‘agreed strategic approach ’ and stop thinking ‘project’
  2. Unilateral agreement across TIS of that strategic approach
  3. Careful planning to:
    1. Minimise risk of service disruption
    2. Establish methodology
    3. Determine resource requirement
  4. Correct and appropriate resourcing

Adoption of an agreed public cloud strategy, combined with correct planning, will better position the university with respect to service resilience, transparency of spend, agility of service change/addition and improvement of TIS’s service catalogue and reputation.

Without a TIS unilateral agreement and/or poor planning the university will end up in an inferior position than today; services would likely be setup and configured in an ad-hoc manner with little or no consideration given to resilience, cost, policy-based automation, service availability and little or no agility to change.  This will seriously and negatively impact TIS’s ability to deliver change.

Strategic approach

  • 80 percent of service/applications to be cloud or public cloud based by August 2018
  • Stop thinking ‘physical’ and/or on-premise
  • No service/application to be considered in isolation
  • All services/applications to be considered in relation to all others, including security and data
  • All services/applications to be refactored to ensure ‘best fit’ for user experience, security and technology
  • All services/applications that store, process or transmit data to utilise a cloud based Enterprise Service Bus (ESB)
  • Refactoring order of preference is Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), Appliance, Virtual Machine (VM)
  • Start by migrating low numbers of small, simple services/applications
  • All services/applications to be fully monitored
  • Fully document all aspects of each service/application including service/application lifecycle
  • All changes, upgrades and new services/applications must adopt the above approach
  • Digest and understand the art of the possible
  • Proceed to more complex services/applications
  • Continually review approach and revise as appropriate

High-level plan

  • Select an appropriate public cloud service – suggest Azure in the first instance as PU is primarily a Microsoft house, ergo Azure provides the best current technological fit
  • Select an appropriate certified public cloud specialist partner for technological and configuration guidance for Azure; discovery discussions have already taken place with SilverSands
  • Extend the PU infrastructure to the chosen public cloud (Azure?) – this must be performed under advice and guidance from the certified public cloud specialist partner; services might include but would not be limited to:
    • Connectivity – consider installing an Azure Express Route
    • Active Directory – consider Azure Active Directory or Azure Active Directory B2C
    • DNS services – consider Azure DNS
  • Migration to public cloud requires all TIS teams to be aligned and acclimatised to perform as required by:
    • Learning how the chosen public cloud (Azure??) works
    • Testing against a variety of applications, starting small and simple and then increasing complexity
    • Meanwhile planning simple early migrations
    • Understanding optimisation
      • Process improvement
      • Switching servers on and off according to demand
      • Virtual machine lifecycle management – clean the sprawl
      • Stop thinking ‘physical world’  – start thinking service portfolio to the user-base
    • Understanding the need for, and use of, policy-based automation
    • Implementing appropriate backup and disaster recovery  solution
  • Minimise virtual machine sprawl by restricting TIS’s use, order of service implementation must be Software as a Service, Platform as a Service, Infrastructure as a Service, appliance, virtual machine
  • Enable a public cloud service for PU users with appropriate controls, costing and transparency

Known issues

Issue Rationale Solution
Cloud first strategy or not? Some TIS teams already adopt a cloud first strategy in-line with Enterprise Architecture Policy EA-POL-008[1] and EA-POL-014[2] –  other TIS teams do not conform to that strategy All TIS teams MUST be aligned with the cloud first strategy as required by the university
Data spaghetti There is no standard approach to application integration causing massive inefficiencies, potential for security breach – no-one knows who’s using which data for what Introduce an ESB system by system
Application refactoring The majority, if not all, on-premise applications are not presented correctly for public cloud hosting Refactor each application as it is touched using strategic order of preference
Generic servers There are a large number of generic servers performing largely undocumented multi-service/application functions and/or service/application components Touch each server and refactor each service/application using strategic order of preference
Technical knowledge TIS has no experience in setting up, running and maintaining public cloud hosting Train staff as required
Resourcing Microsoft Partner (SilverSands) for 3 free days, Solution Delivery, Service Management (Infrastructure & Applications) Pay for more consultancy days

[1] EA-POL-008 – Enterprise Architecture Policy – Provision of Commodity IT Capabilities

[2] EA-POL-014 – Enterprise Architecture Policy – Hosting

Enterprise Architecture Priorities

As part of the ongoing work of the Enterprise Architecture Practice at Plymouth University we regularly review business requirements and University strategy and aim to align the direction of IT strategic investment to meet these needs.  Simple eh?  I completed the last round of this analysis in December 2015, and in the spirit of wishing to share as much of our EA work as possible, the diagram below shows what we have done, where we are and what we need to do next.  In effect this is the Plymouth University Enterprise Architecture Priorities Map.

EA Priorities Radar December 2015 Revision

‘Unblocking the pipes’ presentation

Alice & Sonya would like to thank you to all those who attended their presentation on ‘Unblocking the pipes’. They were delighted to see nearly 30 people were able to attend and appreciated the feedback and questions asked.

As promised, please see below, all related information:

Unblocking the Pipes’ presentation

Value proposition Template

Unblocking the pipes Q&A

Below is a link to the feedback form and any additional comments you may have would be appreciated.

‘UNBLOCKING THE PIPES’ evaluation form

For any additional information or to return the evaluation form please email alice.broadhurst@plymouth.ac.uk

 

You said We did – ‘Unblocking the Pipes’ presentation

‘Unblocking the Pipes’ presentation

09.30-10.30 15th October, Babbage 402

Presented by Alice Broadhurst & Sonya Riley, Account Managers

Following some of the questions raised at the TIS IT staff briefing Alice and Sonya would like to invite you to a presentation on ‘Unblocking the Pipes’.

  • Understand how ‘Unblocking the pipes’ works
  • Explore how business opportunities move through the pipes
  • Develop a better understanding of the pipeline

If you want to know more or have any questions, book your place on 15th by emailing alice.broadhurst@plymouth.ac.uk.

Unblocking the Pipes