Have you ever bought a new software, and watched - in slow motion - as its promising potential withered on the vine?
Why does this happen so often?
Sometimes, snake oil salesmen take us for a ride. Far more often implementation failure is the culprit.
Buying a software is easy. Implementing it within budget, on time, and to the maximum of its potential is hard.
Why?
The most common is a failure to protect the set up team from the day-to-day of the business.
Software implementation requires a totally different sort of management from normal business operations, and most businesses are not set up to allow for it. Specifically, implementations are best done in long blocks of uninterrupted focused time.
In a 2009 essay called "Maker's Schedule, Manager's Schedule" Paul Graham outlined the problem in stark relief. I highly recommend the entire article, but here are the core passages:
Graham starts by defining the two types of schedules:
The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you're doing every hour.
But there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.
He's spot on. And implementers of new software can be grouped with "programmers and writers". I have seen projects languish for weeks, the implementer giving their 30 minutes here and 20 minutes, only to progress 50 times as far in a single uninterrupted day.
In one team I worked with, we called these glorious uninterrupted days"War Rooms".
Next, Graham pin-points the problem:
When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.
I can attest to this. As I sit here, writing this essay, I have a meeting coming up (its 7 minutes away). My focus is impaired, I need to keep checking whether I've lost track of time. This essay would probably come out better if I had no meeting on the calendar (6 minutes).
Finally, Graham puts the onus on the manager to fix the problem:
Each type of schedule works fine by itself. Problems arise when they meet. Since most powerful people operate on the manager's schedule, they're in a position to make everyone resonate at their frequency if they want to. But the smarter ones restrain themselves, if they know that some of the people working for them need long chunks of time to work in.
Graham is writing for software companies that, by and large, do have just these two types of employees: Managers, and makers (engineers).
Interestingly, the problem is more exaggerated with traditional businesses because there is actually another type of schedule. I'll call it the "Doer's Schedule".
A "Doer" is someone that ... does. They act in the business as a part of the machinery of the day-to-day. Dispatchers, invoicing clerks, customer service, even salespeople are doers. As a manager, you mostly manage doers, and doers are not nearly as disrupted by meetings as makers. Their work is transactional, broken into even smaller production chunks (a 30 second phone call, a 10 minute email, etc) than managers.
A meeting is not disruptive at all to them. So we’re really not used to managing makers.
But make no mistake, your software implementers are makers. Their projects are vastly more successful if done in long stretches of uninterrupted, focused time.
If you want to make your software implementers (or any project-based employees) more effective, set up systems and a culture that protects them from their managers and the doers.
Schedule meetings with them at the end of the day.
Give them an office door, or authorize them to put on headphones at their desk.
Ensure they don't have responsibilities that could interrupt them at any time.
This is easy in theory, but challenging in practice. In small and mid-size businesses, software implementers are also either managers or doers. Think hard about whether they can realistically get 4 or 8 hours at a stretch without interruption. Do some other responsibilities need to be removed to make that possible? Its fine for their role to be split, but they need to be able to flip into "maker" mode and not be interrupted.
To get faster, less costly, more effective software roll-outs, give your software implementers a maker's schedule.