Posts Tagged ‘failed projects’

How to Destroy your Company by Building Software

Thursday, September 13th, 2007

I have worked for a long time as a Chief Program Manager and Corporate Architect/Strategist for a very big bank. I was responsible for a cluster of projects with a very big budget.

I managed 120 people in these programs. To manage all the projects a special Program Office was used. It registered and monitored all the data and most important of all, it managed all the Risks.

Later I was part of a smal Strategic Unit of the bank that was responsible for Strategy, Architecture, Alliances and Research. One of our tasks was to do a Risk Analysis of important projects.

One day when I worked at the strategic unit of the bank a huge project was announced. The budget (>500 mio) was very very big. We advised to abandon the whole idea. The Complexity of this project was too big. It would fail for sure. Many years later we proved to be right.

What we adviced was to upgrade the existing infrastructure. Many years later this was the solution that solved the big problem “how to show that not all the money was wasted for nothing“. This example shows a very important and simple rule. Big projects always Fail.

The last ten years when I was a Meta Group Analyst and Consultant I have evaluated many failed projects. All the time I found the same cause. People don’t apply “the lesson that are learned“. Sadly enough we want to “re-invent the wheel” until eternity.

I am still in contact with many highly experienced and talented people in my profession all over the world. All of us have the feeling that the world has turned completely mad.

Big advisory bureaus and important analysts are telling stories that are proven to be wrong for decades. This is not strange. It happens all the time. They have to attract attention, sell the software they have been building and keep the people they employ working.

What is really strange is that people who are working at `the other side`, called Business Believe Them. We did not believe them at that time. We used our experience. What is “going wrong in big projects” is already known for 30 years.

Managers believe packages like SAP will solve every problem. The implementation of a package that is “doing everything” has never been successful. It is a well known disaster. This is also a very important and simple rule.

A Government Agency in the Netherlands is now on a colliding course because of a SAP implementation. The loss is very big (Tax Money). It proves the simple rule.

Managers believe Outsourcing will lower the costs and increase the quality. At this moment the time-to-market in a big bank is more than 3 years, the quality of the software is decreasing and the costs are rising.

The reason is outsourcing. Outsourcing fails when the relationship between the users and the IT-department that is servicing the users is disturbed. When you don’t understand what the other is really doing you are not able to help him. This is also a simple rule everybody will understand.

I will tell you a Worst Case Scenario. The worst case scenario is a combination of all my experiences.

The first step of the scenario is the Selling of the Package. This takes place at the inter-company-network. The inter-company-network consists of executives that are part of many advisory-boards of big companies.

When IBM was in his most powerfull phase it could influence high level executives in Government (even Ministers) and Industry. The executives are trading opportunities. If you buy my packages I will buy your cars. There is nothing wrong with that.

The strange thing is that all of the high-level executives know about the big problems related to packages and outsourcing. They are adviced by low level executives that promise them that this time it will be different.

A new miracle approach is invented that will solve every problem. The current Miracle is called Service Oriented Architectures (SOA).

When the low level executives have reached the top they will be adviced by the same people telling the same stories. The funny thing is that almost nobody remembers that he is hearing the same story he was telling his boss.

The main reason is that the same approaches are given different names and different stories. This is called Marketing.

SAP is a huge software program. It has been build to do `everything`.

To customize this huge software program a software program is developed. A customer has to program this program. This is a very complex activity. The language of the programming program is very special.

Because programming the program is special the specialists are hired from a specialized company. To hire them you have to pay a “special price” (very expensive).

Most of the time the specialists are trained to become a specialist in a few weeks. They learn the trade at the expense of the customer. Hiring young not experienced people is cheap.

Highly experienced people are expensive. Most of them leave the company because they don’t like the culture of “hit and run” anymore. Big companies don’t hire people that are working “on their own“. They believe (for some reason) that big companies are providing quality.

Big companies have to use big companies because of liability. So many projects fail that they need a way of “getting back the money” when “things go wrong“.

When “things go wrong” the problem is so complex that a court is unable to solve the conflict. To “solve the conflict” specialist are hired (mediators). They are also provided by the big companies.

Implementing SAP is big business. The advisors don’t understand anything of the business of their client. This is not needed. The Business People have to tell them “What to do“.

The business people don’t understand the language of the programmers. They are afraid to show they don’t understand the specialists. They never ask questions.

When they ask questions the specialists talk a language they don’t understand. The specialists don’t understand why the customer is not understanding them. The main reason is that they don’t listen at all. They love to talk with the computer.

The most important people called users are never involved in the project. To convince the users communication experts are hired from the specialized companies.

At a certain point in time the managers become very nervous. They feel something is going wrong. They are afraid to admit that. They start to intimidate the people of the big advisory company.

Now another specialist, called an account manager, is used to manage the managers. He is telling a well known fairy tale. The project is almost finished. They need a little bit more time and of course they need more money. The managers agree. The account managers are trained to tell specialized fairy tales.

This starts a new phase. The fairy tale story is coming back all the time and the reaction of the managers is the same. The budget of the project is increasing all the time and the moment of delivery is also moving with the same speed.

At a certain moment in time the manager is replaced or better he leaves the sinking ship just in time. A new manager arrives.

He is not able to stop the project because he is not informed. After some time he knows the terrible truth. The process of telling fairy tales, the increase of budget and the movement of the date of implementation is restored. I was once a witness of a project that staid in this state for almost ten years.

The company is really in trouble when the next phase starts. This phase is `Let’s implement what we have build` because `we have to show we have build something`.

At that moment the users (the victims) are confronted with something they feared for a long time. When they are talking with friends or relatives they hear the same sad story all the time. Because there is no alternative the victims learn to cope with the situation.

When they finally have learned to use the software a new release of the package is created by the vendor and the whole process starts all over again.

Outsourcing is a brilliant trick of the managers. The responsibility for the failing project is moved to an outside vendor. They are now the object of aggression.

The managers wants to manage the Outsourcers. To do this many new managers, Vendor Managers, are created. Bureaucracy is increasing.

What the Vendor Managers don’t see is the different Culture of the Outsourcer. A highly decentralized company starts to work with a highly hierarchical company. This creates confusion.

A comparable problem is the culture of the programmers. So called cheap programmers in India are not accustomed to think for them selves. They just do what they are told to do without questioning anything. The customers expects creative programmers and the programmers expect programmed customers.

The situation is getting worse when the programmers know they are able to earn more money at a different company. They move and disturb the continuity of the project-team.

This is happening in India all the time now. Introducing a new programmer in a project takes a lot of time and disturbs the project. When the amount of changes reaches a certain level the project will always fail. This is also applicable to software-changes.

The real customers don’t talk with the programmers. They talk with the managers that are talking to managers that are talking to managers.

Somewhere in the Chain of Communication all the meaning is lost. The result is something they don’t want, the users don’t want and the customers don’t want.

Last but not least the process took so long that the market has changed. Everything starts all over again.

Do you now understand why there is such a shortage in IT specialist? About 30% of IT-projects is succesfull. This means that 70% of the IT-specialists are working for nothing.

If we add the amount of “succesfull” projects that were delivered too late or the amount of projects were the implementation phase took so long because the software was “not-usable” the percentage is even lower.

I have the strange feeling that about 1% of the projects are really succesfull. These projects are projects were a small amount of programmers (max 15) worked in close cooperation with the users. The project was given a Fixed Budget and a Fixed Time-Frame.

The target was to develop a small “package” that Could be Adapted by the Users Themselves.

My Advice

Get rid of Bureaucracy.

Calculate how many people are really programming in your company and how many people are doing other things. Plot this ratio in history and you will see the “Bureaucracy-index”. This will give you some idea about what you are doing.

Adapt what is working as long as possible.

Keep it Simple.

A team of 15 talented IT-people is capable of doing more than a group of 1000 not-talented IT-People.

Never trust a Hype. Always look what is behind the Marketing Language. If you don’t understand the technological language, ask questions and don’t stop until you understand everything. You are not stupid!

Never believe Everything is Possible with One Package.

Never create software that is able to solve many possible problems. Solve the problems that are known. Nothing more.

Never create a program that needs a program to program the program. This is a trap.

Read About Mapping when you want to know more about a simple way to solve complex problems.

Read Why good programmers have to be Good Listeners when you want to know more about the relation between “meaning” and software.

Have a Look at the Law of Parkinson:  ”A manager wants to multiply subordinates, not rivals“. “Managers make work for each other“.

Have a Look at the Peter Principle : “In a hierarchy every employee tends to rise to his level of incompetence

Have a Look at the Law of Murphy: Anything that works will be used in progressively more challenging applications until it causes a disaster“.