Melissa Swartz | No Jitter | July 10, 2017
The point of technology is to improve the business.
Last Friday afternoon, almost everyone who could had taken off to get a start on the holiday weekend. That was my plan, too… but then I got a call from a client with a problem.
One of the vendors for a critical cloud application was making a change in the protocol that my client used to connect to them, and at 10 p.m. Friday night my client’s connection would no longer work. This application was a 24×7 customer-facing service, and if it was down it would create customer service and billing issues that would take a while to unravel.
My client’s staff was aware of this, and I had helped them test the new protocol, but there was no one in charge of getting the deployment done. Progress had stalled. So I dug in, found some resources to do the work, and by 7 p.m. the new protocol had been deployed.
While this was a happy ending, it’s also a symptom of a problem that we see in IT departments at many of our clients. The need for this change came on very short notice; it needed to be made in two to three days rather than the two to three weeks it should have normally taken. Since it was a business-critical service affected, it had to happen fast. But where was the IT staffer who was invested in the success of the business? Why did it take someone outside the company to get this done?
We see this a lot.
In all fairness, the blame doesn’t lie only with IT. The business side also contributes. There is a language and a cultural barrier between IT and business users. How many of us have heard from a user that something isn’t working, only to find that the problem was reported incorrectly or (worse yet) caused by the user? And how many business users have been asked to provide their requirements to IT for some type of technology, without any understanding of its capabilities?
We find that in many organizations, it is difficult to find people who not only understand technology but also can work with the business to uncover requirements that can be translated into technology. And that’s the point — technology must improve the business. To do that, you have to understand what the business needs.
These needs are never expressed in technical terms. The business says, “We need to be able to do this faster,” or, “We are spending too much on that.” And then it’s up to IT to figure out when technology is the fix, and when it’s not. The solution could be an improved process rather than new technology.
There’s an old saying: “When all you have is a hammer, everything looks like a nail.” It means that people tend to solve problems with whatever tool they are familiar with, rather than looking around for a better tool. This happens in business too. Technology people try to solve business problems using technology as the solution. Process people want to fix the process. Others think that changing the people involved will resolve the issue.
Many of our clients hold their IT staff members accountable to the business by measuring service levels. Was an issue resolved within the specified timeframe? Was the status communicated in a timely fashion? While these things should occur, they often are not a true measure of how well IT is meeting the needs of the business. It’s time to broaden the tool kit beyond the hammer.
As the speed of technological change and market disruption continue to increase, it is important for IT to measure outcomes in business terms rather than SLAs.
An RFP that is issued at the proper time in the process, is supported by a thorough needs analysis, and clearly articulates the requirements of the organization, is an effective tool.
Those responsible for their organization's communication technology must recognize that changes are coming and navigate to safer alternatives.
Writing an RFP (Request for Proposal) is like a painting project. The final product is much better if you do the necessary prep work up front.
How do you make sure that your RFP gets the responses you need? How you phrase your RFP requirements can make all the difference.