queue
Sometimes I am completely dumbfounded by an issue that seems to afflict many of our prospects and clients.

We are called in to help a company (back) on an innovative track. Often because the current product line is past its prime and/or competitors appear to be somehow more agile in digitisation, big data, agile development, or other recent methods or technologies.

When it comes to finding meeting or workshop dates, however, no one appears to have any free time in their calendars.

Companies working like that are doomed. Not because I think a “culture of meetings” is a problem (as a matter of fact it often tends to be), but because of simple math: Queuing follows a mathematical scheme called a Poisson process, which – in short – determines that at a planned utilisation rate of 99% of your time and an uneven distribution of issues arising, 98.1 issues may have to wait.

Now software development and innovation processes tend to be rather unsteady. Much like motorway traffic or call center queues more commonly described by a Poisson process. There are times when an unexpected number of issues arises. Other days are quiet, things go well and nothing unusual happens.

If you are planning your time at a high average utilisation rate, chances are, many relevant decisions will never be made in a reasonable timeframe. Obviously you can reprioritise – being a manager after all – but then the more mundane daily work will never get done, clogging the system further.

Bottom line: if you want to get some innovation delivered, make sure you plan ideally around 70% of your time. Never more than 85%. At this rate you may even find time for that workshop with us, leapfrogging your 100+ % busy competition even further.