As efficiency in project management sometimes is difficult to find (no matter what kind of methodology used as PRINCE2, PMBOK …) I like to draw the attention to the essence :
- the project has the objective to deliver a product, a solution (the WHATs)
- the means to deliver this product is labor, actions (the HOWs)
The goal is to clarify the vast necessity in a project plan of:
- a product breakdown structure (PBS) &
- a work breakdown structure (WBS).
Here’s a simplified approach (no rocket science) to clarify the myth between both:
1) start to describe your final product
our goal is to deliver a car, that’s our top valued product
2) decompose the product into sub products until you arrive at the level of … screws
we need an engine, some doors, front lights, door steps …
these are the sub parts, and owning their proper value
3) for each product determine all the actions needed to construct
how do we create an engine, what is needed to create a door, what is needed for a light …
expressing the charges in terms of minutes (read cost / minute)
4) determine the sequence of your actions and map them onto your products (1, 2)
create work streams to assemble all these products
expressing the total of all charges by means of a value stream
So in the end we are able to calculate the total cost of all parts used and the labor needed.
Now mapping this more generic:
Some templates
a product description of a PBS
Identifier | Unique key, probably allocated by the configuration management method / asset management lifecycle and likely to include the project name, item name and version number. | ||||||||
Title | The name by which the product is known. | ||||||||
Purpose | This defines the purpose that the product will fulfil and who will use it.It is a means to an end or an end in itself?It is helpful in understanding the product’s functions, size, quality, complexity, robustness etc. | ||||||||
Composition | This is a list of the parts of the product.For example:If the product were a report, this would be a list of the expected chapters or sections. | ||||||||
Derivation | What are the source products from which this product is derived?For example:
|
||||||||
Format and presentation | The characteristics of the product.For example:If the product were a report, this would specify whether the report should be a document, presentation slides or an email. | ||||||||
Development skills required | An indication of the skills required to develop the product or a pointer to which area(s) should supply the development resources.Identification of the actual people may be left until planning the stage in which the product is to be created. | ||||||||
Quality criteria | To what quality specification must the product be produced, and what quality measurements will be applied by those inspecting the finished product? This might be a simple reference to one or more common standards that are documented elsewhere, or it might be a full explanation of some yardstick to be applied. If the product is to be developed and approved in different states (e.g. dismantled machinery, moved machinery and reassembled machinery), then the quality criteria should be grouped into those that apply for each state.Cfr SIL / ISO / | ||||||||
Quality tolerance | Details of any range in the quality criteria within which the product would be acceptable. | ||||||||
Quality method | The kinds of quality method that are to be used to check the quality or functionality of the product.For example:Design verification, pilot, test, inspection or review.Cfr CENELEC | ||||||||
Quality skills required | An indication of the skills required to undertake the quality method or a pointer to which area(s) should supply the checking resources. Identification of the actual people may be left until planning the stage in which the quality inspection is to be done | ||||||||
Quality responsibilities | Defining the producer, reviewer(s) and approver(s) for the product.
|
||||||||
Cost / unit |
example:
what is needed to construct a door, a front light, a door step
determine the material, the dimensions, the color, the cost of material
an action description of a WBS :
ENTRY CRITERIA | Describe an input’s state, an event, or an expired amount of time, which is required before this process or procedure can begin |
INPUT | |
PROCESS | |
OUTPUT | |
VERIFICATION & VALIDATION | Describe the validation activities or checklists to determine if the outputs are usable. |
EXIT CRITERIA | Describe an output’s state (or condition) required before the process or procedure can be declared “complete”. |
METRICS | How this process/procedure is measured to determine its contribution to the business. Will need to compile data, possibly to demonstrate to the organization the return on the investment from the process improvement |
LEADTIME | |
WAIT TIME | |
OCCURENCES | |
/T) | = time to complete a single unit of production |
First Time Through (FTT) | % of jobs that are complete and accurate the first time that they are processed. |
Demand : average number of units per shift | |
Batch Size (BS) | size of typical batch that is processed as a unit |
Takt time : rate of demand | |
Throughput time | = sum of delays and process time |
Process Ratio | = Total process time / Throughput time |
Defect Rate | |
Turnaround Time | |
Value Added Time (VAT) | |
Non-Value Added Time (NVAT) | |
Units Produced | |
Total Uptime | |
Work-In-Progress | |
Value Added Ratio | = Total VAT / Throughput time |
Cost of labor / minute |
and repeat this for every activity needed to construct the product at each level
now bring some order and sequence by workstreams :
Workstream | name |
Owner | name |
Objective | Outcome/benefit to be achieved |
Key Deliverables | New capabilities that will be delivered |
Scope | Broken down into stages for each subject area |
Key Milestones | Reference to delivery timetable (in spreadsheet/Gantt chart format) |
Risks / Dependencies | Situations/events that threaten delivery, including dependencies with other workstreams/projects |
Resources | Time and skills required |