"Insanity: doing the same thing over and over again and expecting different results."
Albert Einstein
Once upon a time ...
... there was The IT project.
A project different than anything The Team did before:
- a lot of R&D
- a lot of "out-of-comfort-zone" stuff (tech-wise, but with tech that's widely recognized as 'sexy')
- distributed processing (that never makes stuff easy)
- heavily dependant on maturity of Ops practices (automation, predictability & repeatability of deployment)
- invented, proposed & "sold" to the business people by IT guys
Project had:
- clear business case (it had a strong economic justification)
- massive potential for future (new capabilities, new possibilities)
- an opportunity to gain the meaningful competitive advantage for the whole company
- solid (proven) technological foundation
- at least one person with a clear vision who (it seemed so) was able to convince everyone else (team members' commitment was 100% voluntary)
In theory, project has succeeded. It was deployed to production, regardless of infancy-period problems, it went LIVE, but ...
It has died. Silently. Bit by bit.
Symptoms were more & more visible for few months. Users were asking about it, business owners were asking about it, various new scenarios were appearing every now & then, but ... team was unresponsive, avoided any work related with the product developed, postponed any plans of further development and failed to make next steps to extend actual adoption within the organization - product was live, but wasn't used pretty much at all.
The product that was developed was dying. And there was no-one willing to stop it. Regardless of the fact that pilot (in production environments, for real users) has got very nice results.
A lesson ... learned?
It's sad, but well - projects / products die & this is something we should get used to (and not get it personal btw.). My point is that even in failure there's a lesson to be learned that can be utilized in future. This lesson by itself is an incredible, empirical value that can help in making future projects / products better & more successful. So the most stupid & ridiculous thing is to wrap the whole thing in the veil of silence & just pretend to forget that anything has happened.
Regardless of method you use in delivering software, there's always a space for retrospectives, improvements, wrap-ups, check-points (call them whatever you like) - moments in time when smart & ambitious people discuss what was done right & wrong to avoid past error in the future. Because there are so many questions that should have been honestly answered!
- WHAT has failed?
- WHY it has failed?
- WHAT could we have done different to prevent it from failing?
- WHAT would we do NOW to prevent it from failing?
- Is it possible to revitalize at least a part of the product to keep some of assumed benefits?
As far as I know, there was not even a clear, shared acknowledgement statement in The Team - "OK, the thing is freakin' dead.". Most likely some people have their opinions, suspicions and insights, but there's no will to share them. No big deal, no harm done, no accountability either.
Some may think it may be due to being afraid of blaming & finger-pointing, but ... if the Team can't be honest internally, what kind of team it is?
Very sad. Makes me consider the whole thing a complete waste of time.
Pic: © bahrialtay - Fotolia.com