Get On With It

If you are starting a project and have enough information to get started on parts of it, then don't wait until you have a complete schedule. undefined

To be applied after

 * work according to Informal Labor Plan.

Alternatives

 * Build Prototypes and Size The Schedule are alternatives to Get On With It.

Contents of following sections belong to the original Organizational Patterns website and have been divided into following parts: Context, Problem, Solution, Discussion.

Context
... you have a good idea of a market need and, furthermore, a good idea of how to get started on parts of the project. You’re eager to get started but want to proceed deliberately and by the path that will be both expedient and productive.

Problem
You can’t wait until you have every last requirement to get started.

Team members are sitting idle because their upstream tasks have not been completed. On the one hand, you want requirements to be done carefully. On the other hand, you have some information, and people sitting idle.

Solution
As soon as you have confidence about some project direction, start developing areas in which you have high confidence. These may lie in the area of hardware development (or procurement), algorithm development, database schema development, etc. Let each subgroup work according to an Informal Labor Plan as if they were in full-swing development.

Note that “high confidence” refers to project direction and requirements, not technology. It’s perfectly all right, and in fact desirable, to work on the technologically risky areas first (see Build Prototypes).

Give yourself some room to retrench later as requirements become more clear.

Discussion
In many projects, behavioral requirements are one of the last things that the designers get right. Many projects ship their first release with only basic requirements met, with economically more significant requirements met in subsequent releases. Telecommunications systems often follow this pattern, offering basic communications systems in early releases and more advanced features later. In fact, behavioral requirements are often overrated in their impact on the overall structure of the system; the code that meets behavioral requirements often lives in application code that is added very late to a robust stable base. The base reflects deep domain knowledge more than it reflects behavioral requirements. There is much common code that can be done early on with high confidence: code that supports common domain functionality that is part of most systems for a given market. This code can often be started or acquired before requirements are firm.

This pattern can increase rework, but it is more in the spirit of piecemeal growth architecture than would be a master-planned system that precipitates from “complete” requirements. It is likely that any false starts will also be educational at the enterprise level. In fact, as a risk management measure one can consciously decide to not commit to the results of such an activity. On the enterprise level, this becomes the pattern Skunk Works; with a project, it is Build Prototypes.

There are two occasions in which you cannot tolerate that rework. First, if the task is the process bottleneck, it must work at peak efficiency, and rework should be minimized. Very occasionally, the rework will take longer than the original task, and so this pattern should not be used.

Teams need good communication with their upstream counterparts through patterns like Hallway Chatter and Responsibilities Engage to make this work.

The principle involved is that a process not constraining the overall system can afford to be done inefficiently and in parallel. It is often the case that the analysts, designers and programmers can get started right away, without having finalized requirements. Serializing their work will take longer than doing 10-20% rework. In one group we studied, the database group constrained the process. They could not afford rework, and had to work in the most efficient way possible. Therefore, they did not start early, but waited until their requirements were stable. The designer/programmers had enough extra time that they could afford to prototype some test databases for themselves, which were thrown away when the database designers did their final design. See [GoldrattCox1986].