If Athletes Worked Like IT Shops, The Super Bowl Would Suck
Written by Todd L. MichaudFranchisee Columnist Todd Michaud has spent the last 16 years trying to fight IT issues, with the last six years focused on franchisee IT issues. He is currently responsible for IT at Focus Brands (Cinnabon, Carvel, Schlotzsky’s and Moe’s Southwestern Grill).
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.
-Marc
May 13th, 2010 at 7:43 am
Hi Todd:
As I started reading your story I began to get excited and was thinking about sharing it with my IT shop, but as I read on I found your conclusions to be off the mark IMHO. I have worked in very large IT shops and I have worked as a 1 man shop and in a couple of startups. I am currently managing a medium sized IT staff in a medium sized internet company.
The question is not wether to act like a startup or a large company with processes. That is a false argument. Have you considered there may be a third way?
Have your staff create and internalize your processes. You help through guidance in this development.
They own the problems of delivery. They create the way ‘How’.
When there is a threat to any of the 3 constraints. Point it out and then let them focus. Transfer even more ownership, do not big-brother them.
Use techniques that get the talking more about what they are delivering in the moment.
I hope you take this the right way, I have gone down several paths of what industry experts say, Agile or Waterfall. But the best way is NEITHER. The best way is to treat them as indivduals and create a ‘Team’ that works together to overcome the task at hand in the most fun and creative environment you and they can create. If you are in a situation that this is not the case, consider that your first priority. Everything else is window dressing.
Consider reading “Rework” by DHH, creator of Ruby on Rails and co-founder of 37 signals. It is just out, short and gets to the point.
Just one more thing, be careful about developing process that mimic the physical world. In software development it is all about finding the shortcuts. Just yesterday I had a developer deliver a ‘shortcut’ that reduced our testing cycle from 1 hour to 12 minutes. That is a huge win since this is done several times/day and our QA tasks of test automation are in limbo as this process goes on. Now we have about 2 more hours per day we can do test automation development. That shortcut is not possible in a triathlon.
Software development is not a physical process but a creative one. It is not at all like building a bridge, or a boat or running a triathlon. Rather, it is more like an artist on a canvas. It is less a craft and more an art and you are the artist. Painting by-the-numbers will not work since what they are building has never been done before. It is a blank canvas with multiple brushes stroking simultaneously. The finished work must also be delivered on time, and budget and work within your existing environment. Plans are interesting but really creating a ‘Team’ as I described above is the only way I know of that consistently works.
Best Regards,
Andy Savage
May 13th, 2010 at 8:31 am
I love the piece. And it’s very true: discipline is challenging. Part of the issue is that we learn to like fighting fires. It can be fun to have late night emergency calls, argue with contractors, and hop on planes to triage some IT problem in the enterprise. They’re all signs that we’re important. But they’re also signs that our processes don’t work. It’s like when you start measuring your workouts by how wretched you feel two days later. Barely being able to walk is a sure sign that you’ve had a good workout but it’s also a great way to get injured so that you never meet your goals!
May 13th, 2010 at 10:49 am
So how does this square with the concept of Agile? I understand that Agile does not mean, no planning, but it also does not mean “know everything before the first line of code is written”. Most of my projects hit their significant bumps because the business owners lack imagination (or don’t have perfect foresite – do any of us?).
We ask “what do you want the page to look like?” they tell us and we build that. When they see the page they say “hmmm… that won’t work for us” Now maybe fully interactive mock-ups would help, but really, how different is that from just programming?
When you are training for the IronMan, you know exactly what will be expected, 2.4m swim, 112m bike, etc. If my business owners only knew thier own needs so well…
May 13th, 2010 at 11:40 am
Alas, the existence of project management “discipline” doesn’t often assure project success. I’ve seen too many organizations that produce weekly status reports, subscribe to a specific methodology, and seem to be good only at producing the status reports and the written deliverables, but not at delivering a functional application.
So, in addition to the preparation, one might also need to consider whether the participants have the level of business knowledge, prior project experience, and technical skills necessary to accomplish a big project.
May 13th, 2010 at 12:48 pm
Thank you for this article on the importance of preparation for IT projects. At risk of offending some of the other comment participants, it’s my opinion that the physical world analogy works quite well due to the focus of the article; preparation. Mr. Michaud’s event will be over in a few hours. If he doesn’t prepare properly he’ll fail regardless of how many hours he’s put into the training. IT folks go running off to be “busy” without being productive. I’m typically the technical lead on projects, not the project manager, but I always encourage creativity on the team. In physical training “shortcuts” are indeed availble by finding ways to improve training efficiency thereby obtaining the necessary gains while saving time and preventing injury. The biggest problem I see with the projects I’ve worked on is the shortsightedness. IT folks seem to think about the tasks necessary to accomplish something but rarely think about how to maintain, manage, update, etc. the final product/process. If a customer is looking for a web page design, what they need is someone to help design a site that will increase business, not just have some cool doodads. As an example, Amazon.com dominates in online retail sales because their site gets the job done; make sales. Besides, it may come as a suprise to some, but not all IT projects involve software development.
May 13th, 2010 at 1:24 pm
All,
Thanks so much for the great comments and feedback. I think an important point for me to call out is that ever since I left an organization with mature project management processes, I’ve said things like “We need enough process to cover our ass, but not so much to be bureaucratic.” And 98% of the time, that has bitten me.
Like was mentioned above, having a formal process does not destine one for success, sometimes the process becomes more about completing the process than delivering results. (How many of you have completed a document required by a project well after it’s intended use, just to satisfy a project review meeting?)
But often it is an excuse not to do it. No matter how painful a risk register (or requirement document, or scope document or test plan) is to create, they serve a very specific, very important part of the process.
Regarding Agile vs. Waterfall etc.: No matter which SDLC process you use, project management is integral to the process. Just because you may not be doing deep dive requirements gathering and doing iterative design, doesn’t mean that the process still doesnt need to be structured. I have been in a few shops where Agile was confused with no project management. That is not the case, they are just different executions (plans).
Andy talks about using self directed staff with personal accountability as a way to foster enhanced project delivery. I think that would be absolutely wonderful if you can pull it off (as it appears he has). I have yet to find a culture and a staff that could get there. It get’s even more complicated when a large portion of your “staff” is outsourced to consultants (like mine is).
I still hold true to my idea that the more you prepare, the better you will do. Your approach to the preparation and to the execution may differ from company to company (or from sport to sport), but whenever you sacrifice preparation, you risk of failure increases dramatically.
Thanks again for all the great feedback!