Sign in

Start where you are: preparing for the future White Paper

White Paper

Start where you are: preparing for the future White Paper

White Paper

  • White Paper
  • Service management
  • Strategy
  • Problem management
  • ITIL

Author  Karen Brusch and Neil Robinson

May 22, 2019 |

 16 min read

  • White Paper
  • Service management
  • Strategy
  • Problem management
  • ITIL

As leaders, shapers, and service managers, you aim to deliver transformation to exploit digital products and services, to increase change without breaking anything. Simultaneously, you aim to reduce technical debt and enable autonomy across the organization. Experts are selling you a “greenfield” solution to your problem, but you are stuck in a “dirty mucky field” of traditional processes, legacy systems, services, and ways of working. No one tells you how to transform your dirty mucky field into a greenfield utopia. No one tells you how to manage a patch of greenfield alongside your existing dirty mucky field.

This white paper will communicate insights from the authors in terms of the must-delivers, the distractors, what to watch out for, and how to embrace change in the wider context of the existing organization. It will be particularly interesting to organizations where the implementation of agile methodology is a small percentage of all transformation; the challenge of delivery into context is heightened in this case.

The features of a greenfield:

  • you can independently create new practices and associated processes without impacting existing ones
  • any target operating model can be changed in its entirely
  • all technology can be built from scratch.

An example: digital cloud-based microservice solutions with no integrations to legacy IT services or systems.

The features of a dirty mucky field:

  • there are mature existing practices, associated processes, and controls in place that cannot be abandoned
  • the target operating model needs to support both traditional waterfall and agile/DevOps ways of working
  • critical legacy technology will remain alongside any new technology.

An example: your key record systems integrated to a new digital cloud-based microservice.

Your working environment may focus on new technology and ways of working. This focus may cause your working environment to overlook the importance of managing and evolving the legacy IT estate. This idea is demonstrated in figure 1.1, where someone has put new windows into a crumbling building. The structural issues will result in the new windows falling out if they are not addressed. In the same way, your new interface will collapse without that structural support.

image of a brand new window put into a crumbling building

The Greenfield

Consultants often give generic advice. They paint a picture of a greenfield where:

  • Change can happen faster and in isolation at the touch of a button and teams have autonomy to progress their minimum viable products (MVPs). Often, the definition of change is not communicated. Often, the level of change is communicated, but this not a definition. The level of change relates to code change rather than project-led change.
  • A new operating model can be implemented without considering existing models; the assumption is that the change to agile ways of working is wholesale.
  • New teams can define and implement their own controls, tooling, and ways of working; existing ways of working are deemed outdated and irrelevant. This often results in existing ways of working being scrapped without consideration given to what was working well.

Consultants will show you reference sites where this greenfield exists. They will give you a roadmap for day 1, day 2, and day 3 of how to get there. However, this roadmap will not include timescales, will imply a quick process, and will not consider the integration of your greenfield with the existing dirty mucky field.

Your dirty mucky field

So, now you have your greenfield and your roadmap, but the reality is:

  • You have to implement the greenfield alongside an existing change agenda, which will include everyday IT changes and other change programmes. How do you achieve the greenfield while protecting your existing services for external customers and their associated change agendas? How do you meet the demands of this greenfield when your record systems are not designed to cope with rapid change? How do you protect the existing needs of your external customers?

    You need to gauge how best to balance the adoption of new ways of working alongside maintaining your legacy IT estate. For medium and larger organizations, this is the stark reality: Do you re-architect the old to cope with the new, or do you accept that you will have to run a hybrid model for the foreseeable future?
  • The greenfield target operating model cannot be implemented in isolation or it will create a “new ways of working” silo separate from your existing ways of working. For example, a squad or tribe with the autonomy to manage their own change programme may not understand the potential implications of legacy services and record systems, nor the impacts to other squads or tribes.

    You may have multiple squads or tribes working on MVPs which could be impacted by a single record system. Increasing the volume of change against a service and its supporting controls may make them unable to cope with the new level of demand. Attempt to deliver an operating model that allows for autonomy and protects end-to-end service for external customers.
  • Within this new hybrid model, you will have to embrace the aspirations of Agile and DevOps ways of working alongside your existing controls, risk appetite, and ways of working. This presents a challenge wherein multiple squads or tribes autonomously develop their own ways of working, tooling, and controls or “guard rails”.
    Where controls are in place to meet risk appetite or regulatory obligations, these new guard rails will not be appropriate for your legacy record systems. The way squads or tribes will use tooling for traceability of requirements, code development, and testing is very different to the traditional, siloed use of tooling.

Your existing practices (tools, processes, controls, and operating model) are set up to meet the expectations of the current rate of change. The challenge is maturing these practices to cope with the new level of demand.

Tackling the problem

Two fundamentals of success are to start where you are (the “strategic review/current state assessment”) and to define a set of high-level principles. These are fundamental for the following reasons:

  • You need a deep understanding of existing practices, controls, challenges, and risks. Without this information, you will not understand the impacts of new ways of working.
  • You must define high-level principles to set boundaries that apply to both the greenfield and the dirty mucky field.

These fundamentals will enable you to define how you will mature and change your ways of working and your operating model.


To define your high-level principles, you must understand what is important to your entire organization, not just to squads or tribes. Stick to your principles once they are set.

One of the most important high-level principles is that there should be no duplicate processes. This means you should not create new processes, but you may change working instructions or activities dependant on the workflows involved. For example, you would not expect a new change management practice to be put in to place for your greenfield. The existing change management practice should be optimized to incorporate new ways of working, such as through an expedited procedure for iterative change.

Optimization must not make processes specific to a method of delivery, either waterfall-led or agile-led. Instead, they must identify procedures and working instructions that create flexibility. Do not lose sight of what works in your practices and controls when designing new ways of working.

All activities must be collaborative to promote visibility. Secrecy will result in suspicion, silos, and a power-struggle. New squads or tribes may not want to incorporate existing controls or constraints after being told they have the autonomy to implement change. However, you can collaborate and therefore mitigate the risk of having multiple ways of working.

The last high-level principle we recommend is that you think holistically and optimize the whole. This is also a guiding principle of agile delivery. Although you can optimize practices, controls, and tooling, you only derive benefit if every aspect is optimized. There is no point maturing a flexible process around service levels if you do not address the reporting and monitoring capabilities required to service this new flexibility. Refer to Figure 1.1; failing to optimize the whole would be fixing the window and leaving the building alone.


You must understand the state of your dirty mucky field. Ask:

  • What current governance and controls are in place?
  • What are the capabilities of the existing services that you manage?
  • What practices are in place and how mature are they?
  • What are your key risks?
  • What tooling capabilities do you have?
  • What are the constraints of the legacy estate?
  • What is your sourcing strategy?
  • What constraints exist within your current operating model?

You will need to interview people from across IT and existing change programmes and your strategic planners to undertake this kind of assessment. You will also need to review reports, risk registers, and outstanding service improvement actions. Know what capabilities your tooling supports; for example, network monitoring, application performance, or incident alerting. If you understand the current state of your dirty mucky field, it will be easier to bring together stakeholders from both the dirty mucky field and the greenfield to define the desired future state.


This activity is not about being precise. This activity is about documenting the outcomes and value required by the organization. You should define “what good looks like” rather than designing the future operating model. Stakeholders must agree about what this future state should look like. Without agreement, stakeholders may start to work in siloes and in contradiction to each other.

The outcomes that you should aim to define relate to organizational change, practice maturity, tooling capability, governance reach, and sourcing strategy. Remember, we are not duplicating processes or creating a bi-modal operating model. We are creating a set of outcomes to support the hybrid reality of new and existing ways of working that are simple and practical.


This is about understanding the gap between “where you are” and “where you want to be”. You need to document these in terms of people, process, technology, governance, and sourcing.

Some of these gaps will take more effort and cost to fill, so you will need to undertake a benefit/effort analysis. Take an iterative approach. Look for quick wins but also for gaps it does not make sense to fill at this stage.

An easy way of visualizing this is shown in table 4.1.

Image of table 4.1 Benefit and Effort analysis

Table 4.1 Benefit/effort analysis


When you understand where you want to be and you have identified the gaps which must be filled to get there, define a roadmap of how you intend to reach your goal.

You can do this with an iterative day 1, day 2, day “n” approach.

An easy way of visualizing this is shown in table 4.2.

Image of table 4.2 Roadmap of iterative approach

Table 4.2 Roadmap of an iterative approach

Day 1 activities should focus on quick wins. They are low-effort, high-benefit activities which need minimal

Day 2 activities should focus on medium investments and on key blockers that should be removed to allow for maturity.

When you reach day “n” you will be investing in significant change. These day 1/2/n rankings may vary across areas because squads or tribes and existing teams will be at different levels of maturity.

4.5.1 Simplifying and standardizing

You can keep things simple and practical by establishing a delivery type framework. This is a framework where you can achieve the following:

  • Concisely articulate the number, scope, and objectives of all types of change, providing a standard approach which must be used by all stakeholders.
  • Confirm the stakeholder groups that need to be engaged with each delivery type.
  • Standardize the outcomes expected by stakeholders for each delivery type. This allows you to normalize exception management, which is important when managing the volume of change that is expected through these ways of working.

Through this framework, you can build the agreed boundaries within which change can operate. This enables squads or tribes to understand the parameters of their autonomy.

4.5.2How to create the framework

Remembering some key principles can help to build a framework to categorize the change activities within your organization. Our recommendations are:
  • Keep it simple. Have no more than 6 delivery types; having too many will add confusion and complexity.
  • Build your framework around “what” is being delivered rather than “how”. This will ensure that waterfall-led and agile-led initiatives are treated equally.
  • Do not deviate from the pathways. All squads, tribes, projects, and programs must use the delivery types framework.
  • Tailor outcomes to match and support each delivery type. This will support a squad’s or tribe’s autonomy by giving them a clear statement of outcomes for the delivery type they are implementing.
Delivery TypeEnabling Infrastructure

Proof of concept

ObjectiveTo promote the infrastructure servicePromote greenfield service to live, for testing by trusted set of individualsExpose the live service to a random set of individualsExpose the live service to full market conditions
ScopeZero users< 100 friendly users< 1,000 usersFully live 

Cloud connectivity
Network connectivity 

Proof of concept of new service to a controlled number of friendly users A pilot delivering a new service involving a controlled number of live usersThe service is fully live and objective is met 

Table 4.3 Traditional delivery types example

Delivery TypeIncremental IsolatedIncremental Integrated


Greenfield code to an existing product/ customer journey, with no impact to service AND no impact to other downstream or upstream squads or tribes 

Greenfield code to an existing product/ customer journey, with no impact to service but impacts to downstream or upstream squads or tribes 


Squad or tribe does not require readiness confirmation from any other squad or tribe, project, or IT operational team

Accountable Squad or tribe requires readiness confirmation from another squad or tribe, project, or IT operational team


Incremental delivery of code can be deployed onto a: 
proof of concept base to improve the code
pilot to stabilize the pilot code base (e.g. to resolve any cash reports)
stable code version to undertake incident fixes

  • Incremental delivery of code can be deployed onto a:
    proof of concept base to improve the code
    pilot to stabilize the pilot code base (e.g. to resolve any cash reports)
    stable code version to undertake incident fixes

Table 4.4 Iterative delivery types example

4.5.3 Supporting documentation

Part of the industrialization process is to provide a set of supporting toolkits. Examples of these include:

  • a decision tree, which enables those involved in delivering change to identify relevant delivery types
  • a stakeholder engagement and outcomes guide to ensure collaboration and visibility (see figure 6)
  • a visualization of which non-functional requirements and go/no-go criteria are required for each delivery type (see table 4.5).

Delivery Type

Delivery Type

Delivery Type

Delivery Type

Delivery Type

Delivery Type

Delivery Type

OutcomeEnabling InfrastructureProof of conceptPilotStableIncremental isolatedIncremental integrated 







Change advisory board attendance

Executive change board attendanceYesNoNoYes


Standard change request required YesYesYesYesYesYes
Release Management 

Release Management

Release Management

Release Management

Release Management

Release Management

Release Management

Release booking required NoYesYesYesNo No
Service Transition 

Service Transition

Service Transition

Service Transition

Service Transition

Service Transition

Service Transition

Engagement required?YesYes











Image of a diagram about non-functional requirement mapping Figure-4-600x431.jpg

Figure 4.1 Non-functional requirements mapping to delivery types example

This framework will form a good basis for ensuring standardization and simplicity while supporting the autonomy of the squads or tribes.


There are several reasons for engaging with pilot/pathfinder squads, tribes, and change programmes to promote an iterative approach and gather feedback, including:

  • Visibly, actively engaging with new ways of working enables iterative improvements.
  • Engaging brings everyone together. It removes the secrecy that can infect change programmes and forces you to consider other change programmes on an ongoing basis, enabling a view of the required end-to-end operating model.
  • Engaging brings reality to the table. You should be prepared to “negotiate” with external experts who may not understand the context of your organization or its objectives


When you embark on this journey of embracing Agile, there will be attractive terminology and ways of working that could add complexity and risk to your dirty mucky field. For the purposes of illustration, we have referenced them as “mud patches”.

A high-level principle of Agile is that failure is okay. However, this can lead to a mud patch: a cavalier attitude towards risk and service. From an external customer’s perspective, failure is not always okay. Customers expect new digital offerings to work seamlessly. Customers do not anticipate failure. You need to define the boundaries of where failure is acceptable; for example, through the development lifecycle, in your pilot offerings, or in your widely available stable version.

Tooling presents several mud patches. Many products and tools are available to support agile ways of working and DevOps as an operating model. There can be a proliferation of tools across your IT estate because of the principle of allowing autonomy for teams. Many of these will be cloud-based and not supported by your IT teams. This could lead to exponential increases in licence costs and complexity, with different squads or tribes using different tools to achieve the same outcomes.

So, how do you achieve tooling efficiency? Should a squad or tribe managing a section of the new greenfield buy a plough that cannot be used in any of the dirty mucky fields? The principles of Agile tell you that you can have the flexibility to do what you want, when you want. However, the reality for a medium to large business is that any tooling to support new ways of working must be sourced through normal procurement processes. Your managers should consider the entire IT estate’s needs.

Also, any tools you purchase must meet your IT security requirements. We recommend that nothing be purchased in isolation. Ensure that your IT security team is part of the process, or you could get to work one morning and find access to your new tool has been blocked. Ask questions like, “Will I be able to access a cloud-based DevOps tool through the firewalls if it is not on the approved applications list?”

One of the biggest mud patches is the risk of “going native”. If you get involved in new ways of working, do not lose sight of what you are delivering to your customers. Service protection is your key accountability. It is easy to put the needs of the greenfield over the existing dirty mucky fields. This can lead to a damaging segregation between new squads or tribes and everyone else. Communication and collaboration are key.

As we said earlier, you will be sold the vision of a greenfield in which you can change anything without impacting downstream dirty mucky field services and infrastructure. To actually achieve this, you must remove dependencies between your infrastructure and your application layers (decoupling). This is neither cheap nor quick; you can do this for new IT services but decoupling older IT services may not be cost-effective. Do not underestimate the cost of decoupling; it means a complete redesign of the architecture of your middleware and infrastructure. The new way of architecting creates a “black box” of middleware and infrastructure for your products and applications to tap into through application programme interfaces. The redesign allows you to change coding and hardware without impacting your customers. Controls, processes, and governance that are mature and effective will already exist within your dirty mucky field. Avoid the mud patch of setting new controls, processes, and governance without considering what is already in place and effective. Otherwise, you will:

  • alienate your control and process owners
  • add complexity and risk across the operating model
  • undergo unnecessary re-work.

So, start where you are: do not design from a blueprint.


An image of a pie-chart with three sections regarding key recommendations such as having a clear capability roadmap, Understanding your context and maturity and to optimize what you have

Our key recommendation is that you understand the context of your organization and what it is trying to achieve. Be realistic; do not try to change too much at once. Attempting to create a greenfield on what is already dirty and mucky will cause confusion.

Optimize what you have rather than starting from scratch. Use methods like those described in the “tackling the problem” section to adapt for the future.

Finally, agree a clear capability roadmap with all parties. Be realistic about your blockers to success and plan to remove them in key areas to enable maximum benefit to your dirty mucky field and your new greenfield aspirations.

About the author

Karen Brusch and Neil Robinson are Service Design Consultants in Financial Services. Both have worked for outsourcing providers, as well as client organizations within utilities, public, and financial services sectors and have authored, or co-authored, strategic frameworks for ITSM on Agile, DevOps and cloud enablement. Between them, they have expertise in bid management, client liaison, design and development of target operating models, transformation strategy, holistic service design, and negotiation. Karen is a regular speaker at conferences and seminars and has contributed to a number of publications.

Start where you are: preparing for the future