Everything I needed to know about project planning I learned from my little league coach

When I was kid, I loved baseball. I was good at batting, but I hated being in the field. I could catch the ball as well as anyone, but once I had the ball, I hesitated, especially when there were already men on base. Should I throw to second and hold the base runners? Should I throw to third and try to get the runner out? And while I hesitated, the runners kept running and the problem kept changing. In the end, I would often compromise and throw the ball half way between second and third -- no man's land -- and the runners would just keep running.

My failing was in my fielding strategy: Whenever the batter approached the plate, I would close my eyes and pray that they bunted. If the ball was never hit to left field, I wouldn't have a problem. Sadly, this strategy rarely worked.

After years of sub-par performance in the field, my coach pulled me aside and gave me some advice that has stuck with me through today: Before the pitch is thrown, decide what you're going to do if the ball is hit to you. What will you do if you catch a fly? What will you do if it reaches you on a hop? What will you do if it's hit over your head and rolls to the fence?

This was brilliant advice! While I would still stick with my main strategy -- pray for a bunt -- I could add a new dimension: thinking ahead, and baseball gives you lots of time to think. While the batter was picking out his bat, tapping the dirt out of his cleats, and adjusting his, uh, stance, instead of counting the number of dandelions in left field, I could be thinking about what I should do if the batter did not bunt. Why didn't my coach tell me this years earlier!

Fast forward 30 years...

Today, I often see software project plans that assume the project will be fully staffed on day-one, the hardware will arrive exactly on time with no serious bugs, all external dependencies will be met with perfect quality, and no one on the team will ever get sick, quit, or take a vacation day. The project leader lists those assumptions in the project plan, saying, "If all of the assumptions are met, this project will be successful." The assumptions are really risks that they're not planning to deal with and they're just hoping will go away. Basically, they're planning to fail; praying for a bunt.

It's easy to plan for the best. The key to quality project planning is planning for the worst, contingency planning, planning for the case where the ball gets hit to you, or over your head. And maybe you don't want the ball, but sooner or later it will be hit your way. I've never worked on a project where everything went as hoped, so good planning is all about dealing with things that could go wrong.

Just like in baseball, the absolute worst time to deal with a crisis is during the crisis. There's just too much pressure when the ball gets hit to you to decide where to throw it. And as you stand there, trying to decide what to do, the problem is changing, time is passing, and things are continuously getting worse. If you try to make the decision in the heat of crisis, you're likely to throw the ball into no man's land. Instead, you need to plan for crisis before the crisis happens.

Even before starting the project, ask yourself, for example, what could you do if the hardware gets delayed? Can you continue to develop the software using a simulator or using a different hardware platform? Are there tasks you could move around to minimize schedule impact? Are there features that can be dropped in order to shorten the back-end schedule? In the end, it may be impossible to deliver the software less than X months after the hardware is available, and even that information is critical in the project planning phase.

Every assumption is a risk, and every risk should have a contingency plan. It's even possible to plan for the unexpected (that will be blog entry for another day). And when you're in the middle of the project, and a crisis breaks out, you can calmly and confidently tell people that everything is going according to plan. Then just do what your plan said you would do.


Post a Comment:
Comments are closed for this entry.

Bob Hueston


« July 2016