• E-mail this page
• |  Print this page
• | 
• | 
• | 

Embracing Project Inefficiency

I ran my local chamber of commerce's 5k this past Friday. Total time elapsed from leaving the office to going home: 90 minutes. Previous experience showed that I could change, travel, then run the same course on my own with half the total elapsed time: 45 minutes. Many participants of a large IT project would be seriously ticked off at a 200% inefficiency; but that would be silly.

Large logistical events simply can't be as efficient as small team events or individual efforts. There are too many moving parts. At the Chamber race, well over 700 folks had to pick up timing chips. Can't distribute them the night before: experience showed the race organizers that too many people would forget to bring them the day of the race. Are you going to fire the gun at the starting line when you see that half the people are lined up at the porta-Johns? And so on.

I think that IT and IT governance efforts have focused so much on planning, management, and efficiency that we sometimes forget to recognize that it's going to be hard. It's going to be inherently inefficient to roll out a project that touches a lot of people and crosses business unit lines. And if we don't own up to it and minimize the impact, or claim that our cool modern practices and tools will act as magic fairy dust, it can make a difficult project even more difficult. But a little honesty and earnest communication efforts can help to overcome the inherent inefficiencies.

Set Expectations.

Right from the start, don't minimize how hard your project is going to be. You won't be doing yourself a favor if you communicate "it's gonna be easy" -- because it probably won't be. The cardinal rule of customer service is to set customer expectations. "Ma'am, the kitchen is a little backed up right now, can I bring you some more bread, or another glass of wine?" is less rage inducing than being ignored forever in a restaurant. Sure, it's bad news to hear that you're not going to get everything exactly the way you want it, but it's better to set the expectation and handle any pushback than it is to not communicate and deal with the rage once it has had a while to fester.

Plan for Slack

Planning for inefficiency goes a long way towards mitigating the effects of inefficiency. It is, for example, much better to plan for deliverables to be late (within reason) due to business exigencies than to plan an overly ambitious perfect project schedule. Planning for inefficiency might extend the project by a week. Planning for perfection and then encountering a snag has the potential to mess up contractor schedules, impact costs, and create downstream cascading delays. It's better to just build some slack in.

Don't Hide Behind Email

Ok, admit it. You're IT. Smart, a deliberate thinker, a little socially awkward: email's a perfect communication vehicle, right? Trouble is, 80% of communication is non verbal. If all you do on your highly complex project is communicate through email, you're only communicating 20% of your true intent, and risking misinterpretation and incomplete communication. Not exactly what you want for your project. You're going to have difficult conversations during your project, and you want accurate and complete communication. There's middle ground between death by meeting and hiding behind email; you need to find it. When you do, you'll both give and receive good information that will help to mitigate the inevitable inefficiencies of large, complex projects.

Jonathan Feldman is an InformationWeek Analytics contributor who works with IT governance in North Carolina. Comment here, write to him at jf@feldman.org, or visit with him at GMIS 2009

Read more about IT governance at governance.informationweek.com

« Google Endorses Health Data Rights | Main | Microsoft IE8 Hype Is Beyond Belief »