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, and 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 concurrent projects run in agile or standard methodology. The ability to do so is linked – and only – to the PM’s capabilities and its team. A team, in itself, needs all the 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’s a different “car” coming out of the supply chain each time! Yes, engineering teams are making a different “car” with each round; that is their job, their duties, and – hopefully – their fun.

And that different “car” is deployed through the same delivery line! Can this really work? It does. Sometimes it’s rock’n’roll, but it does work. It’s hard, but it works. Level one and two support are usually more industrialized. Level three and project teams need a very consistent method, and 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 (and while writing more on this post, I recall Julian Browne’s one and MBA complexity approach) is that everything interacts 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 at 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 losing time. Time that you could better use on building for those who have a plan, for those who are ready.

And worse, 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 be achieved and having delved into the subject, you can only have a superficial view.

Is there worse? Yes! If you don’t know what’s needed… any consultancy firm will be ready to help. They smell the company blood or desperation from far… and are ready to help frame it! Remember, they grow with third companies’ money. That’s their job.

Now, from all the conversations about digital transformation I’ve been through, the above complexity and reality always come 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, and 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.