PMBOK 6th Edition Interesting Facts

I have the habit of analyzing & collecting the interesting facts about Processes and ITTO items in PMBOK. I did this for past couple of editions. Here are some interesting facts related to ITTO in PMBOK 6th Edition:

3 Most Frequently Occurred ITTO item:

1. Project Management Plan – 48 Times (47 times as Inputs, 1 time as Output). Fun Question: Find out the one process that is not having Project Management Plan as ITTO.
2. Organizational Process Assets – 47 Times (47 times as Inputs)
3. Project Documents – 43 Times (43 times as Inputs)

Total Number of Unique ITTO items: 147

Knowledge Areas with Highest Number of Processes:

• Integration (7 Processes)
• Risk (7 Processes)

Process Group with Highest Number of Processes: Planning (24 Processes)

EEF and OPA are used as acronyms for Enterprise Environmental Factors and Organizational Process Assets respectively. Though these acronyms appeared in 5th Edition Appendix, it is more prominently spelled out in 6th Edition.

Did you notice any interesting facts? Share it with us.

How to prepare Risk Register?

Risk register (also called as Risk Log) is a master document that provides the details of all identified risks and their characteristics. Though it is created during risk identification process, it is periodically updated throughout the project management life cycle & it is an important risk management document in every project.

Risk Register Sample

A sample risk register is shown above. Risk register has complete information about project risks. Here are the list of data fields part of a typical risk register:

• Risk ID – Unique ID to report/review/communicate the risk
• Risk description – Short description about the risk event
• Risk owner – Name of the risk owner
• Risk Category – Category of the risk
• Cause of the Risk – Information about the risk trigger
• Effect or Impact of the Risk – Information about the effect or impact if the risk occurs
• Project phase detected & affected
• Ranking – Ranking of the risk
• Affected WBS activity – WBS ID if it affects a specific work package
• Probability of risk occurrence – This is from qualitative risk analysis
• Frequency of risk occurrence – This from qualitative risk analysis
• Potential responses – Possible responses for the risk. It can be more than one
• Approved final response – Response selected for implementation
• Contingency plan – Plan in place to reduce the risk effect in case a risk trigger occurs
• Fallback plan – Plan in place suppose primary response didn’t work effectively as expected
• Risk Triggers – warning signs of a risk occurrence
• Last occurrence – Last occurred date/time
• Cost of mitigation/fallback plans – Cost estimated for mitigation or fallback plan execution
• Time required for risk responses – helps in schedule plans
• Reserves – Management & contingency reserve information if available
• Risk review audit information – Comments about the risk based on risk review audit
• Current status of the risk – Closed (or) Open (or) Trigger event identified, etc.

There is no limit to the level of details captured in risk register but it depends on benefits of the information and the efforts to update the data. More information captured enables possibility of more detailed reporting.

Let us review uses of risk register:

• Risk register provides main details about all identified project risks with its characteristics (like probability, frequency, category, cause/effect, etc.) along with potential responses and it tracks current status
• Information about secondary & residual risks are also documented in risk register
• Risk register provides key information to all other risk management processes
• It is primary source for risk review process & all kinds of risk reports

Here are the general steps in preparing Risk Register:

• Documenting risk register in spreadsheet software gives more flexibility to manage it. Risk repository database software can also be used
• Identify required information fields that should be included in risk register
• Employ any one or more tools & techniques to identify and document the risk. Many tools and techniques are available for risk identification like brainstorming, interviewing, root cause analysis, checklist analysis, assumption analysis & diagramming techniques
• Record all identified risks with its details. Document the responses in case, if it is available
• Periodically review and update the risk details as and when information about fields like responses, last occurrence, etc. are available
• Document new risks, secondary and residual risks if anything is identified later in the project life cycle

References:

1. Use a Risk Breakdown Structure (RBS) to Understand Your Risks, David Hillson, Proceedings of the Project Management Institute Annual Seminars & Symposium October 3–10, 2002, San Antonio, Texas, USA
2. The controlling influences on effective risk identification and assessment for construction design management. International Journal of Project Management 19 (3), Chapman, R.J. 2001
3. A Guide to the Project Management Body of Knowledge (PMBOK) Fifth Edition, Project Management Institute Inc., USA, 2013

How to prepare Risk Breakdown Structure (RBS)?

Risk Breakdown Structure (RBS) is a tool that provides hierarchical structure of project risks arranged by risk categories. Risk categories generally are grouping of potential risk sources and it differs from one project to another. Below is a sample RBS for construction design project (RBS Template adapted from Dorofee et al., 1996)

RBS Template adapted from Dorofee et al., 1996

Instead of going through a big spreadsheet with hundreds of verbose entries about risks, RBS provides a pictorial representation of related risk categories arranged in a tree structure which is an excellent way of getting the complete information about project risks in a single place for effective communication, management and governance.

Let us review uses of RBS in Project Management:

• RBS provides a structured way to identify risks by going through all risk sources from which project risks may arise
• RBS helps the project team to focus on high risk source areas
• RBS helps project team to develop more generic risk responses based on sources
• RBS helps to manage & report the project risks at different levels – roll up, drill down reporting & in case multiple projects with same nature within the organization uses same RBS templates then it helps in getting comparison reports across those projects
• Reviewing RBS from completed projects helps organization to identify high risk sources, repeated risks, document them as part of existing RBS templates and develop effective responses

Next let us review general steps involved in preparing RBS:

• First check whether organization has RBS templates & tailor it for particular project. In case multiple templates available based on different project types (i.e. large project, IT project, Manufacturing project, etc.), pick the one which matches with current project
• In case templates are not available, start with more generic templates or guidelines generally available & tailor it for current project need
• RBS creation doesn’t require sophisticated drawing software. It can be created using big chart paper or spreadsheet software. It can also be represented by placing each level in different columns in the increasing order in a spreadsheet
• Use brainstorming technique as it is the best one to build RBS structure
• First start with broader risk sources for the Project as higher level risk categories
• Involve stakeholders who are experts in specific source area (example industry or funding) to decompose higher level sources of risk into layers of increasing detail
• Stop adding sub-levels at the point where sources cannot be subdivided further or subdividing will not aid risk management process significantly

References:

1. Use a Risk Breakdown Structure (RBS) to Understand Your Risks, David Hillson, Proceedings of the Project Management Institute Annual Seminars & Symposium October 3–10, 2002, San Antonio, Texas, USA
2. The controlling influences on effective risk identification and assessment for construction design management. International Journal of Project Management 19 (3), Chapman, R.J. 2001
3. A Guide to the Project Management Body of Knowledge (PMBOK) Fifth Edition, Project Management Institute Inc., USA, 2013

What methods & techniques are used in Project Scoping?

One of my blog reader asked me following question – “identify the principles, methods and techniques used for scoping a project?” In reply I wrote a mail explaining all the methods & techniques that is generally practiced for scoping of project. I am sharing the mail content here for everyone’s benefit.

Scoping a project involves two step process – gathering requirements & defining the scope with collected information.

Before I mention about the principles, methods & techniques for scoping, let me present some of my views about Scoping in Project:

• Project Scope should cover everything that satisfies the customer need
• Arriving final approved scope is very challenging task among all the activities in Project Management
• Defining & Managing Scope is the backbone for Project Management
• It is not a single person’s activity & it involves a group of people mainly project stakeholders. Lot of group interactions will be carried out during the requirement gathering & defining scope
• Scoping is so vital which affects all other important factors in Project like schedule (hence delivery), cost, resources and risks
• Generally high level of scope is available as part of Project Charter
• Enough time need to be given to prepare & review for project scope before approval. Also any scope change after approval is going to affect the Project’s outcome
• It is not necessary that entire project scope should be defined & available at the start of a project. It is progressively elaborated.

Requirements gathering uses various elicitation (data gathering) techniques to document exact need of the customer. Some of the group elicitation techniques are:

1. Facilitated workshops – An elicitation technique using focused sessions that bring key cross-functional stakeholders together to define product requirements

2. Focus groups – An elicitation technique that brings together pre-qualified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result

3. Group creativity techniques – Techniques like Brainstorming, nominal group technique, mind-mapping, affinity diagram, Multicriteria decision analysis are used to gather the requirements & define the scope

4. Group decision-making techniques – Decision on gathered information arrived using analytic hierarchy process, voting/democratic methods. Final decision will be arrived by any one of the below methods – unanimity, majority, plurality, dictatorship.

Inputs from subject matter experts(SME) plays a major role in the requirements gathering. Here are some techniques that involves SME’s:

1. Expert judgment – Judgment provided based upon expertise in an application area, knowledge area, discipline, industry, etc., as appropriate for the project scoping.

2. Interviews – A formal or informal approach to elicit information from stakeholders by talking to them directly. Different question types (like open-ended, close-ended, etc) are used to gather the requirements

3. Questionnaires and surveys – Written sets of questions designed to quickly accumulate information from a large number of respondents

Other methods to scope the project is to perform analysis on available information.

1. Document analysis – An elicitation technique that analyzes existing documentation and identifies information relevant to the requirements

2. Product analysis – For projects that have a product as a deliverable, it is a tool to define scope that generally means asking questions about a product and forming answers to describe the use, characteristics, and other the relevant aspects of what is going to be manufactured

3. Alternatives generation – A technique used to develop as many potential options as possible in order to identify different approaches.

4. Context diagrams – A visual depiction of the product scope showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it

Prototyping is creating models of deliverables help in understanding the need & articulate the requirements. Sometimes requirements gathering is performed by observation of tasks being carried out & noting down the processes, pain points and exact user steps

Here are the pointers for further reading:

Requirement Elicitation Techniques – http://www.umsl.edu/~ycnx6/  (Retrieved on 01/06/2014)

Ten Requirements Gathering Techniques – http://tynerblain.com/blog/2006/11/21/ten-requirements-gathering-techniques/  (Retrieved on 01/06/2014)

Elicitation Techniques for Processes, Rules, and Requirements – http://tynerblain.com/blog/2007/09/13/elicitation-techniques-2/  (Retrieved on 01/06/2014)

Analytic Hierarchy Process – http://en.wikipedia.org/wiki/Analytic_hierarchy_process  (Retrieved on 01/06/2014)

Of course you need to go through PMBOK 5th Edition as reference to get universal definitions.

Work Performance Information Cycle

Project information collection & dissemination is a cyclic process & vital one for project success. I collected few points here about project information cycle & thought it is worth sharing with all of you:

•Data collection for a project starts very early in project life cycle

•Lot of information collected in projects from various sources within and outside the project

•Data collection is a continuous process throughout the project life cycle

•Collecting & organizing data and transforming them as information (i.e. project performance) helps in decision making & effective communication

•Data/information can be a written document or verbal statements

•Organizational process assets is repository of information for previously executed projects & provide valuable inputs to other projects

Due to confusion over terms like data & information, PMBOK came up with crystal clear definitions for each of those terms.

•Work Performance Data – data collected on day-to-day basis in project work execution (Example – % of work completed, # of defects)

•Work Performance Information – data collected from controlling processes that are used to analyze the project performance (Example – status of deliverables)

•Work Performance Report – way of representing the project work performance information that delivers intelligence for decision making (Example – status report, project dashboard)

Work Performance Flow