Disruptive architecture

Blog

What is your plan B?

The sun is shining and everything works as it’s supposed to be, but what is your plan B when it’s windy and rainy and things not working?

Photo: Adobe Stock Library

We have a good example from the latest IT-attack last Friday when the Swedish grocery and department chain Coop got their IT-systems hacked. In most stores, there was no plan B, so they have to close the stores, and most of them are still closed a week later.

Another example is when you plan to implement a brand new IT-solution for a new business. What happens if the system doesn’t deliver the promised functionality and/or get seriously delayed?

In Coops case, they could not even go back to manual routines with pen and paper.

What is your plan B?

Comment

No documentation

Don’t make any documention as it’s waste is sometimes said in agile projects.

The question is then how far we can go with this principle while not breaking the law.

The first step is easiest, don’t document what you are doing and have done.

The second step would then be to scrap the source code after we put it in production, as we don’t need it after compilation. It’s easier to rewrite in a new language compare to fix undocumented code.

Third step is to get rid of the developers from the files as they still may waste their brain with memories of what they have done.

Fourth step definitely over the limit, and that is assure no living witnesses from your projects. However, natural death gives the same result, but takes longer time.

The alternative is to think of what you need to document, for whom and why.

Cost of legacy

Why is Hollywood substantially better at running large projects than your IT-department?

First of all, my experience is that IT-projects are started on a whim, without proper scope, estimates, funding and stakeholder commitments, e.g. business as usual. To have a green light for a feature film, you need to have your ducks in order. You will end up with an indie film that will fail if you don’t do your homework. One 3% of them are profitable and more or less in the same grassroots league as a large IT project.

Second, a new feature film is often a greenfield endeavor and the director doesn’t need to think of the past, unless you are doing a sequel or two with you godfather. But we have TV-series that have been running for ages, they have their legacy. But they also have a production bible and a show runner. The production bible describes what have happened in previous episodes and the show runner is responsible for over arching story and that things fits together. Do you recognize the role in business and IT?

IT-project are very very seldom greenfield projects and the legacy we have is mostly not documented. Think of making the last episode of Game of Thrones without knowing what happened in previous episodes.

Third, humans and film critics (in you think the are human) define if they think it’s good enough, not yet machines, which means there is a softer success criteria’s for movies. Compare this with two different IT systems, that have different integration concepts, will not work together. IT-systems on the other hand can ship updates afterwards. So far only one Hollywood film got a major update after release.

My take on this is that within IT, we are more sloppy because we can fix things afterwards. We don’t need to get it the first time, unless it’s a spaceship, nuclear power plant or a self driving car.

Comment

Right competence for the job

You just got a new wild horse, and you need help to train her and you don’t know how.

Who would you like to get help from?

A person who trained wild horses before
A person who trained ordinary horses
A person who trained dogs
A person who looks good and is nice
I can myself

When your business is doing something completely different, who do you ask for help?

It’s easier to train a wild horse than run a transformation project.

Comment

Risks and rewards with IT

We all know that the bigger the project are, the greater the risk of failure.

Small teams, small deliveries is the essence of agile project, and they do succeed if they stay small.

But if you want to win big, you have to bet big is also a common wisdom, but how well does this work in software development?

Are IT-projects profitable? The statistics shows that only 18% of the project with less than $2M budget succeeds and only 2% of larger projects, but not if they are profitable.

Let’s go to Hollywood for their statistics for film production.

According to an article from Stephen Follows, 51% of Hollywood movies are profitable. What’s interesting is that films with a budget of $25M was as profitable as films with a budget of $100M. I.e. no difference in profit based on budget size. If we instead are looking at profitability for low budget films (< $3M) is the statistic show that only 3.4% are profitable. If we only look at profits for them with teathrical release, 30% is profitable. E.g. less profits with smaller budgets.

Profitability in Hollywood is on average 7% of the revenue. Compare with Spotify, a company celebrated for there software development, who turned profitable after ten years, with an operational margin of 3% for Q3 2019.

So far can we conclude that the dream factory is much more successful in running large projects that the IT sector, where large programs regulary fails.

Traditional banks have a profit margin of 10-15%, in spite of the fact that they usally can large IT projects. Most fintech companies are not profitable, so we don’t get any help from that sector.

Automotive, a sector as old as film have as an average a negative profit margin of -4.4% for the last ten years, but some smaller brands had profit margins near 10%.

Is your IT helping you to be profitable?

Comment