Despite widespread humour about business consultants giving advice, it is a serious endeavour. Bad advice harms companies and livelihoods. I wanted to illustrate the mechanics of advice-giving with an example from internal consulting practice.
A CIO asks for an opinion
A Chief Information Officer (CIO) asked for advice during an IT development freeze. One team had highlighted a risk over a core IT system. My duty was to get knowledge quickly.
Giving the team a really good listening to
My initial activity was to spend time listening hard to the leaders and the team members. People rarely raise a warning flag for no reason. And I believe that most people are good people who do things with the best of intentions. Sitting down with the team to understand the world from their perspective was a first step. Next I needed to contextualise these concerns within the work.
Working in the work with the workers
The best place to learn and understand is by getting close to the work. Avoiding meetings rooms wherever possible (and only use them to consolidate learning). Starting with the demand that came into the team. And then understanding how it flowed through the team to other parts of the business. As this knowledge began to develop, I began to articulate a systems picture. Contextualising the concerns identified by the teams and annotating the issues that I encountered.
A picture of the interrelated IT systems
I also began to trace out a separate picture (below) of the different and interrelated IT systems that supported this complex business. Looking to see what each system did and where it went afterwards. Understanding what predictable issues occurred and why and how they interrelate with this bit of IT. This included the legacy systems requiring maintenance. Checking back with technical and other teams where necessary, or going back into the work to see and learn.
The advice and some photos
Within weeks* I provided the CIO with advice that I could support with detailed evidence. Shortly afterwards some IT architects and programmers asked me to take them through the IT systems picture. They were very interested and took photographs. I took this as a good sign, and confirmation that systems thinking can help provide very different perspectives in problem situations.
*Mostly due to team availability
The nicest thing about all this, was that I made friends, even though the advice didn’t support the team’s conclusions. They knew it had been thorough, accurate and fair.
Commercial sensitivity
I am taking the time to write about and reflect on my practice. I have not identified the organisation. And I have blurred the photo.
Leave a Reply