1.0 Title: Reverse Process Analysis
2.0 Purpose: To discover the sequence of events that led to an outcome by starting at the outcome and decomposing what had to happen to produce that result.
3.0 Usage: This can be a useful method to develop a plan - especially as a starting point when all else fails. It usually needs to be combined with analyzing from a starting point and even starting in the middle and working both ways. Ultimately however - projects still have to start at the beginning and work their way through - usually in a different sequence than the plan called for, and most often with a rather different product than the original elevator pitch vision statement.
This requires a fairly static notion of what the end product is, and if many alternatives are still open for discussion - may be very expensive to do for each to useful level of detail.
4.0 Frequency: This rarely gets done more than once, and often only gets partially completed. That's fair - as the deliverable is not a product in itself - unless you are getting paid to produce a glossy report or a thesis to a committee, in which case you will have a rather expensive coffee table book that is long past its service life. (It may have some use as a teaching tool perhaps.)
5.0 References:
6.0 Responsibility:
7.0 Ownership:
8.0 Effort
9.0 Risks
10.0 Contents:
the RPA can be a series of tagged diagrams which may be expand from right to left in a reverse order of complexity - identifying not only the components but any "kitting" and information requirements.
10.1 The End Point
This may be a sketch, figure, diagram, narrative or any combination that describes what object or system is and does when it is complete. (This is necessarily rough and speculative - since the whole idea is to design and produce the object.)
10.2 The primary components
This is a list or graphic or both which undoes the last stage of integration of the product or even its typically arbitrary, work breakdown structure.
10.3 Input deliverables
For each component the required "deliverables" in the CDID sense of the word, may be postulated that existed in order to create that sub-item. In the case of an engineered mechanical product - not only did the parts have to be manufactured or purchased, but all of instructions for assembly, testing, transporting, purchasing and also needed to exist as well.
This is the best opportunity to identify deliverables that have multiple roles in the process and to avoid redundant and potentially conflicting sources of information. (for example - a CAD file not only contains the geometric information, but also is the source of the need for a part to even exist. If a part can be eliminated from the CAD file - then all of the associated life-cycle costs are eliminated as well. If the part is removed in the CAD design and some other data record is being used to decide whether the part exists or not (such as a written specification) then all of the support activities may occur anyway (such as manuals and storage and spares) even after the part no longer exists.
10.4 CDRL
The above deliverables should be added to a potential CDRL for the project.
11.0 MetaData
12.0 File Handling Policy
13.0 Procedures
14.0 Tutorials