Because we work in an increasingly competitive IT environment, we must pay careful attention to how we spend our time. Although we all want to work exclusively on high value-added activities, reality and clients often dictate that we expend huge amounts of effort on time-critical but often pointless work. Even though most of us know the difference between priority and urgency, actually applying it in a business situation can be difficult. Early in my career, one of my clients showed me a way to apply the concept to real business situations that I still use to this day.
I was working as a team leader on a help desk migration project. My company provided interim support, along with process consulting and a certain amount of staff augmentation. The client's long-term goals included the deployment of a more effective ERP solution, a redesign of his operations strategy, and the establishment of a five-year partnership with one of four competing companies.
Realizing that a fair amount (about $40 million) of work rested in that partnership opportunity, our managers let the team know that we were not to make any mistakes. My direct manager asked me to do anything I could for my counterpart and the client IT director. It was implied, but not stated, that if they needed their cars washed, it would not be too much trouble for me.
With that in mind, I threw myself into the work. As the senior consultant on-site, a thousand details came across my desk every day. I worked with my team to address issues as they arose, believing that my focus on a help desk implementation needed to be on immediate response. The client team worked in the trenches with us. Over the next two months, we learned their systems and they learned that they could count on us to bend over backwards to address whatever they wanted.
However, things got worse. The more work we did, the less we seemed to accomplish. Projects began to slide. Within four months of starting the engagement, a sinking feeling lodged itself in the pit of my stomach. No matter how hard we all worked, or with what intentions, this engagement seemed doomed to failure.
One day, the IT director pulled my project manager and me into a conference room. He closed the door and said, "Look, I'm sorry about this. I've let you drift down into the muck. It's time I got you refocused on the priorities of this engagement, not the immediacy."
Simple concept, complex execution
As the next six hours of our discussion revealed, separating priority from immediacy (to use my client's term) in business is more complex than it might appear. He was a master at understanding the varying levels of the analysis, and what he shared with me was an eye-opening experience.
First, he aligned all of our tasks into two "sources of business priority." The first was business strategy as defined for the various business units. The second came from the other direction; it was the actual business needs (rather than business requests, which were immediacy) of the profit-generating business units. He argued that although a business unit might not understand its business needs, an analysis of its common immediate requests might reveal these needs to an observer.
Then he went on to lay out the personal priorities of the political actors, as he understood them. In those cases where an individual had control over a budget he needed access to, the individual's priorities became important. Actors who influenced budgets but did not control them (in other words, stakeholders) became secondary or even tertiary considerations.
The personal priorities of his teams (consultant and employee) became his third level of analysis. He argued that, from a time management and leadership standpoint, people were more likely to do tasks that aligned with their personal priorities. However, the priority of the team did not devolve from those priorities. Rather, it came from the first two levels of the analysis.
So far, so good. It was at this point, though, that my intentions and his diverged. He said, "I use consultants for priority work and let my people deal with the immediacy that comes from people who don't understand priorities."
The consultant's role
The idea that, as consultants, we should focus on priority work possesses a certain professional appeal. I strongly dislike working on urgent but fundamentally useless tasks. Most people do. As a professional, I would much rather let my client counterparts fight the battles with urgent activity while I sail forward making important changes.
But, on a very real level, consultants often lack the social and cultural awareness within a specific organization to truly work on priority activities. Furthermore, from a professional development standpoint, the client employees often need the experience gained from working on high-priority but low-urgency projects. These projects often involve new technologies, techniques, and opportunities for career growth that help to build employee loyalty.
It would seem the real solution lies somewhere between the absolutes. Rather than just sloughing off work, the managers (project and team) must take a long, hard look at the priority matrix surrounding each activity. Sometimes that matrix will dictate that an employee needs to take the action. Other times—especially when a sacrifice play becomes necessary or skills not possessed by the team are needed—consultants look like the most viable option.
Complexity in action
Despite my theoretical disagreements with my client, my project manager and I took his refocusing to heart. We pulled our team out of the immediate activities. This allowed them to focus on the high-value projects the IT director wanted us to work on. This in turn raised our visibility within the organization, eventually leading to us landing the partnership arrangement. In the long term, that partnership arrangement resulted in a help-desk and operations outsourcing contract. That contract pulled the client IT team out of highly urgent work, allowing them to focus on priority activity and analysis.