Stories from the consulting desk
A snapshot into why IT professionals often get it wrong. And maybe some ideas on how to fix it… or fix IT. 😉
Why ask why?
I sat across from the company controller. She had asked me to come in and speak with her.
About a week before this, I had sent her an email asking the following questions:
Do you spend a lot of money on technology but often fail to recognize true business benefits?
Do you still find that your organization performs many tedious and manual tasks resulting in duplicate data input and errors? Did you believe technology would help you reduce these?
Do you understand why your IT team or vendors have recommended the technology you’ve purchased? Do you wonder what it does for you?
And so it goes?
Her response was something like, “We have it all here and have no idea what it is doing for us. Can you come speak with me soon?”
Candid response… and pretty common.
Which brings us back to our meeting.
She explained that the company was growing – rapidly. They’re systems seemed slow. Also, as I had asked, she felt too much duplicate data entry and manual processes were required to get them the information they needed or perform their jobs.
She knew this was true throughout the organization but she was painfully aware of this in her accounting and finance group.
She explained that she had received three quotes for system-wide upgrades. Exasperated she said, “Three proposals. One is $120,000. One is $150,000. And one is nearly $200,000. How do I know which one is correct?”
She handed me the quotes.
I set them to the side and asked her to tell me more about the company, her current systems, and the growth they were experiencing.
We discussed their current software (ERP system). She told me about the other software they use, the challenges that their satellite offices faced, the frustration they felt when exchanging data throughout the company. Some of the workarounds in place. We also discussed future plans. What the founder’s vision for the company was. Wide-ranging topics that were mostly about their business and some of their processes.
After 45 minutes she looked at me and said, “You know.. none of the companies who gave those proposals had this discussion with me.”
Oh IT people… why? Why do you not ask why?
Shopping lists are ingredients, not recipes
I said to her, “Well.. what you have here are three shopping lists. I am going to assume each of this list are full of really great ingredients. And, should you purchase the items on these lists, you’ll likely be able to cook up something that taste okay.”
“But,” I continued, “you don’t have a recipe. That is the real problem. Unfortunately, when these companies came and visited you, they looked at your current systems – servers, switches, PC’s, routers, printers, etc. They heard you say you wanted to upgrade. So, they mostly built a list of the same ingredients as before – but newer versions.”
“I can’t tell you which of these proposals is right? And I cannot tell you whether you will be spending, $120,000, $200,000, or $500,000. Or significantly less than that. We won’t know that until we craft a recipe. We need to have an idea of what we are cooking before we start buying ingredients… even good ingredients.”
And therein lies the rub.
Back in 2001, I wrote an article, Why Technologists Must Learn to Speak Business. It was my first paid article. It ended up being published in three magazines around the country (same publisher) and led to a career advice column. It would also form the backbone and impetus for my book, The IT Career Builder’s Toolkit and the subsequent, Building Your IT Career.
In that first article, I bemoaned the fact that IT professionals seem intent on touting technology over understanding the business. And, incorrectly, IT professionals bemoan that they are not understood; that the users they serve and organization management does not take the time to understand technology.
But that isn’t their job. Their job is their job. And, if you want to be a value-added technologist, this fact should excite you. It means, if you take the time and interest to understand their business, you can help them see the value of IT because you will understand IT’s role in the organization.
The proposals above represented one of the main problems I see with IT in general and specifically with IT project development – the Myth of Limitations.
The Myth of Limitations
The above IT organizations came into this business and heard, “We want to upgrade to faster systems.” And so, they built a quote for “faster systems.”
They assumed the business understood what technologies were available. But the business – the founder/owner, the controller, etc. – they don’t know what is possible in the technical realm. So, they are limited in what they can ask for. They have a Myth of Limitations – ie: if X is all that we know, we ask for X.
The “good” IT professional will look past the request and find out a little bit more. They will discover what the company does, what they’d like to do – from a business (NOT TECHNICAL) perspective. Predetermining the technology limits what you can recognize in the business.
Concept Over Process
I started touting Concept Over Process when I was with Blue Cross of California. It places business understanding, business process, and the work the user’s do as preeminent to the technology implemented.
It requires that IT immerse themselves in the departments they serve. It requires taking a legitimate interest in the value technology can bring. FYI: Faster computers, a faster network – that is NOT where value is created. Those are the vehicles for delivering value.
Don’t confuse this point. Infrastructure is necessary – but not necessarily valuable. If that is where you try to find value for the business, you will always be viewed as a necessary expense. Being an expenses, even a necessary one, puts you at risk.
Value is streamlined user functions, the ease of access to data – and tools that helps data lead to decisions. As I like to tell clients, “information should inform.”
Concept Over Process = Recipe before Shopping
Beware a list of ingredients – even really great ingredients – before you have a recipe.
One is a recipe for success, one is a recipe for failure and frustration.
I’ve been hired by a few organizations to help their IT group recognize this. Shift their perspective, their language, their passion, from technology to the business. And in doing so, their technology improves.
Concept Over Process is both a mindset and methodology. It is also a chapter from my book. You may download it here..