Buying a piano doesn't make you a musician

Ever since I started to deal with software, I've been taught the development mantra of the "1/3 rule".

  • 1/3 project is design and analysis

  • 1/3 project is implementation

  • 1/3 project is testing and documentation

I'll let you into a secret - it took me more than 10 years to actually find non-zero time for serious testing and documentation and it's still a long way from being a third :( Maybe later when I'm older and wiser ;) There are many other similar rules of thumb in the software world which everybody agrees about, but which no one actually holds onto...

Something very similar applies to solution deployment. When you personally need a new software tool e.g. a video format converter, my experience is that it takes about 20% of your time to get it running and 80% to learn how it works and how to use it effectively.

One cannot simply download and install an application in an enterprise environment, but an, at least, similar ratio of time usage should be applied i.e. 20% of the project should be concerned with getting the technology up and running and 80% used training users, adjusting workflows and setting new ones.

Let's do a reality check for a moment. In my own small experience a ratio of something like 95% of time and effort is spent dedicated to technological issues while only 5% is given over to user adoption. Let me know in the comments section if you have a different experience.

The total domination of the technological side over training, education and user adoption is a value killer for any new technology. Last week I bought a MIDI keyboard and some music software. Is it sufficient for me to connect all the cables, load up a sample library and fine tune the parameters to become a musician? HELL NO!

 

 

Everybody's always focused on the new possibilities of a technology, yet we all totally forget that the primary function of any technology should be to help people be more efficient in their work. They cannot be, if they do not know how to use it. One of the reasons behind this tendency might be the fact that technical criteria are so much easier to measure (e.g. application response time is <2s) than user adoption levels (e.g. 80% of users are well-trained).

I've spent the last few years mainly deploying a wiki-based system for the documentation of Business Intelligence outputs (business dictionary, report catalogue…). Does the procurement of an Encyclopaedia software make you an Encyclopedist?

When we meet a new customer who has an overflow of undocumented reports full of terminological babble, there's always an implicit expectation that the deployment of the technology alone will make order from the chaos; that people will suddenly understand the need to document and will know how to write well-formulated definitions.

The truth is that installation is only a minor task. The major one is the cultural change needed to get the user adoption of the new tool into everyday routines. Check out the following game plan overview for our user adoption of the technology. The technological side is mostly solved in a relative short Warm-up phase (!), in the rest of the phases, user-adoption activities rule.

 


What was the ratio of technology to end-user oriented streams on the last project you worked on?