Business productivity is rising up the boardroom agenda

Reproduced with permission from The Times Enterprise Network. To subscribe click here.

One aspect of the autumn budget the chancellor got right was his focus on improving business productivity through investment in digital skills and technology. With inflationary pressures growing, productivity is an increasingly important board agenda item for most businesses right now.

Although I’ve spent a long time in tech, the truth is that I fell into it by accident when I was asked to run a venture capital-backed medical software business just before the dotcom boom. I had no background in software and it was a baptism of fire. The mistakes I made then continue to be invaluable whenever the topic of software investment arises. Both companies I chair, the grounds maintenance firm Ground Control and the executive search specialist Leathwaite International, are investing heavily in new systems.

So many CEOs end up running businesses, like I did, where technology is integral to success, but not their functional background, so I thought I’d share some of the key lessons about the opaque world of tech and new system rollouts.

In the absence of a coding background, my fall-back position has been to think like a user — about critical day-to-day workflow as well as the analytical reports that improve decision-making. I enjoy management by walking about, understanding the challenges of our frontline teams, particularly in sales and service. It is a great way to pick up what’s working and more importantly, what isn’t.

A regular complaint from the front line is the quality of data, so if you want to get the best out of your current IT system or move to a new one, a key step is to ensure the consistent capturing and cleaning of customer and supplier information. The low productivity that results from poor data is significant and generally not identified early enough by senior management. As a result, data migration challenges are almost always underestimated.

The second major point is translating tech gobbledygook into a language the rest of the business can understand. Imagine running a medical software business where you’ve got doctors and techies talking to you in a foreign language, as I had. It took a while (and a smart colleague) to teach me the benefit of creating a brochure at the outset to explain to all stakeholders what the product would look like and was intended to do, with a themed, timetabled road map for functionality to be added. Sounds obvious, but I’ve lost count of the times I’ve witnessed mismatches in stakeholder expectations.

I was so concerned about the Tower of Babel issue between business operators and their own tech teams that I commissioned a series of published guides for our customers along the lines of “10 questions you need to ask your IT director before you invest in new software”, with case study examples.

Another benefit of creating this clear road map up front is that it helps combat the uncanny knack tech projects have of going over time and budget. Poor user specifications, scope creep, lack of change control processes, rushed user acceptance testing, weak sign-off, inadequate training — all these are common and avoidable. Get clarity right at the start and then stick to it.

A third key lesson was helping our software developers understand the challenges of being a software user. Once, after an unnecessarily painful software release to customers, I asked our tech team to help us support customer calls, as we were inundated. This had a number of very positive outcomes. First, we realised that we needed to bear in mind the needs of our most (not least) technophobic customers. Secondly, our developers heard first hand how users described their experiences. Thirdly, we made a “look back and learn” a key part of our software release review. And finally, we realised that issues identified by customers — rather than internally — were by far the most important.

Fourthly, be mindful of IT architecture. If you were involved in a building project, would you commission the builders without a detailed plan of what you wanted your building to look like? So why would you do it any differently with a software project?

Time spent in product management, addressing needs and pain points, designing user experience and testing will save enormous amounts of time and money in the longer term. That way, whether you build in-house or outsource, as long as you have strong project management, you should be able to avoid the project going badly wrong.

Finally, apply the sniff test — even when you’ve planned thoroughly, do listen to your gut.