Hope is Not a Strategy

In This Issue:Hope Is Not a Strategy

Four Days Remaining to Sign Up for Project Management Workshop

How Are Things Working For You?

Doug was concerned. He was the project manager for a brand new product. After a few specific features, the product manager wasn’t quite sure what needed to be in the first release. The developers were working in a new language. The testers had never seen this new database. And, his management wanted the first release in six months, but this organization had never released a product in fewer than 11 months. When I spoke with him, he said, “All I have for a strategy for this project is hope. I know better than that–but I don’t know what to do. What can I do?”

Plenty. The first thing you might try is a Hudson Bay Start to see if you can create one running tested feature. A Hudson Bay Start is the equivalent of a “Hello World” feature to see if you can understand how to develop and test something in this new system. A Hudson Bay Start helps people see the risks in the project and what they have to learn.

If you’re curious, the The Hudson Bay Start approach was originated by the Hudson Bay Company in the 1600–1700s in northeastern Canada. The Hudson Bay Company outfitted fur traders. To make sure the traders hadn't forgotten anything they needed, they left Hudson Bay and camped just a few miles away. By making camp just a few miles away, the traders ensured they hadn't forgotten any tools or supplies–before they abandoned civilization. With just a short start to their journey, they had a better idea about their ability to endure the winter.

Doug decided to timebox a Hudson Bay Start. He gave the project team one week to create a small feature the developers assured him would be a “piece of cake.” It wasn’t, but in a week the project team learned what they needed to know to make progress. Doug then took these actions:

1. He led the team in brainstorming the risks, and some of the mitigation plans. For example, the testers didn’t know the new language or the database, so Doug planned to bring in some training from an expert who excelled at helping teams apply what they learned in the training to their product.
2. The project team decided they liked the focus the timebox provided, so they agreed to work in timeboxes to stay focused.
3. The team had never tried an agile lifecycle before, so they were reluctant to try it for this project. But, they were willing to timebox the initial requirements and design parts, so they could move into feature-based development and testing. The team agreed that many partly-finished pieces of functionality would be a disaster. They agreed to finish one feature before moving to another feature.
4. Doug set up a rolling wave schedule on the conference room wall, with the major milestones at the top. In addition, Doug added some explanation about the major milestones, so people would understand what “Demo 1 to Small Customer” meant.
5. He listed the features and tasks for each week, just for the timebox they were in. At the end of the timebox, the team held a short retrospective and planned the next timebox.
6. The team members agreed to make their progress transparent to each other. Doug created a velocity chart, also on the conference room wall. Doug spent time with the product manager to help him understand how important it was to define and rank the requirements for this release.

Hoping for a good outcome is not enough. Once Doug recovered from the shock of being assigned this project, he and the project team worked together to make the project as successful as they could. They weren’t able to meet the six-month deadline, but they did release in seven months. And hope was not their strategy.

Four Days Remaining to Sign Up for Project Management Workshop, Sept 22-24, 2008