How to decrease lead time in four steps by taking ownership of the demand-to-deploy value chain

Operations

There are many questions to answer and decisions to be made before a business idea gets turned into a delivery from the IT department. Is the request reasonable and possible? Is it safe to put into production? How and who should develop it? Does it have financial approval?

With regard to IT’s role as business partner and enabler, one could argue that excellence in going from idea to implementation is one of the most important capabilities an IT department has. If IT lacks this ability, building trust as business driver is simply not possible. Excellence in transforming ideas into deliverables means developing smart solutions to a predictable time and cost. Achieving time and cost predictability is done through consistent process work.

Nonetheless, surprisingly few IT departments have a demand-to-deploy (D2D) process. The activities that involve capturing ideas and transforming them into deliverables are divided between different departments and so is responsibility. But nobody is responsible for moving the best ideas into deployment in the best possible way. Even ITIL neglects the demand-to-deploy value chain. It is mentioned as Requirement to Deploy in the Open group IT4IT reference Architecture but not yet widely used. This article will explain how an IT department can take ownership of the demand-to-deploy value chain in four steps.

Many IT organisations have an organisational structure of plan, build, run and a CIO office, or similar. What often gets lost along the way is the responsibility of value chains that cut across more than one department. Shared responsibility is nobody’s responsibility. The risk for sub-optimization in each organisation is substantial due to the fact that no one has the overall responsibility to drive efficiency and effectiveness. How many different ownerships throughout demand-to-deploy is there in your IT organisation?

List of possible ownerships throughout demand-to-deploy

  1. Demand: Business CIOs or business engagement are responsible for the demand process.
  2. Project Model: The PMO (Project Management Office) is responsible for the project model but not for enhancements.
  3. Development Models: The architect board or the development teams themselves are responsible for the development and test models.
  4. Change, Release and Deploy: The Service Management office (SMO) or IT operations are responsible for the Release and Deployment and most often running the CAB (Change advisory board)
  5. Request for Service: To make things even more muddled, there is also a vendor management team responsible for the Request for Service (RFS) process, i.e. how to request enhancements or projects from the vendors.

demand-to-deploy-diagram-web

The business only cares about results from an efficient process

The business doesn’t care about IT processes. The important thing is that ideas are transformed into requests and that requests quickly are implemented to a predictable cost. Hence, the business is only interested in the result of an efficient process – a predictable, measurable, and optimised process for its purpose. Too many IT organisations deliver inaccurate or limited reports on when demands will be transformed into a deliverable and at what cost. This is because there is no overview of the demand-to-deploy value chain. There are no reports to present because no one is measuring the entire value chain.

IT organisations have owners, managers and administrators for many different processes, but no such roles exist for the demand-to-deploy (D2D) value chain. To solve the major issues, some standard process solutions are needed.

How to decrease lead time in four simple steps:

  1. A Process Owner high up in the IT organisation must take on the responsibility and authority. Suitable positions could be at the CIO office or similar.
  2. Appoint a process manager working for the process owner.
  3. Clarify the demand-to-deploy value chain from start to end in order to identify major bottlenecks and to start measuring the process.
  4. Implement governance so that any changes in the processes affecting demand-to-deploy are coordinated with the demand-to-deploy Process Manager.

Most people are surprised by how many different views there are within IT departments on the demand-to-deploy value chain. These different views can only be identified once the entire demand-to-deploy value chain starts to be mapped out. The benefits of the improved process work listed above include clear communication internally within IT and with the business as well as setting the right expectations.

It is first when a clear value chain has been established that KPI’s can be presented to the business (e.g. time to execute an enhancement from demand to deployment or how many requests gets deployed during a year). With KPI’s like these, better estimates for future requests can be provided – both in terms of time and cost. Working with the entire demand-to-deploy value chain instead of sub-processes will decrease the lead-time over time. And the trust in IT as a business partner will increase with more accurate estimates and decreased lead time.

About the author

Rolf Svärd is an IT Management Consultant with a passion for change and improvements. His key competence areas include governance, process development and service management. Holds a Licentiate degree within the field of business process development.


Related Articles


Engaging business in IT sourcing – the fine art of demand management

Sourcing

Results from 3gamma annual insights survey shows a clear disconnect between IT sourcing strategies and business outcomes. Companies are struggling with aligning IT sourcing and business requirements, and IT seems to be left on their own in designing and developing approaches to IT sourcing. The effect? The ability to support an ever-changing business is negatively impacted and a cost paradox is created: IT organisations with a focus on cost optimisation risk inflicting additional costs on the business.


The directional IT strategy: Seizing game-changing opportunities through end-to-end agility

Strategy & Architecture

To keep up with a fast changing environment where competitive advantage and best practices are short lasting, organisations need to adopt an agile approach to IT strategy – enabling them to explore, identify and seize game-changing opportunities.


Successful transition of business application services

Change Management

Across many businesses, the way in which support for its key applications is provided has changed over the past few years. It has evolved from a model involving…


Interview with Tony Davis, author of “Agile & PRINCE2: The best of both worlds”

Change Management

Interview with Tony Davis, author of “Agile & PRINCE2: The best of both worlds” outlining how Scrum or other agile approaches can fit within a Prince2 governance structure. Here, Tony goes into some of the practical issues and pitfalls companies often face when implementing agile methodologies.


The art and craft of IT management – why IT management is more than best practice

Change Management, Strategy & Architecture

The digitalization of business raises the stakes for IT. IT is now, more than ever, an integrated part of the business. Making IT work, making change stick and…