The implementation of GJB5000 requires compliance with the organization’s standard processes. However, GJB5000 acknowledges the complexity of software projects, the activities and work products recommended by the standard process are not applicable to all projects, and each project can tailor the activities and work products of the standard process according to its own actual situation.

Here we talk about how to crop the working product during the software development process.

First, explain the cropping range of the software work product. The output of any work product, whether it is a technical document or a statistical form, a summary report, requires a certain amount of work, so in addition to the software used by the final delivery user is the only object that will not be cropped, other work products are tailorable.

Second, we must correctly use the cutting method of the work product. The cropping of a work product is not necessarily a simple removal, does not produce a work product, and sometimes simply takes a simplified way to replace it. For example, the user requirements document cannot be left ungenerated, but it is not necessary to produce a software development task statement that strictly follows GJB438B, but uses the user requirements list instead.

Finally, the work product is tailored on its own value.

Whether the work product is useful for the achievement of the project objectives

The software project manager should be able to judge the value of each work product based on the objectives and actual situation of the project. If the value of the work product to the project is small and there is still a lot of work to be done, such a work product needs to be cut.

For example, for a bidding project, its project goal is usually to “develop software that can be used for demonstration in a short period of time”, so that the requirements, design, testing and other documents of the software can be cropped – there is no need to use formal documents that meet the requirements of GJB438B, and the consequent reduction of formal review and document standardization will save a lot of work and is very helpful for quickly implementing software with certain quality.

Whether a work product is cut depends on whether it is “funded” by someone

Sometimes whether a work product is cropped or not depends not on the inside of the project team, but outside the project team. In this case, the value of the work product for the project is not very large, but it is of great value to stakeholders outside the project team.

For example, the quality system inspection requires that there must be a software development plan document that complies with GJB438B; The transition review requires that the software development summary document must be provided, etc.

In principle, whoever needs these work products should pay for them. If someone is willing to “fund” this work product, the project team can generate this work product for her. Although the actual scenario is often a direct request from the management department, in this case, the software project manager should submit a “funding” application to the relevant departments.

In short, if there are no above two reasons, then this product does not have to be produced.

This is exactly:

Work products can be cropped, whether to crop to see the value

If there is an exception, no value can be cut

Bibliography: Project Style: In-depth Understanding of Software Project Behavior Patterns, Author: (US) Tom DeMarco et al., Translator: Jin Ming, Publisher: People’s Post and Telecommunications Publishing House