We used to have an engineer at our office who would always turn in work requests claiming his job was the top priority. He would even evoke the name of the boss to give credence to his sense of urgency. However, I would never succumb to anyone’s priority claim (especially his, because he did it all the time), instead I would look at the project as part of the whole. A personal plea (or demand) to receive top-priority status would never trump project deadlines or the real importance of other work requests.

In one person’s mind, his project might indeed be the most important; but its real priority can only be determined by looking at the bigger picture. With limited resources and limited man power, coupled with an overwhelming (or even steady) flow of requests, we have to develop a system of prioritizing those requests. The system could be either formal or informal, written and posted for all to see or simply more of a thought process. It all depends on the size and dynamics of the company and the types of requests.

In a reply to a recent blog piece, a TR member wondered how I would answer an interview question if asked how I would resolve an apparent conflict with two seemingly urgent requests. The first thing I’d say in such a case is that it actually presents a false dilemma; I simply cannot accept that premise — one request has to have higher priority than the other. I would then take a step back and consider the premise of each request. I would assign each request a priority defined by any number of factors. Those factors, of course, would depend on the type of business and the particular projects. What follows is a general breakdown of my thought process when assigning priorities to any IT work request.

Critical: Production for the company has come to a halt. Production for the individual has come to a halt, and there is no other computer option at his/her disposal.
High Priority: Production or productivity is severely hindered. This includes the prospect of missing a looming deadline because of a technology issue.
Medium Priority: Production or productivity is hampered, but work on a project can continue, and a deadline is not in danger of being missed.
Low Priority: This might be better described as an annoyance. It does not affect production or productivity, nor would there be any adverse outcome, as it relates to our project or business, if the issue went unresolved.
Response: Will be addressed in order of priority. If I’m out of the office, a cell phone call is certainly appropriate for a critical issue, and even for some high priority issues. Otherwise, it can wait for normal business hours.

If there’s still an apparently irreconcilable difference between two choices — if one or the other, for example, will indeed miss a deadline — then other considerations need to be factored in. Which client would be easier to work with if their deadline was missed? Would we be at risk of losing one of our clients? If so, which one? Does our company stand to lose revenue because of a missed deadline? If so, which one? If both, which would lose less? Are there farther-reaching considerations other than just our immediate client and personal revenue? (The governor is scheduled to attend this ground-breaking ceremony with full press coverage, and we still don’t have the technology links established!)

Sometimes, the lesser-of-two-evils principle would help in establishing a priority. Both choices are bad, but one isn’t nearly as bad as the other. However, even in cases such as these, we can’t let ourselves get trapped into a false dichotomy. Are these really the only two options — miss one deadline or the other? Perhaps there are people in another department who could be temporarily assigned to help out? Do we know an independent contractor who could be called at a moment’s notice to come in and take one of the projects? Perhaps we even have a relationship with one of our competitors who could either subcontract their people to us or take on the project for a share of the fee. (I actually know of a couple of architectural firms that used to do this very thing.)

There’s always another option. There’s always a way to resolve an apparently unresolvable conflict. And there’s always a way to clearly establish that coveted top-priority position.

By the way, in the case of the engineer I mentioned at the beginning of my piece, it brings something to mind (it’s one of those sayings you might see hanging in someone’s office): The lack of planning on your part does not constitute a crisis on my part. His lack of planning might have created a crisis for him, but it didn’t automatically make it a top priority for me. (Note: I said he used to be with our company!)