Printers

Don't let gray areas delay your projects

We've all been there--we're set to start a project when a gray area brings everything to a pause. Jay Rollins talks about how it's best to face the gray areas head on.

When I started writing this blog, the goal was to provide real tools for IT leaders based upon my  experiences, the mistakes I made, and the lessons I learned in order for you to make decisions faster and with more confidence. One of these lessons, in hindsight, is pushing past the decision making paralysis that can ensue when you're ramping up a big project.

I've had a few instances where we have had a big project coming up and anything related to that project was placed on an implicit hold status. No decision is made or there is excessive decision foot-dragging. When I look back, I determined that the root cause was figuring out how to deal with the gray areas.

Here is an example. At one company, we did an analysis of the help desk tickets and found that printing was one of the top three issues that the IT staff had to deal with. Toner, non-standard, old printers, paper jams, you name it, it happened. Early on, we decided to standardize on one type of general purpose laser printer so we could stock parts. We eliminated shared computers and stopped the proliferation of inkJet printers in every office.

As we got the money to replace these printers, we started finding areas where one size does not necessarily fit all. We began having a difficult time getting printers out of individual offices. Phrases like "You can pry my inkJet out of my cold dead fingers" were uttered jokingly, but the point of the joke was that they preferred we skip right over them. Basically, there was a printer almost every five feet in the offices.

Also, there were some concerns about security in regard to the use of central printers. Users would claim that they had to print sensitive information that could not be viewed by someone standing near a printer.

We ended up leasing document stations with fax and scan capabilities--I won't go into detail--but the part that is pertinent to this post is what happened during the project approval and project implementation.

We built the business case and it was pretty appealing from a cost savings side. At about the same time the business case was complete, a printer used by a senior executive crapped out. I tried to set the expectation that a brand new uber-printer was going to be installed as soon as the project was approved. One thing lead to another and the approval was delayed two days and implementation was set to begin a week or so later. Meanwhile, this customer was suffering with a bad printer. In hindsight, and what I use as foresight today, I would satisfy the issue right away. You never know what kind of minor delay you will need to work through and all to save the company $500.

My new black-and-white definition is that if it's under $1,000 to solve an immediate need, do it unless the equipment and the resources to install the new project equipment are on the premises and ready to start implementation that day. You can always eBay the equipment later.

6 comments
tonycopp
tonycopp

Just do it. A senior executive in the lurch? Sell him on a trade with the weakest link who had an acceptable printer in this case but whatever..enlist the potential donor with the offer they can't refuse..reward the donor with conferred or direct approval..failing that.. give them mine and I'll make do...just make it happen, captain!

addicted2speed
addicted2speed

Personally I think throwing $1,000 at a problem might not be the appropriate solution. Typically the desk-side technician doesn't have that level of approval authority anyway. I would probably set the threshold at $100. Anything higher than that should probably pass through the inbox of the Support Team Lead or Tech Support Manager (whoever manages the hands-on guys). Also, to resell the equipment later, you would recover some of the initial cost, but then there are additional costs such as people time, depreciation, and support-time (if the equipment is significantly different). In the end, I would estimate the entire cycle would probably cost closer to $2000 by the time you unload the temporary replacement printer and get the new ones deployed. However, the idea of getting the resolution first without waiting for another project to move forward is a great contribution to the "Marketing" that must be done on behalf of IT groups. Getting the user up and running should always be the highest priority. As basic as that sounds, this is often lost in the world of Department Management and Project Management. Inserting a temporary band-aid solution must be presented as just-that: a temporary solution, pending the larger project... and (perhaps) the solution should have a stated end-date. "Here's a temporary printer, but we'll need it back in 5 days because it is scheduled to be deployed somewhere else". Whether this is true or not is of no consequence to the end user. But if you just tell them I need this back in 5 days, they'll often wonder why. To that end, I would not have replaced the faulty printer in your example... I would have suggested that in the interim your user print to another printer. If they are printing sensitive documents, there must be trusted colleagues who have working printers sitting nearby. This would have been a free and temporary solution, and I don't think it would have delayed the pending project approval.

Forum Surfer
Forum Surfer

I once saw a project go horribly wrong. It was conceived and implemented without IT approval or recommendations. Not that I'm on a power trip or anything, but IT should sometimes, if not always be included for major projects that will remotely involve stuff plugging in walls. In this case, it was a major department renovation. At the end of it and 2 days before it was finished they came to us because they needed 8 more ports. The problem? We're a Cisco shop and due to certain compliance and regulation issues we only run Cisco. Due to the number of VLANS and inter department work being done at certain areas, a layer 3 switch was needed. Because of the phones, POE was needed. Because of the GIS applications, gig to the desktop and 10gig uplinks were needed. Now if you've ever priced a 3560-E with the enterprise image, 10 gig uplinks and POE you'll know they are way over $1000 even without SmartNet. Plugging in a cheapo non managed switch just doesn't cut it. I ended up saving their behind by adding in an old 2950 and changing the setup a little bit. Most of the non essential people were moved to the 2950, freeing up the existing 3560 to be used for phones, AP's and the workstations that did the bulk of the resource intensive work. I explained this, and the consequences at great length. Low and behold, two months later the very same non-IT project manager was asking why the GIS apps slowed down on some of the workstations? Granted, that is an example of bad project management. However, sometimes grey areas can quickly exceed $1000.

pntmarcos
pntmarcos

started with a good premise, but ended with a dull thud. is the best way to deal with gray areas to spend $1000?

MichaelPO
MichaelPO

I have to agree with the previous post. If you had Sr Mgmt buy-in, they should have set the example for the company. It doesn't take very many $1000 quick fixes to blow my budget or derail the message to the company.

ecasteriii
ecasteriii

As a future IT project manager, I find this to be a great lesson to learn beforehand. Why put off the things that you can do today? Customer satisfaction is job 1 with a project manager, and you cannot have success in this arena having unsatisfied customers.