If the current breed of Service Management /Help Desk products such as IBM’s Maximo or VMware’s Infra are relics of the Analytical mindset, what would the tools of a Synergistic or Chaordic mindset look like?
I’ve observed many disturbing behaviours driven by the current breed of tools commonplace amongst the organizations locked in an Analytical mindset:
- All of these tools are based on a push mechanism so bottlenecks are prevalent, an expected norm, and not even understood as a problem
- Through the use of ‘specialist’ service groups they create complex workflow processes and thus actually reduce overall flow (customer lead time increases!)
- Service staff are abstracted away from the customer through 1st/2nd/3rd line support hierarchies and thus rarely able to priorities or even start to comprehend the business value of the tickets raised (until he who shouts the loudest intervenes)
- Ticket resolution targets are common, often disguised as SLA’s. In order to hit the targets some staff may prefer to work on low-value / easy work instead of work with a higher business value. They always find ways to ‘cheat’ the target.
- Armies of people are employed to operate these applications and don’t actually service any of the tickets and thus add no value. Often charged with process improvement by implementing more complex workflows and generating reports against flawed SLA’s. And so, the cycle goes on…
Not only do these tools drive the wrong behaviours but also they bake them in as fixed processes without any ability to easily adapt. Numbing the excellence that is human interaction and thinking.
Tools of the Synergistic and Chaordic mindset
I’m not against tools. I accept that tools can be useful in lots of situations and equally applicable in the Synergistic or even Chaordic mindset. If the current tools (designed to control the analytical mindset) are so flawed, what will the new breed of tools look like? Are we starting to see some of these future tools emerge with the likes of Rypple.com? So, here are my requirements for a new breed of ITSM software:
- New tickets raised are placed in the organisation backlog (not allocated to anyone).
- There is only one backlog (or queue).
- Tickets in the backlog are automatically deleted (hard delete not soft) after 2 weeks (orgs to the extreme right of the Marshall model will be less than this, possibly deleted daily).
- Tickets in the organisational backlog are ordered by priority, highest priority at the top of the pile.
- Only the top ticket in the pile can be taken.
- Anyone accessing the application can change the priority of any tickets in the backlog.
- Each staff member in the service organisation can only work on one ticket at a time.
- More than one member of staff may work on a single ticket.
- Anyone in the organisation can take a ticket off the top of the pile.
- A staff member cannot start another ticket until the one they’re working on is complete.
- If a staff member has to stop working on a ticket for any reason to pick up another one then the dropped ticket is deleted (hard delete not soft) and the amount of time expelled is added to the waste stats.
- The application does not support any concept of service groups or teams.
- The application does not require a login nor does it have any concept of users, permissions, or roles.
- The application cannot send automated emails to inform users of changes to tickets.
- Tickets only support 3 states – Backlog, Work In Progress (WIP), and Done.
- Only tickets with a state of Done are persisted long term.
- Each ticket has date/time stamps: date created, date WIP starts, and date when the ticket is Done.
- There is only one free text entry field for a description (limited to 140 chars – not related to twitter!)
- Stats are displayed in the application dashboard. The stats displayed are current throughput, current lead time, current cycle time, and current waste.
- All tickets in the application are searchable via free text search.
I suspect the requirements above will seem unfathomable to the analytical mindset. Think carefully about the consequences of these requirements and the behaviours they will drive.
Mobile phones and children
My 6-year-old daughter asked me to buy her a mobile phone recently. She justified it from a safety perspective so if she needed help she could simply call me and I’d come to her rescue. When I was a child, if I got lost or stuck in a difficult situation I had to figure it out for myself and think on my feet. I couldn’t simply call my parents. I never came to harm, I always found my way home. Again, think carefully about the consequences of this.