The older people under us have all experienced the IT wave in the nineties. The time of the IT cowboys, everything was possible, there was no knowledge about IT with the customers and technically all was much simpler: a client, a server and some basic programming skills were enough to go on adventure and write programs for your customers. Analysis and design were exceptional, let alone testing. The IT jungle was born and chaos nurtured. The customer had barely a voice since he could not argue with these IT specialists who were using their own specific jargon.
As always there was a tendency to do things better and so big and small consultancy companies started doing more and more up-front analysis, later design studies were added in the project traject. This worked quite well for a long time and is even today still often used for complex and complicated projects. Nobody wanted to admit that they didn’t know everything upfront. I remember we spent months writing lengthy analysis documents and never thought about what the customer really needed or that his requirements could change in the mean time.
In the picture above I summarize the way of working we now call the waterfall method. It all started with a brilliant idea about bringing the banking application to a tablet. Everybody was using tablets and other iPad’s and we saw another bank developing the same thing so we started a big project. We did not bother to talk to our customers (we knew exactly what they wanted) or we spend a lot of money on a full marketing survey that did not bring us any further.
So we embarked upon a couple of months of analyzing. With a small team of analysts we settled well in our first base-camp, very skilled, isolated and all very focused. We talked to stakeholders, key users, management and in 6 months time we came up with a very detailed, structured and spell-checked analysis document. Now it was time to sign-off the document which everybody did (without admitting it was far too long and that they never read it fully). Admitting you don(t understand something is difficult indeed.
The analysts went off and we settled in our second base-camp with a small group of designers. Wire-frames, technical architecture, usability, performance, scalability were now the words being used and after 2 months we had all technical issues solved and all kind of diagrams were delivered, mostly without any explanation. Analysts tend to over document, technicians don’t like documenting. Things that were unclear in the analysis were implemented as we had understood, since the analysts had left or were busy on another project.
Our last route to the top was easy. We hired developers and embarked from our third base-camp to reach the top. Everything was well described and analysed so we only needed intelligent executers. Questions were not asked since nobody liked to admit that they did not understand the well-written analysis or the fancy design diagrams. We would sound silly if we did not understand what these experts wrote down. A small amount of testing and our project was ready to go in production. We were happy and celebrated the end of the project.
In the meantime the customer took 2 months to evaluate which bank had a pc banking application that would run on smartphones. iPhones and other Android devices had prevailed in a year’s time over the tablets. There was an enormous gap between us, standing with our tablet app on the top of the mountain and the customer enjoying his android and ios app on his mobile phone. How could we ever fill that gap?