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 functions first, remembering that "value" has many dimensions: fiscal value (income or cost savings to the system consumer or sponsor), political value (reassuring a critic or rewarding an ally), and morale value (bits that are rewarding for the team).
- Which are the most expensive functions? Delay implementation of functions that are high in people or financial cost to reduce expenditures if a project is paused or cancelled. This approach allows an expensive function to be deferred easily if project resources become constrained.
- Which functions facilitate testing? Consider how the system will be integrated and tested, then partition and order the build to support these activities. If your system must store and access data, building store facilities first makes it easier to test access functions later. Testing early assures that more time is available to make schedule, scope, and resource adjustments if problems are detected.
- What decisions can be safely delayed? When it isn't necessary to immediately commit to a course of action for some aspect of a system, consider delaying that part of the system until more information is available. This approach allows the decision to benefit from more information and reduces the rework required as we learn more in the course of the project.
- What functions comprise the minimum acceptable product? Feature sets are like an onion because they tend to have many layers. One of the advantages of an effective agile process is that it produces a working product-after each iteration (layer). Sequencing functionality so that early iterations produce a valuable product makes it easier for a project to respond to later schedule or resource developments by declaring victory for the current version of the product and deferring unrealized functionality to "the next version."
You probably noticed potential conflicts among the suggestions above. Some high-risk features may also be high cost, suggesting they should be done near the front of the schedule to make sure they are doable. At the same time, I suggest scheduling them later to defer spending.
Some high-value functions, which we might typically want to develop first, may need most of the system to be completed to successfully implement and test, meaning they must be implemented last. Deciding how to balance these considerations and the best way to sequence the build can be a complex and subjective process; however, the product and project will both benefit from a thoughtful loading effort.
The all-too-common alternative is a mindless sequence to the build that is needlessly inflexible and difficult to manage, making it hard to take effective action if it becomes necessary to throw cargo overboard during the project. By taking a little time up front to consider how to load the project cargo, we increase the odds of reaching port with goods to deliver-even when the sailing is not smooth!
