You need to be agile!
You need to scale up!
You need to DevOps!
You need to industrialize!
You need to ensure business continuity!
You need to be agile!

A delight for any ICT department.

The range of will, need, wish, observation is huge and, at times, conflicting! You bet that for ICT it can be overwhelming.
And for the all inclusive subverts, the funny thing is, we do all of it! And sometimes at the same time…

I have seen concomitant projects ran in agile or standard methodology. Ability to do so is linked -and only- to the PM capabilities and its team. A team, in itself needs all required roles to have the right versatility to get things done.

You can industrialize a lot of actions, but it has to accommodate the fact that it is each time a different “car” coming out of the supply chain! Yes, engineering teams are making a different “car” at each round, that is their job, duties and -hopefully- fun.
And that different “car” is deployed through the same delivery line! Can this really work? It does, sometimes it is rock’n’roll, but it does work. It is hard, but it works. Level one and two support are usually more industrialized. Level three and projects teams needs a very consistent method, the method must be industrialized.

John Gall in 1975 said:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

This became Gall’s law.

But what it means (while writing more on this post, I cannot miss to mention that I recall Julian Browne’s one and MBA complexity approach) is that everything is interacting with everything. To be agile and quick, you need to be small. A small team will limit the complexity to what they can actually handle as a …team! And thus, it should deliver simpler systems that work. Agile is near lean and lean is near Scrum… And perhaps an enterprise architect would be helpful for keeping the house tidy, what do you think?

And if you look back to the customer value chain, or service value to the user, unit, business, etc. Make sure that you work on something they are sure they want. Something that they have thought through. You can plan one year in advance, you can estimate huge programs, but if the end goal of the customer is not known, there are -real awful- chances that you are loosing time. Time that you could therefore better use on building for the ones who have a plan, for the ones that are ready.
And worst, any framework to shape and to somewhat have a tangible view is there only to make you feel safe, because, again, without knowing what is to achieve and having dug the subject, you can only have a superficial view.
Is there worst? Yes! Should you not know what is needed… any consultancy firm will be ready to help. They smell the company blood or desperation from far… and are ready to help framing! Remember, they grow with third companies money. That’s their jobs.

Now, from all conversations about digital transformation I have been through, the here above complexity and reality always go with -at least- three components:

• The Pace. Meaning the speed at which a digital service might hit you
• The scale. Meaning the order of magnitude the service might have on society when it is out there
• The relation to authority changes. The reference entity has to go down the arena, it will be more exposed.

And you know what, it all explains why, it is utterly difficult to succeed in digital transformation, especially when you want it to be disruptive.

NB: John Gall (September 18, 1925 – December 15, 2014) was an American author and retired pediatrician. Gall is known for his 1975 book General systemantics: an essay on how systems work, and especially how they fail…, a critique of systems theory. One of the statements from this book has become known as Gall’s law.