Roles and responsibilities of a Project Manager


Leadership & Project Management Champions

Project ManagerOften, I see number of web searches made on this topic. So, I thought of presenting my views on the same.

The below four lines would be the starting sentences of a typical project team meeting.

“Is every one there?” Manager asked to his team in meeting.

Answer “Yes” came in asynchronously from all different voices.

“Is everything fine? Anyone facing any issues in their project objectives?” This is manager’s voice.

One member raised the voice and told “I have one issue regarding the database design”

………….. And it goes on for an hour.

Why am I presenting the dialogs at the first place to explain the role & responsibilities of Project Manager?

In the above conversation between PM and team, we understood project monitoring role of the PM. Actually, the role & responsibilities of a Project Manager is little complex and needs to be explained elaborately in clear terms…

View original post 250 more words

Measure of success


Leadership & Project Management Champions

Whenever we are stepping into a new year, we review all our previous year plans, achievements & of course failures. For the new year, we set new goals, renewed old goals, great wish list. No matter where you are what you do, you measure success in that activity. Success produces happiness. To me, the measure of success is –

“Your success is not measured by outsiders praise but by your rejoicing heart”

Benchmark set by our mind will vary from our manager’s expected level. They praise(or scold) you for every activity you performed based on their expectation. But, sit back and think how do YOU feel about the outcome? Do you feel happy? Then you achieved it.

In case you feel unsatisfied, then also you need to be happy as you learnt a new way to get higher level of satisfaction.

Last year was a great year for me. I…

View original post 130 more words

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

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

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

Feed Positivity


One evening an old Cherokee told his grandson about a battle that goes on inside people. He said, “My son, the battle is between two wolves inside us all. One is Evil. It is anger, envy, jealousy, sorrow, regret, greed, arrogance, self-pity, guilt, resentment, inferiority, lies, false pride, superiority, and ego.
“The other is Good. It is joy, peace, love, hope, serenity, humility, kindness, benevolence, empathy, generosity, truth, compassion, and faith.”

The grandson thought about it for a minute and then asked his grandfather, “Whichwolf wins?”

The old Cherokee simply replied, “The one you feed.”

– ANONYMOUS

Agile Estimation – Story Points and Ideal Days


In Agile, estimating the project duration requires the estimation of the size to happen in first place. Size estimation of a user story or a feature or the entire project can be done either by story points or ideal days. Mike Cohn dealt this in great length in his book “Agile Estimating and Planning”.

Team estimates the size based on their experience (compared to expert judgement in PMBOK), analogy (compared to analogous estimation) or splitting a big story into smaller pieces and estimating it (compared to decomposition in PMBOK).

Let us see very high level overview of these two agile estimation methods:

Story points – Story points will be assigned to each user story based on its nature expressed by the team (big/small, complex/simple, risky/straight-forward, etc). Story points are relative i.e. simple user story carries 5 points, complex one (twice that of simple one) carries 10 points.

Ideal days – Ideal days are ideal number of days taken for a user story based on the assumption that the team works on the user story and only that user story (without any interruption).

In general, Story points are widely used as a measure of size in Agile but it is left to the team which one they want to use – Story points or Ideal days – based on their need.