People vs Processes and Tools

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.