61. Orphaned Deliverables

People develop project artifacts that no one values enough to pay for.

Every process improvement initiative in the systems and software industry defines a flood of new activities, roles, and artifacts. For example, the Rational Unified Process and the German V-Model suggest more than 150 deliverables, each. These deliverables include requirements specifications, design documents, specific models, user-interface concepts, test plans, estimates, . . . the list seems endless.

One of the artifacts that is never questioned is the final deliverable: the product. But what are the merits of the others? Do we need them all? Is it worth spending time and effort producing them?

Photo © James Rye

Sometimes, the team spends time producing artifacts that nobody cares about. It realizes the waste of time and effort, but the process demands that each deliverable be produced. In such cases, the question to ask is,Who is the sponsor of this artifact?

spon•sor: a person or organization that supports an activity by pledging money in advance

Every artifact needs a sponsor who is willing to pay for it. Paying, in this context, means not only being empowered to ask for the production of this artifact but also being able to grant the resources to produce it.

If the deliverable in question is required inside the project, the decision is easy. It is up to the project manager to decide whether producing the artifact helps or hinders in achieving the project goals.

A more difficult case occurs when deliverables are needed or wanted by somebody outside the project team and producing those deliverables is considered an additional burden on the project. In such a case, a sponsor has to be identified.

Consider what happens when an organization wants all projects to come up with standard documentation of their software architecture. The hope is to foster reuse of design solutions and to inform outsiders about the project. The required architecture documentation includes attractive summaries of the most important decisions and overview presentations in a predefined format. However, the development teams’ key goal is to finish on time and within budget. They do not need all this documentation to achieve their goal. A central architecture group could serve as a sponsor in this situation: It could lend a member at the start of the project to help the teams conform to company architecture standards and to help produce the required documents.

Maybe a sponsor in Marketing is needed to produce customer-specific user documentation in addition to the standard user manual. In order to get the required documentation done in time, he might contribute a marketing person to the team to take responsibility for producing these specific user guides during the current release.

Another sponsor could be the head of the central human-machine interface team who wants mock-ups for early feedback and has a manpower budget assigned for this job.

Other people from outside the project can act as sponsors, such as a central quality group that has a budget for collecting long-term statistics about post-release, error-removal rates. This sponsor offers manpower or time and money to the project to do this extra work, usually something that the project manager would be reluctant to fund from his own budget.

It is easy to ask for things to be produced when you do not carry the burden of justifying the costs. Most centralized methods and tools departments are not in a position to give resources to projects. Their job is to suggest what they think are good ideas and to persuade every project to go along with them. But since they are ministers without portfolio, their recommendations are not always welcomed by projects.

Orphaned deliverables are those produced without articulated and proven need; in other words, without a sponsor. Consider the merit of each orphan. If you find that nobody is willing to pay for it and that the project doesn’t need it, don’t do it. If you think it is a good idea but nobody is paying for it, find a sponsor.