Everyone has heard the sage advice "start off slowly" and "take small steps." However, in business, our sense of urgency often gets in the way of our understanding of this extremely practical advice. A very embarrassing experience early in my career focused my attention on this point, and a more recent experience reminded me of it.
I had just left my first serious job and moved on to a support role on a reasonably large network deployment. I answered phone calls at all hours of the night, hit three cities a day rebuilding servers, and generally carried on like a good little boy. By the end of the first four months, the client came to trust my motivation and enthusiasm as well as my rather odd approach to technical problems.
Eventually, the client (over my project manager's protests) entrusted me with laying out the support/incident resolution weekly and monthly reports. They wanted me to come up with a way to accurately track not only the work, but also the technical trends so that we could get ahead of the issues. I set to work. This was my chance to demonstrate that my experience as a small-time project manager, support engineer, and general busybody qualified me for the big time.
Two weeks later, I had a 60-page task list (I deluded myself that it was a process and critical path document) along with a bloated Access database for tracking everything. After I presented it to the client, they put me in charge of managing the thing.
Two weeks after that, I walked into the project architect's office. I unloaded on him for almost an hour. No one wanted to follow the nice escalation procedures I outlined. The data I gathered didn't seem to do any good. With me out of the field, we were now falling behind on our project support. Why didn't anyone want to work with me on this?
The man who would become my mentor gave me a level look. Then he asked the first of a long and agonizing string of questions: "What do you want this procedure to do?"
Dissecting the process
His seemingly obvious question forced me to reconsider my goals and motivations. As I sat there mumbling about organizing work and keeping lines of communication open, he kept looking at me. After I ran down, he asked the same question again. And again.And again. Until he finally drove through my thick skull what he wanted out of me.
That afternoon, we tore apart the "process" I had designed into tasks pointed toward specific operational or strategic goals. In doing so, I discovered that in my 60-page document I was trying to address 10 issues: seven strategic and three operational. We then ranked those goals by priority, from both our company's and our client's perspective. Where there was a conflict (for example, we rated hours allocation among subcontractors far higher than the client would have), we discussed what caused that conflict and how it should be resolved in client or company procedures.
After our discussion and analysis, he sat back to consider the mass of needs sitting before us. "So," he asked, "how do we implement all of this at once?" I shrugged at the complex diagram of stakeholders and actors. "No clue?" He chuckled. "Sleep on it."
Small, planned steps
The next day, we sat down in front of the diagram again. I stared at the goal priorities for a long time. "We implement the processes that link to the client's top goal and our top goal. Everything else is junk."
From the expression on his face, I could tell it was going to be a long day. It turned out I was right; he kept me there until well after midnight. But, in that time, I learned one of the most valuable lessons of consulting anyone would ever teach me.
He agreed that the starting point lay in the two top priorities. However, he disagreed that "everything else is junk." In fact, he pointed out to me that everything else was on that board for a reason; my initial analysis was not flawed. Both my company and the client needed the data and wanted to meet those goals.
My mistake lay in trying to do too much, too fast. Although people might intuitively recognize that the changes I wanted would improve their lives in the long run, the short-term work far exceeded this nebulous long-term benefit.
What we laid out over the course of the day was a plan for implementing the tasks and data gathering that affected the top two priorities. We would then feed that data to the decision makers and show the people doing the work how it positively affected their jobs. After that, we would add the remaining priorities. At the end of the meeting, he suggested that we meet again in two months to assess our progress and reassess our priorities; if something had changed, we could easily adjust.
The difference between how people reacted to my process before and after the meeting made a believer out of me. Where they were sullen and uncooperative, they began to go out of their way to help me. As more directly helpful data became available, things got even easier. When the situation changed, as it always does, we just readjusted the priorities according to current needs and moved on with our lives.
Almost nine years later, a former client asked me for a bit of assistance with a new project. It seemed that they were floundering their way through an outsourcing effort. They wanted me to come in, look around, and see if I could help them get better focused.
As I sifted through the mass of task lists and almost-procedures, I experienced a moment of deja vu. I faced my own work from so long ago, but this time I was on the other side of the desk.
That client is still working on refocusing and implementing effective procedures. But by showing them how to take small steps and reassess priorities, I've helped them begin making progress again after being stalled for almost a year.