This is page 2 of:
If Athletes Worked Like IT Shops, The Super Bowl Would Suck
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 Todd.Michaud@FranchiseIT.org. 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.
-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!