Mon 10 July 2017
I recently attended a demo of a software tool for requirements management. After a few minutes showing the menus and screens, the demo became a presentation of a slide deck about the software.
It turned out that the engineer demonstrating the tool does not use it himself. His weapon of choice for requirements management is a spreadsheet!
Do as I say, not as I do.
Think of all of the situations where:
- person/team/project doesn’t follow ‘the process’
- person/team/project misuses or avoids using ‘the mandated/expected toolset’
... which boil down to an underlying us vs them anti-pattern:
- we are recommending/specifying the right thing, but they are doing the wrong thing
Now, it seems to me there are only a few core reasons why someone would do the wrong thing:
- They don’t realise it is wrong: lack of experience, information, training, or brainpower
- They realise but don’t care: misaligned motivation or incentive
- They believe that what we call ‘the right thing’ is actually the wrong thing
So for any given tool/process, maybe:
- people are unaware of it, unable to find it, or unable to login to it
- people do not understand it
- people think it is broken, inefficient, over-complicated or not applicable
- it is actually broken, inefficient, over-complicated or not applicable
That’s a whole set of potential blockers which can cause people to conclude that
...the right thing is to ignore the specified tool/process.
If we want people to actually follow our guidance, we need to remove all the blockers. So I suggest that any tool/process we specify/recommend needs to satisfy all the following:
- easily discoverable; it is obvious how and where to find it
- easy to understand and well documented; fast learners can figure most of it out for themselves
- accessible with minimum friction e.g. no waiting hours/days/weeks for a login
- works as described, and is generally applicable, efficient and fit for purpose
Maybe we should stick to pushing only the tools and processes we actually use ourselves.