Splitting the Timelines

Originally published on LinkedIn

Why traditional phased project approaches fail in accelerating change, and how organizations need multiple timelines (current operations, experimentation, transformation, and legalization) to enable true digital transformation.

While traditional corporations love to phase projects (sometimes to slash initial costs to justify ROI or meet any business case in the eyes of controlling department), I don’t think this is the approach to safeguard companies against a world as accelerating as today’s, especially with the cycle of inertia of large organizations.

Agility (or to be precised: manoeuvrability) is one of the key features of an Ops initiative, and it would be difficult from an organizational perspective and very costly in traditional control models to ensure that such initiatives have a rapid decision-making process.

The Illusion of Transformation

In small and medium-sized companies, the Dual Operating Model can often work well. In larger organizations, it is sometimes attempted to be mixed with agile models such as SAFe (among many others). Despite its many virtues, I see it as running the risk of competing priorities of business as usual (and forcing to make each individual sales counts) and the elements of transformation - to the point where, given current sales goals, transformation becomes difficult, impossible, and because it’s hard to let go of such an attractive word as transformation - it remains a label without much meaning, except perhaps to keep projects afloat with the higher priority implied by that label. This is how transformation dies in an environment that doesn’t realize it. The grass is painted green and its shades are selected in Excel.

Preparing the Time Machine

At the level of large organizations actually wanting (or needing) to make a real transformation at a pace at least similar to startups, at least three-four timelines are needed (cf. e.g. Three Horizons Framework).

The first one is the here and now. It’s the securing of current sales, in accordance with a company policy that agrees to consciously sacrifice a dedicated portion of it, in order to thwart blocking transformation and calm the growth streams of technological and organizational debt. This is the implementation of the message “we are ready to earn a little less, but accelerate the prospect of earning more.” This is already uncomfortable, and when you add in the fact that we’re talking about a timeline longer than a fiscal year (or the end of a board’s mandate), many organizations are already giving up at this stage.

The second timeline in smaller organizations allows for experimentation and testing of new technologies - already here would be areas of focus for the Ops team. In large organizations, on the other hand, this will most often correspond to the current technology turnaround, which is usually 6 to 24 months. This is the level of the current roadmap and alignment of project dependencies, preparing for the implementation of new products, services or offers. It is also the place where projects should be evaluated for alignment with the planned transformation and the strategy for that transformation.

The further we look in an organization’s roadmap (and most often in multiple roadmaps used to play projects’ tetris between different departments), the more projects should not so much change in terms of alignment with the transformation strategy, but should be outright canceled and replaced by those that are aligned with the transformation.

And the organization (at the CEO and board level) in turn should understand that cancelling such projects is not a failure, a loss of sales or an opportunity to look for someone to blame (usually the easiest way to scapegoat the Project Manager or his entire department), but a courageous decision that already at the level of business decisions (independent of any technologies) is a rational approach to accelerate the transformation.

The Horizon of Ops & Ops Support

The third timeline is the actual area of Ops dealing with transformation in big organizations. It should be a unit that maintains the azimuth of change on the horizon of the company’s strategy (usually 4-6 years), and when circumstances require it (and in the current world, they do), extrapolating that strategy into hypotheses over a time horizon of 8-10 years - with special attention to those of the hypotheses in which the organization will lose its current position in a given market: whether because the market will change, or because it will disappear or be absorbed by another (e.g. currently unknown; simplifying the so-called blue ocean), leaving the company bleeding customers, losing profitability, in extreme cases as a result of irrational or ad hoc decisions, going bankrupt and/or being taken over by competitors.

The third horizon in large organizations should be an area of strict reporting to the board of directors and, in special situations, even directly to the CEO. Ops in the horizon of significant transformation should have a maneuverability ranging from 2-3 months (in the area of organizational, process changes) through several weeks (in the space dealing with formal issues inside the organization, especially in the area of cooperation with external partners) to under 24 hours (when decisions require to mitigate ongoing risks). In each of these areas, I see the need for the CEO or board to have the courage to make decisions that will be exceptions to procedures that have been present inside the organization for years and also: to trust the Ops team and give them an area of delegated autonomy.

In the realities of large corporations with traditional models, I see the need for another fourth horizon. This is the area of legalization, standardization and scaling of the changes introduced by Ops within the organization. In one concept, this is a unit consisting of people from legal, corporate security, cyber security or procurement. Such a team, following the ongoing work of Ops, would be tasked with aligning the implemented changes with the organization’s policies - or enforcing changes to those policies to match the new reality. Depending on the company, this means a period of about six months to two years - and this is a time that neither Ops nor the organization, when faced with change, can wait.

In the above, at least one more step is needed beforehand: preparing the organization for change. I believe that it is about this that I will publish the next text.