I recently embarked on a personal goal of competing in an Ironman Triathlon. You know that ridiculously long physical event that involves a 2.4-mile swim, followed by biking for 112 miles and then, after that, you get to run a marathon (26.2 miles). I figured that being 60 pounds overweight and having absolutely no real experience in any of the three sports was a perfect metaphor for some of my IT project plans.
As I started my training program earlier this month, I was struck by the notion that being successful in an Ironman competition (or any physical sport, really) is 90 percent preparation (training) and 10 percent execution. It's absolute commonsense. But why is it, I wonder, that with IT projects we so often try and make it 10 percent preparation and 90 percent execution?
For many of us, it seems natural to want to stop talking about doing things and start actually doing those things. After all, talking about what we are going to do is not "accomplishing" or "delivering" anything. Many IT people (myself included) naturally want to start "doing" well before it is prudent to actually do so. We get anxious about getting things done on time. We see the clock or the calendar ticking away toward a deadline and want to do something--anything--to get things moving. But in reality, in too many cases, that is the worst possible course of action.
The same thing is true of my Ironman training. After only two weeks, I was contemplating how soon I could run the big race. I had to remind myself that just two short weeks ago I got winded riding on an elevator; I'm nowhere near ready to self-propel myself the distance between Portland, Maine, and Providence, Rhode Island. Even attempting to do such a thing in the near term would be stupid and likely cause me significant physical injury. And yet, many IT projects are started with the equivalent preparation every single day.
I started my career in a big company (EDS) with mature processes. All my projects included a highly formal project management practice. They included a significant period of time for requirements gathering, and we created project scopes and charters. In addition, there was a detailed and fully resourced project plan, a risk register and formal weekly status meetings. Things ran smoothly. Everyone knew what to do and when to do it.
If something unexpected happened, most of the time, someone had already figured out what we should do just in case that event occurred. All that time spent creating the plan made executing the project a very straightforward process. Because this environment was the only one in which I had worked (other than a convenience store), I just assumed this process was the way projects always worked. Boy, was I in for a surprise.I have since worked in much smaller companies. Almost all of them have lacked the project management discipline that I was "brought up on," if you will. Once you've worked in an organization with formal project management processes, being in one with less discipline can be painful. Here are a few indicators that your organization's project management discipline needs some work:
- Someone says: "What exactly does a Project Manager do?" (Don't laugh. I've been asked more than once.)
- Someone says: "A risk register? What's that?"
- Someone says: "Thanks for coming to the status meeting. Someone remind me again about what we were talking about last week?"
- Someone says: "The project plan? We haven't updated that since the day it was reviewed by the executives."
Here's another real-world example. I had one of my consultants say to me, "This new project manager who you have on this project, he's uh, something else. He's constantly on us about what the status is. We have a status call EVERY SINGLE DAY. It's kind of ridiculous. This guy needs to tone it down a notch, you know what I mean?"
My response went something like: "This project is four months behind schedule, has missed three delivery deadlines and is significantly over budget. I would suggest that maybe the project manager is not the one who needs to adjust here."
With this particular project I have asked a new project manager to step in and fix the mess left by his predecessor. It all spawned from a lack of discipline at the start of the project, which in turn led to a mess throughout the project. I am not without fault in the situation; I did not closely monitor the project's progress close enough to take corrective action quicker. By making changes sooner, I could have recovered much of the lost time. My responsibility is to make sure that I do not have similar problems again.
Competing in an Ironman is just like launching a new IT project. I have a workout plan scheduled for the entire month (a project plan). I know exactly what workouts I am doing every single day (individual milestones). If I miss a workout, or something goes wrong--say an injury, I have a coach (a project manager) who helps me adjust the plan to address the situation. My coach and I both monitor my progress with a heart monitor and GPS tracking (status reports). I have several warm-up races scheduled (milestone deliverables), at which I must be fully prepared to compete. When race day comes (deadline), I am confident I will be ready to compete.
Now if I start bringing Gatorade for my team to status meetings, I might have taken the analogy a bit too far.
What do you think? Love it or hate it, I'd love to gain some additional perspectives. Leave a comment, or E-mail me at [email protected]. You can also follow me on Twitter: @todd_michaud.
And if you are interested in following my Ironman training progress, check out www.IronGeek.me.