Because so much of what we do in software and project management is abstract, metaphors are particularly important communication tools. When I heard Peopleware author Tim Lister describe reducing project scope as "throwing cargo overboard," I adopted it immediately. If you are worried about getting to port on time with the fuel available, consider throwing low-value or optional cargo overboard; your voyage might still be considered an overall success.
When talking recently with a technical writer for a software product development firm, this metaphor kept bobbing on the surface of our conversation. Her upcoming product shipping date was constrained and difficult to change, and her team was working long hours to support the schedule. Several things she said made me think of cargo juggling:
While the project manager had some schedule float at the beginning of the project, it had all been consumed and it appeared increasingly likely that everything planned for this release would not be done on schedule. Translation: It didn't sound like the project as originally envisioned (the ship, as currently loaded) was on pace to get to port on time.
- The technical writing team was frenetically documenting the subsystem that included the most important set of product features. Unfortunately, this subsystem was also the last scheduled for development. Without functioning code available, the writers were documenting features and functions from design specifications. The documentation was also being concurrently translated into multiple languages. The technical writer saw a significant risk that the documentation would not match the product if the code was not available soon. Translation: Either substantial documentation rework would be needed wherever the delivered subsystem did not match the design specs, or the release documentation would include quality problems.
- She speculated a bit dejectedly that the entire subsystem her team was currently documenting might be pushed to the next release. If the subsystem was thrown overboard at that point, the documentation team's heroic efforts would be wasted. Translation: The planned implementation of features did not match the product priorities. Finishing low-priority stuff first means it isn't available to be thrown overboard to cut scope if needed, and it means important stuff may not get done at all.
The more she said, the more it sounded as though the loading plan for this project's cargo might have benefited from better planning. While that insight would offer little consolation for her at that point, I thought it might be of interest to future voyagers.
A "loading plan" describes where specific cargo will be stored on a ship and considers things like weight, balance, and cargo access. On projects and on ships, it is important to keep expendable cargo near the rail and vital cargo deep and safe in the hold. While I don't know much about the mechanics of ship loading, I've learned a few questions that can help prioritize and sequence software implementation planning (Your mileage may vary. Void where prohibited. These are intended as suggestions and should never be used in place of thinking):
- Which are the highest risk functions? Implement high-risk elements early. These include external interfaces, complex calculations, high-performance components, difficult algorithms, and components that will be built with unfamiliar tools. High-risk items drive schedule and cost uncertainty. When the tough stuff is done early, you will have greater confidence in estimates to complete the project. If things go badly with high-risk elements, discovering this early lets you get specialized assistance, explore alternative approaches, try to negotiate problem areas out of scope, or even kill the project with minimum expenditure of resources.
- Which are the highest value functions? Implement high-value