Along with the myriad issues incessantly crying out to be addressed from an infrastructural and informational perspective, the company I worked for was growing at a frenetic pace and acquiring other companies at a ferocious rate. These companies were spread across a range of different business sectors so my “customer” population (the internal users within the businesses who used technology to run the many parts of the conglomerate) was varied and had very diverse needs.
No two days were the same, no script existed on what to do next. Brilliant!
One of the challenges to get on top of quickly was to ensure the IT and IS environments were “controlled” in the sense there were not boundless numbers of disparate software packages and hardware devices scattered throughout the business environment. Because, as I kept telling the team, whatever we built we also had to maintain and support. The more software packages and hardware configurations in our environment, the more expensive, time consuming and risky this was to manage with our minimal resources. But making sure we had practical levels of software and hardware in place to support the business was a task much easier said than done. (Nowadays, with the move to BYOD environments, this is even more of a challenge.)
In an attempt to provide guidance to the helpdesk and IT department, I mentored the IT team to move away from their existing model based on customer “want” to one based on customer “need”.
The more people who use this question in their dealings, the better and more effective meetings and IT execution in general will become.
That is, with the key purpose of IT within an organisation being to enable the business strategy and help the organisation become the business it needs to become, we would see our role as understanding and delivering what the customer “needed” to do their job, not just what they “wanted”.
My initial thoughts were this mindset shift would move us from being a business where there was a constant demand from users for more different IT software and hardware systems (want) to one more constrained and balanced (need).
How wrong I was!
Nothing changed. In fact, things became even worse as everyone “needed” to do something, or something different to everyone else.
This surprised me and for a while had me stumped. I was way off course. So I went back to my metaphorical drawing board to muse on a better approach. Then, after much pondering and thinking through why things were happening the way they were and trying to get inside my internal customers heads, it suddenly struck me – these people were all trying to do certain things for a reason, right?
That was my Eureka moment! I suddenly hit upon the ultimate question to ask when someone came to ask for that new piece of software or hardware. Seven simple, magical words which brought clarity and depth at the same time: “What problem are you trying to solve?”
This unassuming sentence creates a laser-like focus as to exactly what a person is trying to achieve as an end game, rather than what they want or need. There is a vast difference between these two scenarios.
Once we understood the problem a person was trying to solve, well, we then just needed to provide them solutions. And, if we pre-empted the sort of generic problems our customers would most likely need to solve, then it became even easier.
We were problem solvers.
For example, if the problem someone was trying to solve was remote access to their email then we had already solved that problem. We had three different ways to achieve this. Another example would be a customer requesting a special database to be developed for a specific purpose. Instead, asking them what problem they were trying to solve would result in identifying the information either existing already elsewhere in the organisation, or extending an existing in-house application to accommodate their informational needs.
Going down the old “what do you need” path would have meant creating numerous new and unnecessary methods and implementations resulting in an unnecessarily complex infrastructure and general lack of cohesion across the business.
The powerful question
As a sidebar, the powerful question “what problem are you trying to solve” also exhibits extreme “super powers” when used in those fiery and passionate meetings where everyone has an opinion or beef to discuss at the table; and the conversation gets louder and louder, and more and more confused and misdirected with no resolution in sight. Pitching the “what problem are you trying to solve?” question to the audience at the right time has, in my experience on several occasions, brought the room to a quiet standstill while people mulled the poignancy of the question over. It makes you appear almost sage-like.
When people subsequently start tumbling out what they felt was the problem to be solved, I’ve found both amazement and sometimes rampant disagreement around the table. People had different ideas as to what problem they were even discussing.
It’s not hard to fathom why they couldn’t reach a consensus when people were talking and arguing about totally different problems!
Some years back, as CIO for a very large conglomerate with an extremely aggressive growth agenda, word came to me one day from above the business was going to open an office in another state within the next two weeks (because that’s the way we do things around here, I was told)! It was a fait accompli. The discussions about the proposed office had been ongoing for some months, I found out, but no one had thought to involve IT in those discussions. The judges’ decision was final and no correspondence was to be entered into. IT’s role was to comply and make it happen.
I was presented with a dictum from the CEO and responsible for enabling the brand new office within a fortnight.
But I was now stuck between two immoveable objects – an unachievable goal (who could fit out a completely empty and unconnected office from scratch in just two weeks?) and a CEO whose bedside manner would make Kerry Packer on a bad day seem like a pussy cat on Mogadon (those who remember the 1991 House of Representatives Select Committee enquiry on the print media will appreciate this analogy).
So, I sat down and calmly built out a simple yet telling Gantt chart which contained the key tasks needing completion to ensure the new office could function (ISP connectivity to the office, printer configuration, Citrix connectivity, procurement and transportation of computers, phones, PABX and onramp establishment, and extension of the WAN).
The ISP connectivity alone at that time was six weeks minimum with other tasks dependent upon that being completed first. At a push, we could complete everything within eight weeks, certainly not two.
Armed with this picture, I went upstairs, sat down and explained to the CEO it would be approximately eight weeks before a new office could be readied. As expected, this information was not greeted with enthusiasm (I’m being courteous). With a few choice expletives thrown around the discussion began to veer into the well-worn path of a not-so-polite and denigrating appraisal of IT delivery in general and how it seems our only goal was to impede the business.
I sat calmly and listened, saying nothing (recalling the Chinese proverb “in a contest between the river and a rock, the river will always win). Then when everything went quiet, to focus the conversation back to the point at hand I asked, “What problem are you trying to solve?” The emphatic answer was to open a new office interstate within two weeks – “which part of that didn’t I understand?”
I then placed the Gantt chart assuredly on the desk in front of the CEO and said I was extremely happy to comply with that directive, I just needed to know which tasks I could remove from the plan in order to reduce the eight week critical path timeline back to two weeks.
The CEO looked at the plan, looked at me, back at the plan then, after a pause of some 15 seconds, concurred nothing could be removed from the plan and grudgingly agreed it would take eight weeks to do it properly and they would plan around this accordingly.
With revised instructions to “let’s do it properly” I left the room feeling quite pleased to have resolved such a contentious issue quickly and without any blood spilt on the floor.
I’ve since found this simple question to be one of the sharpest and most often-used weapons in my CIO armoury.
The best thing is, the more people who use this question in their dealings, the better and more effective meetings and IT execution in general will become.
Geoff Lazberger is a former CIO for three separate corporations across investment banking, property development and hospitality. Email comments and feedback to firstname.lastname@example.org.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.