Why Documenting Information Is Important

Facilitating your process journey …

Why Documenting Information is Important

by

Henry Schneider

Process and Product Quality Consulting, LLC

March 25, 2008

®2008 ***Proprietary*** All Rights Reserved - Process and Product Quality Consulting, LLC


25/4/2008

Information That Should Be Documented

Problems Encountered In the Absence of Documentation

Suggested Approach

Agenda



35/4/2008

Why Should I Document Information?



45/4/2008

Crisis-Driven Organizations

Processes ad hoc — improvised continually reinvented curtailed under stress reactionary

Schedules and budgets unpredictable usually exceeded

Success factors heroes overtime firefighting



55/4/2008

Sources of Crisis

Inaccurate estimates under scoped requirements

explosive code growth

schedule and resource shortfalls

Unmanaged work no corrective action

unruly subcontractors

Volatile baselines changing requirements

uncontrolled versions



65/4/2008

Why Isn’t Product Development More Fun?

Managers

few institutionalized management processes to help them

the management tests come before the learning and the practice

Developers

no understanding or agreementon the requirements and priorities

inadequate time to do the work right



75/4/2008

Is Anyone In Charge?

Senior managers

management of the organization is at the mercy of the projects

customers are constantly complaining

Customers

product is not ready when needed

spiraling costs that exceed expectations

functions are missing or do not work correctly

quality problems after delivery



85/4/2008

Weak management practices

Unachievable commitments

Ad hoc processes

Practices sacrificed for schedule

Practitioners resist discipline

Unpredictable results

Lack of Documentation Leads To



95/4/2008

Categories of Information

Engineering Information

•Requirements

•Agreements

•Assumptions

•Key e-mail

•Key design decisions

•Specifications

•Etc.

Project Management Information

•Plans

•Estimation Models

•Basis of Estimates

•Risks

•Assumptions

•Key e-mail

•Key management decisions

•Issues

•Action items

•Etc.

Process Management Information

•Policies

•Processes

•Procedures

•Work instructions

•Training Records

•Etc.

Support Information

•Historical Data

•Configuration Management Reports

•Quality Assurance audit reports, trends, and recommendations

•Quality Records

•Meeting Minutes

•Key Decisions

•Etc.

Supplier/Vendor Information

•Supplier quality assurance reports

•Supplier status reports

•Invoices

•Contracts

•Agreements

•Requirements

•Etc.



105/4/2008

Engineering Information



115/4/2008

Engineering Involves

Establishing and maintaining sets of requirements customer requirements product requirements product component requirements managing the requirements as the product evolves

Designing the product and its components

Managing the interfaces among the components and between the product and other products

Building the components

Integrating the components to form the product

Ensuring the requirements are satisfied

Ensuring the product will perform as intended

Delivering the product



125/4/2008

What happens when requirements are not written down?

Unstated requirements or poorly stated requirements lead to confusion among staff and customers

People designing, implementing, and testing the work products inconsistently interpret the requirements

It takes an inordinately long time to get agreement on product design

There is an increased potential for higher costs to meet customer expectations

Requirements are accepted by staff from any source they deem to be authoritative

The project experiences a high level of requirements change

There are high levels of rework throughout the project

There is an inability to prove that the product meets the approved requirements

Lack of requirements traceability often results in incomplete or incorrect testing of the product



135/4/2008

What happens when technical designs are not written down?

An ineffective solution is chosen

Products may not meet technical performance requirements or user needs

Increased testing and rework is required to resolve design issues

The product may not be able to accommodate technology upgrades and future growth if the technical solution is not well conceived



145/4/2008

Subsystems do not operate together

There is increased integration test time

The integration environment is inadequate to support the integration activities

A product is released without all the component integration fully tested

What happens when product integration and delivery is not written down?



155/4/2008

There is disagreement among technical staff as to whether the different components meet the requirements

The product being tested does not meet design requirements

Product reliability suffers because defects are not detected or corrected prior to customer release

Added rework occurs because defects that could have been caught early escape into later lifecycle phases

There are arguments among the technical staff as to what the user really wants

The released product does not meet user expectations

Customers do not pay for products that do not meet their needs

End users refuse to use the product as delivered

What happens when peer review and testing approaches/results are not written down?



165/4/2008

Project Management Information



175/4/2008

Managing a Project Involves:

Estimating the scope and work that needs to be performed

Developing mechanisms to acquire identified products

Developing a project plan

Getting commitments to the plan

Monitoring progress against the plan

Identifying and analyzing risks

Taking action to address significant deviations from the plan

Taking action to appropriately mitigate risks



185/4/2008

What happens when project planning information is not written down?

Project estimates are inaccurate

It is difficult to identify deviations from poorly documented plans

Resources are not available/applied when needed

Future projects cannot learn from completed projects because there are no lessons learned

There are unclear responsibilities across groups

Information to support future similar projects is not made available

Too much time is spent trying to determine project status

Data needed for management decisions are not available when needed

Corrective action is not taken early when it is least expensive

Lack of management insight makes project results highly unpredictable

The customer does not have confidence in the project status reporting



195/4/2008

What happens when risks are not written down?

It is easy to ignore risks when they are not documented or tracked

Risks that are known to project staff are often not known to management

Repeated project failures due to unforeseen (but predictable) risks can cost you business



205/4/2008

Process Management Information



215/4/2008

Managing and Improving Processes Involves:

Establishing the infrastructure for continuous process improvement

Establishing organizational assets and guidelines for using the assets

Establishing ways for projects to take advantage of the advances of others

Training people to help them perform



225/4/2008

What happens when process information is not written down?

There is little visible senior management support for process improvement

Improvement activities are not aligned with business priorities

Improvement efforts often result in false starts and difficult implementations

There are no documented processes for staff members to follow in performing their job roles

Project managers and staff do not use information collected from previous projects to improve their project



235/4/2008

Staff members attend training courses they do not need

Staff members avoid training that is provided

Staff members are not released to attend training they need

Staff members are not appropriately skilled for tasks required to maintain a competitive edge

What happens when training information is not written down?



245/4/2008

Support Information



255/4/2008

Supporting Projects and the OrganizationInvolves:

Establishing and maintaining the integrity of work products

Providing objective visibility into, and feedback on, processes and associated work products throughout the life of the project to support delivering high-quality products and services

Establishing a measurement system to address the many information needs of projects and the organization

Determining which decisions should use a formal evaluation process and then applying formal evaluation processes to make good decisions

Getting to the root cause of problems and addressing the problems to prevent their occurrence in the future



265/4/2008

What happens when configuration information is not written down?

A product baseline cannot be produced when needed

Rework is performed during testing because components are not what were expected

A complete inventory of system components is unavailable when needed

A previous baseline cannot be rebuilt, and this wastes money and resources during maintenance



275/4/2008

No assurance is available that quality standards and processes are followed or achieved

Poor quality work products may be produced

There may be processes that staff avoid

Significant project issues are not escalated for management attention

What happens when quality information is not written down?



285/4/2008

Measurements are used inappropriately

Inappropriate measures can cause unintended behavior

Management is based on perception rather than fact

Measurement presentations may confuse rather than enlighten

Useless measures are collected

What happens when measurement information is not written down?



295/4/2008

It is unclear who is authorized to make what decisions

Decisions are made subjectively

Rationale is unavailable when needed to understand an earlier decision

Too few choices are considered for major decisions

What happens when decision information is not written down?



305/4/2008

The same problem occurs again and again

Missing a more optimal solution costs time, money, credibility, and perhaps even the whole project

Symptoms of problems are addressed rather than the root cause

What happens when causal analysis information is not written down?



315/4/2008

Supplier/Vendor Information



325/4/2008

Managing Suppliers and Vendors Involves:

Managing the contract

Communicating with suppliers and vendors

Overseeing contractor processes

Setting requirements for acquired systems and products

Accepting acquired products and services



335/4/2008

What happens when outsourcing information is not written down?

Supplier selection is not based on the right criteria

Management and technical staff do not have insight into supplier activities

Supplier products are accepted even when they do not meet the product requirements.

Integration of supplier products into a product baseline is problematic



345/4/2008

What happens when supplier/vendorinformation is not written down?

Unstated or poorly stated requirements lead to confusion among staff, customers, and suppliers

Suppliers inconsistently interpret the requirements

Supplier proposals are not consistent

Negotiations are ineffective

There is confusion about the responsibilities of the supplier and the acquirer



355/4/2008

Suggested Approach

Use a process improvement cycle to address the documentation problem

Analyze what has worked and not worked on past projects

Document processes first and reference existing process assets

Once documented, you will have better insight into additional required process assets



365/4/2008

Process roles

Applicable standards

Applicable procedures, methods, tools, and resources

Process-performance objectives

Entry/Exit criteria

Inputs/Outputs

Product and process measures to be collected and used

Verification points

Interfaces

Critical Process Attributes



375/4/2008

IDEAL Model for Process Improvement

Initiating

Diagnosing

Establishing

Acting

Learning



385/4/2008

Diagnosing

Characterize current and desired states

Perform a gap analysis

Develop recommendations

Based on the gap analysis, determine current documentation needs and suggested path forward



395/4/2008

Establishing

Set priorities

Don’t try to do it all at once

Develop an approach

Start documenting the key information that is causing issues due to not being documented, then expand to other areas

Plan actions

Write an implementation plan for the documentation effort and track progress against the plan



405/4/2008

Acting

Create Solution

Decide the format and content for each type of document

Assign a “book boss” for each document (could be the same person)

Pilot/Test Solution

Try the new documents out first before rolling out to everyone

Refine Solution

Make adjustments base on the pilot

Implement Solution

Provide necessary training on how to properly document the information



415/4/2008

Learning

Analyze and validate

Allow 3 – 6 months of use

Collect information on what works and what doesn’t with the new documentation process

Propose future actions

Make appropriate improvements to the process and repeat this cycle



425/4/2008

Questions



435/4/2008

Consulting

• CMMI

• Software Engineering

• Systems Engineering

• Process Improvement

Appraising

• SCAMPI A, B, C

• Gap Analysis

Training

• CMMI/Process Improvement

• Action Planning Workshops

• Measurement and Analysis

• Process Area Specific Training

PPQC Services



445/4/2008

Address: Henry Schneider

President/Senior Principal Consultant

Process and Product Quality Consulting, LLC

2111 Heather Green

Houston, TX USA 77062

Phone: 281-218-6682

E-mail: [email protected]

Web Site: www.ppqc.net

Contact Information

mailto:[email protected]

http://www.ppqc.net/

Business

Why Documenting Information Is Important