I was involved in a huge systems development project a while ago that was a disaster. I will describe the project and try to analyse why a strong believer in the breakthough approach abandoned it completely.
Description of the Problem
A large intergrated steel mill was producing rolled steel and their costs were too high. I think the problem was they were worried about competition from the mini-mills that could produce steel at much lower price. The competition from the mini-mills at the time was not a big problem as they could not produce the high quality steel this company could produce. However I expect mini-mills were taking business away from them.. Therefore they needed to change.
What the Client Decided to Do
Phase 1 – The Study
They embarked on a major "re-engineering study" by a re-engineering consultant. The conclusion was they needed to completely change the way they made steel – they had too many products. Apparently they had started out as a custom smelter that produced rolled steel to a specific formula for each order. Now these orders were large but they conclusion of the study was they needed to change this.
Phase 2 – The Big Enterprise Solution
The client then embarked on a huge project to change the process from the initial order to delivery to the customer.
- Bought a new complex piece of software to develop the recipe for each order or product which had to be adapted.
- Formed a huge project team of people who developed the orders for the steel makers.
- They then needed a system development group to work with internal systems people to develop the systems for project. This is where I came in – I was a part of that team.
I think originally when we got involved we thought the specifications were already developed for the programs to be developed. We discovered early that this was not the case. They had concepts but this was a very complex process and major changes were required in the process before a system could be developed. So I am part of a huge team working hard to put together a huge team of designers and developers to work on this project. The team worked feverously for several years and the project failed. I was only involved for the first six months and I knew it was an ill fated project from the beginning.
Analysis
So why didn’t I propose a breakthough approach in parellel with the big project to tackle some short term improvements?
- I was on a train roaring down the track and I got caught up in the momentum.
- Who could I have talked to about the idea.
- The development company just wanted to put together a team that followed their methodology and make sure all the boxes and processes were done. We had just been approved with our process for ISO 9000 and had to follow this process.
- Maybe I could have talked to the steel maker but I would have had to step way outside my responsibilities and likely got my wrist slapped or worse. In fact I did not even think of doing something like that. I cannot remember why because I had for years talked about the breakthough approach.
- The systems developer was more interested in putting a huge team together to develop this big system that was being specified by others.
- The executive teams had made the deal so regardless of scope and cost and we were driven to execute on only the scope as agreed, not necessarily the right thing as the project evolved.
Why did I not say "the king has no clothes on"? To make matters even worse, the Schaffer team years before had told me about a steel maker they helped with breakthoughs that had embarked a project to installed new electric arc furnaces to improve their process.
Why, oh why, did I not think of that? I wish I knew the answer. I really feel I failed the whole team. I got caught up in a project that was larger than anything I had been involved in before and knew it was going badly wrong. I did not sense any readiness to take a different approach. I cannot even think of who I would have talked to about breakthroughs. Here is a highly respected company with high quality people roaring down a track to disaster. The amazing thing is that the project did not destroy the company. Unfortunately the project burnt out many really good people who worked very hard to make the project a success.
Lessons Learned
What are some things we can learn from this experience.
- Always be looking for breakthoughs. Often creativity is needed to find where the readiness for change exists.
- Sometimes we get caught up in the details and cannot see the big picture. We were following a new process and really did not know what else to do.
- The project represented a marvellous opportunity for us all. Success would have really created an amazing process. I expect we did not know how difficult it was.
- The principle difficulty was that people really did not want to change the way they did things but it was the only way a new system would improve the situation.
- The problem was complex and no trials of the approach were made.
In hindsight, I expect many people on the project team knew this project was heading for trouble but we all believed the changes needed to be made. I think the big idea of re-engineering a major operation should be done in some sort of incremental approach. I expect the concept was sound but the implementation as one big project was flawed. I think Michael Hammer created many problems with his book on Re-engineering.
I would really like to hear some comments from people who were involved in big projects.
