Tailoring guidelines for software projects

One trap that's easy to fall into is formalizing artifacts far too soon. Early versions of artifacts often evolve quickly and remain fluid for some time as different representations while their implications are explored. Formal documentation can impede this process; you can waste a lot of time polishing an artifact that's largely expendable. Hand-drawn diagrams and simple descriptions on index cards are often sufficient in the early stages of an artifact and, for some projects, may be all that's required.

An artifact may be tailored so it can be maintained in any form. For example, the Vision document may be captured as a Web page, the Project Plan may be captured as a Microsoft Project file, and the Risk List may be captured as a Rational RequisitePro requirement type.

Some projects spend a lot of time populating templates of formal documents by manually cutting and pasting information. Instead, consider generating required documents from the source, using tools such as Rational SoDA, or negotiate a simpler way of providing the same information, such as using Rational Rose Publisher to generate a Web-based design model. In many cases, you can skip an artifact altogether because the information is implicitly provided in the environment. For example, rather than generate the section of the Requirements Management Plan that lists attributes of requirements types, you may want to only provide the tailored Rational RequisitePro project with the applicable requirements types and traceability, and then walk through it with the interested parties.

Another example is to provide a read-only version of the Microsoft Project files to the interested parties, rather than duplicating graphics into a separate Software Development Plan. A useful artifact is one that communicates valuable information. This information should be at the fingertips of those who need it.

This selection is based on identifying and prioritizing risks to the project, and determining early mitigation strategies for those identified risks.

The well-intentioned project manager or process engineer may have a large wish list of nice-to-have metrics, controls, reports, and so on. However, tasks and work products cost time and money. Some of these costs, such as daily interaction with the environment toolset, may or may not be visible, but simply get folded into lower productivity on standard tasks.

You must distinguish critical process needs from the wish list and determine whether the benefits outweigh the cost. You probably have highly trained staff with valuable skills in designing, implementing, and testing. Don't have them spend hours each week filling out forms, enhancing documentation, or fighting with unwieldy tools.

If these tasks are required, consider having them done by qualified support staff. The format of intermediate work products-those work products not intended for the final product-is not as important as the task and thought needed to produce them.

It doesn't matter what they look like, or what tools you use to build them, provided they serve their purpose. As Dwight D. Eisenhower said, "The plan is nothing; the planning is everything. One trap that's easy to fall into is formalizing work products far too soon. Early versions of work products often evolve quickly and remain fluid for some time as different representations while their implications are explored. Formal documentation can impede this process; you can waste a lot of time polishing a work product that's largely expendable.

You need to make sure that your new project does not contradict or violate your partnership agreements. Tailor the Project to the Process Environment. Now you can try to tailor your project to the process environment. It means that you need to fit the basic characteristics of your project to the components of your process environment.

Where possible, combine documentation and testing across your organization. Consider using standardized documents to manage your new project. Formalize requirements traceability and cross-team communication. Use in-project reviews and regular audits to make sure development requirements of the project meet business requirements of your process environment. Use reliability modeling and testing.

Do your best to choose the simplest adequate lifecycle for your project development. Create a safety plan that determines how to reach and control secure development and testing environments within the life-cycle of your project.

Incorporate the Project into the Process Environment. Finally you can incorporate the project to the process environment. It means that in case the project is tailored successfully, you can develop and iterate it many times within your environment. Organize the work. You need to examine the WBS of your project and define the level of detail required to identify processes of your environment employed My Account.

Task Management Software. Business Management. Project Management. For example, an organization using a staged representation can exclude process areas at maturity levels 4 and 5 when the organization is focused on achieving maturity level 3. An organization using a continuous representation can exclude process areas outside the scope of the target profile; however, benchmarking opportunities using the continuous representation are possible only through the use of equivalent staging, so careful analysis should be used before deciding to exclude a process area.

Process areas can be excluded when they are determined to be not applicable to the organization being appraised. This means that goals and practices of the process area are inherently outside of the organization's scope of work. For example, if an organization does not use suppliers for products or services critical to its product development efforts, it can exclude Supplier Agreement Management from its appraisal.

Under these circumstances, a maturity level rating could still be determined; however, that maturity level rating must also state which process areas were considered not applicable. A process area is designated "not rated" if it is outside the appraisal scope or if insufficient data is available to satisfy the data-coverage criteria.

A maturity level cannot be determined if process areas at that maturity level or below are not rated. In other words, "not rated" process areas are interpreted as not achieved and act against the achievement of a maturity level.

Specific goals and generic goals cannot be excluded from process areas included in the scope of an appraisal effort. If a process area is applicable, each of its specific goals is applicable as well as the generic goals within the scope of the appraisal. Specific practices and generic practices are typical activities necessary to implement and institutionalize the goals of the process area. Therefore, appropriate alternative practices can be substituted for specific practices and generic practices if the alternatives are effective in implementing and institutionalizing the goals.

All other model components subpractices, typical work products, examples, amplifications, elaborations, and references are informative and can be excluded at will. Previous page. Table of content.