Covid-19 is rattling nerves, up-ending lives and sparking a huge expansion of the virtual workplace. For those contemplating or in the midst of sponsoring enterprise IT projects this is going to significantly expand the communication and execution challenges standing in the way of your success.
What is already hard is about to get harder. The traditional, face-to-face methods for setting objectives, managing work and steering a course towards those objectives will no longer be consistently available.
Some in the tech community will dismiss these concerns. They will argue that the virtual workplace is nothing new. They’ve been doing it—at least part-time—for years; they have the drill down cold.
Maybe, but I’d caution against taking undue comfort from that experience. The dynamics of full-time, completely virtual teams are far more complex than part-time, partially virtual teams. In the latter, workers tend to isolate after issues have been discussed and objectives set in person. And when it comes to having the act down cold, well, let’s just say the data doesn’t support that conclusion.
The research is consistent—70% of enterprise IT projects, and 95% of those projects in excess of one million dollars, fail. Two-thirds of those failures happen for one reason. It’s not the tech. It’s not the team. It’s because what the business needs to do is never fully communicated—therefore, it’s never fully understood.
I think this is happening because we’re mistaking what these projects actually represent. We talk about running IT projects, but that’s not what we’re doing. We’re running business projects that happen to be enabled by IT. Technology is only a tool—nothing more. Tech marketeers often sell it as magic; it isn’t.
This misunderstanding has resulted in two problems. Business-people have become complacent—they assume too much and are not telling the technologists everything they need to know. Technologists, on the other hand, aren’t asking the right questions to solicit critical details from the business. Neither party does this consciously, but that doesn’t change the result.
As the executive in charge, whether from the business or IT, this communication deficiency is your single biggest project risk. Given the enormous financial pressures now confronting businesses all over the world, it might well be career limiting not to step up precautions to mitigate this risk. The purpose of this article is to share a simple tactic to help you do that.
—–
By way of introduction, I’m a serial entrepreneur, ex-CIO and technologist. I’ve run virtual teams of 5 to 500 people around the world—doing dev and enterprise implementations—for over 25 years. I became very good at running virtual tech teams and enterprise IT projects. I did not start off that way.
The secret was coming to understand the importance of business stories.
Through trial and error, research and some suggestions from a former mentor (the first Chief Learning Officer in the world who helped Jack Welch usher in the golden age of GE), I was able to develop a simple checklist to capture and communicate what the business was trying to. It worked extremely well.
I’d like to pass it along. But, before I do, I want you to be aware of two things.
First, the checklist may require your team to do a little adaptation and additional planning. It doesn’t have to all be done at once. The process tends to an on-going, group exercise. You probably won’t gather all of the information for the checklist in one pass, but each pass will provide additional value. The time you’ll save executing and fixing mistakes will far exceed any additional time you spend planning. Research by the PMI, IEEE and others has consistently shown a payback of 36 to 100 times.
Second, this approach uses imagery and storytelling to overcome the mental limitations and communication challenges that all humans face. You’ll need to get things down on paper and draw workflows, process maps and storyboards. These can be basic—even crude—but your team will need to understand and buy-in to the stories you create.
We tend to forget that everybody’s minds-eye is different. With the best of intentions, different people will visualize the same thing in different ways. If you remember the old telephone game, you’ll recall how dramatically the story changed by the time it made it to the last person. That same degradation of your “execution story” will occur within your team in the absence of a physical document that specifies your execution goals and strategy.
All that said, here’s the idea.
It’s a twelve step checklist for telling the business story of what you’re trying to do and how you intend to do it. Neuroscientists have found that people learn and remember through stories. They’ve also learned that if you don’t create a shared story, team members will create their own. This checklist not only helps IT and process owners unearth the business’s execution story, it acts as an insurance policy to keep that story intact.
The checklist serves two other functions. It’s a cheat sheet to help your team ask questions about ambiguities. It also helps the team hold each other accountable. If questions are asked, but answers are not forthcoming—and such attempts are documented—it makes it very hard for one party to later blame another.
If you and your team can answer these 12 questions, you will have created a shared, 360 degree definition of exactly:
- What is it that you’re trying to do;
- What’s going to be required to do it; and
- Why accomplishing that goal is important.
Seeing the Old in a New Light:
The checklist reframes an old idea. Business execution is not a one-off, linear exercise. It’s a continuous cycle with four quarters. These form the central plot-line of every business, of every process. Every execution story has these twelve elements and they occur in this order.
Quarter One: DO
The checklist starts with the acknowledgment that business is about DOING something—it’s about moving a ‘ball’ from point A to point B as fast and efficiently as you can to generate profit. In this section you define what you’re trying to do. Think of it as mapping the workflow or horizontal dimension of your process.
Question 1: What are you trying to do?
What are the ‘balls’ that you’re moving from point A to B? What’s the timeframe? Who’s the customer? Why are you trying to do it?
Responses like ‘we want to install a new ERP system’ don’t answer this question. That’s a statement of how you’re trying to achieve a goal. What you’re trying to do is achieve some kind of increased efficiency or competitive advantage. Explaining what those goals are and why they’re important is what you’re after. When your team understands what needs to be done and why it needs to happen, they’ll be best equipped to creatively discover how to make that happen.
Question 2: What are the interim steps in the process that you need to accomplish to realize your goal?
Where do those steps start and stop? Who sits at each end of each segment? What changes at each step?
Question 3: How will you know that you’ve successfully completed each step and met your ultimate goal?
What are your criteria for acceptance? What happens if those criteria are and are not met? What’s the reward for success and cost of failure? Be specific.
Quarter Two: MANAGE
Every time work is performed it’s managed. Mapping who’s going to do the work, where that work is going to take place, and how you’ll organize or supervise it defines the vertical dimension of your process.
Question 4: Who’s going to do the work?
“Who” touches, performs or manages the process? In the context of this question “Who” can be an organizational position—a line worker, manager, director, etc. Who could also represent a customer or external partner.
Question 5: Where’s the work going to be performed?
“Where” can represent a physical location—a factory, work-station or department—or organizational unit—a sales territory or team. The Who and Where of Questions 4 and 5, usually represent the boxes on a process map or org chart.
Question 6: How’s the work going to be organized?
“How” represents the lines on a map or org chart that run between the boxes. Those lines are the relationships in your process. They can also be points where you measure performance.
Quarter Three: ASSESS
Although there are countless variations on these themes, there are only three basic questions that can be asked about process performance: how much, how fast, and how efficiently do you move the ball from A to B? These metrics are used to evaluate the health of your horizontal workflow and the efficacy of your managerial or vertical process.
Question 7: How much work is transiting the process?
Metrics concerning how much volume is transiting a process—over some period of time—are the most common performance measurements. Organizations typically focus on five to seven of these for a given process—and they’re usually well known.
Question 8: How fast is that work transiting the process?
Tracking things like build times and sales velocity gives you a sense of the time required to physically transit your process.
Question 9: How efficiently is the work transiting the process?
This question covers a lot of territory. There tends to be seven categories:
- Variance (e.g., Plan vs Actual)
- Efficiency (e.g., Costs per Unit)
- Quality (e.g., Rework Rates)
- Customer Satisfaction (e.g., Churn)
- Organizational Alignment (e.g., Backlog Trends)
- Reliability (e.g., On-Time Rates)
- Compliance (e.g., Compliance Violations)
Quarter Four: REFINE
Time is your most precious resource. Allocating that resource to advance the performance of your business is your most critical job. This fourth and final section of the checklist provides a framework for assessing those allocations. The following three questions are the only ones you’ll ever need to “triage” your organization to determine where to target your interventions and get the greatest bang for your buck. The chart below (or something similar)—which identifies the performance of every participant in your process—is what you should end up with every time you ask these questions about a metric.
Question 10: What’s Ok? What’s not Ok?
For each metric identified in the Third Quarter, you need to decide where you’re going to draw the line between adequate and inadequate performance. There are many ways to do this: contractual obligations; budget goals, best practices, etc.
Question 11: Who or what’s involved?
Who or what falls into each bucket just defined? An answer to this question defines the calculation used to sort all the process participants into either the Ok or Not Ok categories.
Question 12: How much does it costs?
Using the formulas defined above, you’ll run the numbers for each process participant to calculate their impact. These are usually some form of cost accounting or variance calculation.
Repeat:
What you take away from the answers to these last three questions will guide how you refine your efforts so you can continuously improve performance going forward.
Conclusion:
This isn’t hard. It’s storytelling by numbers. It may seem like added work, but one way or the other, before you complete your project, you WILL answer all of these questions. It’s just cheaper and easier to do it up front than to wait for things to break down when you’ll have to stop, backtrack and repair what went wrong.
Regrettably, there’s much more to say than can be covered in one article. If anyone wants to learn more, feel free to contact me directly at dave@itsaboutwhat.com.
