How CIOs benefit by getting multi-speed IT right

For organizations today facing unprecedented disruption, agility is key. But is there just one way to achieve it? My colleague Kit Friend elaborated on the risks of adopting a hybrid model when your company isn’t ready or able to go all in on Agile. Now, I want to share with you a model that intentionally includes multiple delivery methods, including waterfall and Agile delivery: meet multi-speed.

<<< Start >>>

---

Why CIOs should go all in on Agile to avoid chaos

READ MORE 

---

<<< End >>>

Multi-speed is more than just delivery methods

Multi-speed is not a stepping-stone toward going fully Agile, but rather a target state for your delivery operations. It recognizes that not every team or part of the business will work at the same speed. Technologies, team structures, business stakeholders and delivery methods employed throughout the enterprise shape a landscape that can’t be easily forced into one or even two speeds.

When it comes to multi-speed, chief information officers (CIOs) understand the why, but not necessarily the how. An Accenture survey of some 900 executives found that 88% believed that the IT organization needs to broaden its scope and keep pace with the evolving needs of the business. 70% believed that their IT organization could operate and simultaneously support multiple business objectives; and yet 81% stated that most IT organizations don’t know how to operate effectively while supporting multiple objectives simultaneously.

Multi-speed IT is an approach to help choose the most appropriate model for each service or team, reducing the dependencies between them. This is not an attempt to help with the transition to Agile or reconcile different needs, but rather a description of an ideal target state.

Operating models are more than a delivery method for a problem. Multi-speed IT looks at its dimensions to shape an approach for each team and enterprise.

Four criteria to assess if waterfall makes sense

So, while Agile methods seem like the way to go in many cases when might waterfall be more suitable to retain in an organization? Consider these four criteria to make that assessment:

1. The level of change is very small, so that having stable teams isn’t economically justifiable.
2. The technology architecture does not allow for frequent releases (e.g., there are many dependencies with other systems).
3. An existing waterfall-based company culture and associated constraints are difficult to alter in a short timeframe (e.g., different teams or even vendors own different parts of the delivery lifecycle with complicated handovers between them).
4. Initial delivery of one-off initiatives where the level of change in both scope and technology can be contained (It could be, however, that after the initial release, Agile methods could still be preferable and should be considered during the design of the platform’s target operating model).

To sum up, waterfall often makes sense in situations with a clear best practice (e.g., a 6 week build of a social media marketing campaign) there isn’t a long change pipeline and where multiple handovers in the delivery lifecycle cannot be altered; while Agile is suitable when the situation calls for being fast paced, collaborative, and explorative with tight feedback loops.

Multi-speed IT needs to enable agility

Multi-speed requires CIOs to shift gears, so that their teams can deliver change in a way that is dynamic and responsive to the requirements of each business area. Agility is a valued trait for the C-suite in any operating model, including multi-speed. Multi-speed IT, as an operating model design approach, stems from the need to introduce agility in the operating model, not necessarily equal to adopting Agile methods. The risk is that multiple delivery methods in a single organization may cause different methodologies to clash at project (team), program (product) or portfolio level. The benefits of adopting a multi-speed IT approach could be lost, with an even worse result than adopting a single methodology.

<<< Start >>>

---

Move fast to thrive: Intelligent operating model

READ MORE 

---

<<< End >>>

Key rules to design a robust operating model

Multi-speed IT operating models are unavoidable in today’s fast-paced business environment, but they are not easy to design or implement. These key rules help avoid being worse-off than using a single delivery methodology.

• Define your teams (or parts of value streams) to enable independence
• Select a single delivery method for both teams and portfolios to avoid changing resources and team structures
• Use clearly defined delivery methodologies
• Leverage project management tools to unify efforts at the company level
• Organize work based on a single list of prioritized initiatives
• Delegate funding and prioritization decisions to portfolio level to ease the process
• Create communities of practice for different practitioners, to resolve any complexities

Gearing up for growth using multi-speed IT

<<< Start >>>

<<< End >>>

<<< Start >>>

<<< End >>>

<<< Start >>>

<<< End >>>

What to keep in mind as you begin the multi-speed IT journey

To have a well-planned, executed, and logical process of knowing multi-speed, a few things are important to keep in mind.

• Acknowledge the journey: Make everyone aware that a transition to a new operating model is underway and let those who are excited for the change (e.g., their teams transitioning to Agile methods) be the first movers. This will help ease the fears and concerns of others who are more uncertain.
• …but do communicate the destination: It’s important that both company leadership and middle management are fully behind the idea that agility is the ultimate aim.
• Governance should lean in: Portfolio managers and central teams such as Architecture and Security can and should be part of the discussion for the new target operating model, so that they don’t inadvertently block the teams they support.
• Establish clear ways of working: Good rigor around processes and adoption of recognized delivery methods is essential. Consider which teams would benefit from a particular methodology and ensure the conditions for their success.
• Set reasonable expectations: Be patient. Many organizations don’t even start to reap benefits of agility for the first two years, even though the longer term benefits of business agility are still clear.

Remember that during any transformation, different areas of the business will be moving at different speeds towards being more agile and will have different targets. Spoiler: there’s no end point—once over the horizon, it’s a quest for continual improvement.

Thanks to my colleague, Kit Friend, for his contributions to this blog.

See more IT Strategy insights.