How to fail while implementing a new IT project in the business? The anti-guide

Business comes to IT…

…and timidly mentions that it would like to improve something in its company: organize work better, sort it out. In other words: a new system is needed.

– “For when?” IT asks.

– “Due yesterday,” the business replies. “We have just had an appointment with the CEO…”

– “If it goes well, it will be done in a year. In the case of any complications – in three years,” says IT and then bursts out of laughing.

That is how the time-to-market remains undetermined.

Is this malice or stalling? No, it is rather a sign of inertia and feeling helpless, which is the result of the lack of staff and lack of competencies. IT is one of the industries which suffer most from employees deficiency. There are not enough people to maintain the systems that have been already working in companies, let alone implementing other ones.

So, the business is on its own. It takes its toys and goes home, where the “toys” are the idea of a dreamed of a tool, and it tries to shape its expectations by writing them down. As a result, a long list full of requirements is created. Unfortunately, they are entirely mistaken. Why? Because the business is not supposed to handle this kind of problems.

The business does its own business…

…produces, sells, delivers. The sales or production does not know (and does not have to know) the possibilities given by innovative technologies and even more – project schemes. It is not capable of judging which is wrong, and which is right, so what should be implemented in the company. And there is something more: the business follows the good old pattern, the pattern of schemes which have been in force at the company for years. These misguided project requirements are sort of sacred corporate procedures poured out on paper.

This way, the unwanted baby of the IT and the sacred business pattern are combined into an order for a new system which is passed to the procurement department. What does the procurement do? Since the order came from the business, the procurement treats it like sacred, and the included requirements are considered as a definition of a ready product. So, the search for the provider begins. And because the procurement usually uses just one selection criteria, which is price in 100%, they search for the cheapest provider.

In the beginning, the least expensive provider is happy like a child who got the dreamed of gift on Christmas but hasn’t unpacked it yet. There is an assignment, a big company, a cool logo – it will look fine in the portfolio. But when the task is “unpacked,” the provider’s face falls because they see the long list of requirements – those sacred procedures, the list created by the business, which is not an IT implementation expert. This raises a question – how to carry out this assignment?

The provider tries to do something about it. First of all, they go to the architect of the project, which is the business itself, to consult weird expectations at its source. It is no go. Fine-tuning of the details does not work out.

The business knows what it wants…

…and it should be just like it was ordered. The provider is dismissed empty-handed. And they already know: all that gift, the project itself, is, unfortunately, a dud. But they still fight it; they give it a try in the IT department. They go to a project manager and say  that they have some issues. They would like to deliver something, but they do not precisely know what… And they want to do it so as to please the business, stick to the budget, and remain on a schedule as well. It is impossible.

The project manager also sees that not everything is all worked out. But he is not into the success of this business project and does not want to go into complexities of it; to fix or explain it. The PM makes it very clear: “Deliver it the way the project says.” They might as well say “tomato” – it would be just as helpful. But then it would be much better to replace the PM with a kid who would have done it with greater joy and charm.

And finally, someday – following the sacred provisions included in the contract – the new system makes its debut. It took a while, but what a relief! The business requirements have been met; the budget is not exceeded; everything is just fine. Success! But why no one is breaking the champagne? It quickly turns out that a lot of money and time was invested in the system that is far from perfect.

The story of the wanted-unwanted project is not over yet. It appears to be inconvenient not only in use but also in the resumes of people who created it. Willy-nilly, even those who did not felt responsible before, now assume it’s also their responsibility.

How to make a way out of this? After the implementation failure, the right thing to do is to make amends, save the project. But to do so, some investments need to be made. So, another amount of money is spent, and the only achieved result is sunk costs.

Still, no one is happy, even the provider, although they have earned more than they were promised from the start. To straighten out what they have done, they have to make a makeshift fix. They create a monster they would like to get rid of, but they cannot do this – still, they are the only ones that can take care of the creature. The company is dependent on the provider, and the provider is dependent on the company — a typical vendor lock.

The business has what it wanted…

…but it is not satisfied. It is difficult to be pleased with a hot potato instead of a dreamed of system. But the story of the implementation could have had an entirely different, much better end. Provided that someone with their head screwed on would have started with a question: “When there will be money from it?” But then the out-of-date implementation pattern should be called into question so that a new way could be discovered: an agile approach, working on business goals by taking small steps. And the business talk is held by the business and a consultant partner, not the provider. Building an IT system in small steps delivers better results — that’s  what I have written in my article “Blocks instead of lines. A tale of fast ROI in IT projects.”

The only question is – are you brave enough to go the agile way, or you would rather end up with a product no one wants to use?