Schedule Game #4: Hope is Our Most Important Strategy

 

A few years ago, a senior manager called me. “We have a project in trouble. We started off hopeful, but now it looks impossible.” I asked a few questions, and discovered they had never done a project like this before. It was bigger, in a different language, on a new platform, with a shorter schedule. No, they hadn’t arranged for any training (for anyone), but they were hoping they could complete the project. After all the entire fortunes of the company were riding on it.

I wish I could tell you this was an isolated circumstance. But all over the world, there are projects right now where “We hope we can” is the mantra of the day. See Hal’s e-tip Hope is not a project strategy for the individual’s perspective on this.

I’m a pragmatic realist. I do understand that many times organizations and people undertake projects where they really don’t know enough to know how to pull off this project. In that case, the PM has some obligations:

  • Recognize and write down where you have risks. You may have technical risks (new language, new platform), schedule risks (shorter schedule), or most likely, both.
  • Choose any lifecycle other than waterfall. If you’ve never done anything technical like this before, iterate on some prototypes, or iterate on a few features, to see where your work takes you.
  • Consider a Hudson Bay start” to see if you can make anything. A Hudson Bay Start will show you what you’re hoping for (those unknown risks that get up and bite you in the leg).
  • Make sure people have the technical functional skills and solution-space domain expertise. If necessary, train people. It’s cheaper to train everyone on the project in a new language than waste time.
  • Plan to iterate on everything, especially your planning and scheduling.
  • Ask for help from the project staff on making status visible and easily updated.
  • Don’t be afraid to ask for help from other people. You’ve never done this before, don’t think you can somehow know everything you need to in time to do the project enough good.
  • Even if management or your sponsors don’t want management reviews, you hold them. I like developing lots of milestone criteria, as well as release criteria.

I hope for lots of things, and most of the time nothing happens, unless I work to make it happen. Same thing with projects. Hoping for a good outcome is not enough. Planning, seeing where you are, and updating the plan — that’s what makes project success possible.

I appreciate you, Hal, for writing the e-tip and triggering me to write this series.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in schedule games and tagged , , , . Bookmark the permalink.

2 Responses to Schedule Game #4: Hope is Our Most Important Strategy

  1. Kevin Richey says:

    Hi Johanna, been reading your blog for several months now. I love what you write, please keep it up.
    My company is adopting C#.Net for a major initiative, so we paid for expensive on-site training. The school was recommended by MicroSoft.
    We learned nothing, it was a complete waste of time and money for us and probably ruined any chance of funding for future training. How do you find good technical training for a group that is smarter than your average teacher?

  2. Jeff Atwood says:

    > for a group that is smarter than your average teacher?
    Nobody asked me, but if your group is that smart then have the best communicator on your team lead everyone else in learning C#.
    > But all over the world, there are projects right now where “We hope we can” is the mantra of the day. See Hal’s e-tip Hope is not a project strategy for the individual’s perspective on this.
    I have an entry on this I call “Defeating Optimism”:
    http://www.codinghorror.com/blog/archives/000284.html
    It’s also related to #5.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>