Sunday, November 28, 2021

Certified Hybrid-Agile Master with MS Project Online Course

 



I’m pleased to announce the availability of the Certified Hybrid-Agile Master Online Course for Agile practitioners and Management professionals:

CERTIFIED HYBRID-AGILE MASTER WITH MS PROJECT 


It’s a complete video course on Hybrid-Agile Management with both theory and practical. Certified Hybrid-Agile Master course is an in-depth, hands-on, practical-oriented Certification Course and literally, only such course, worldwide. It also comes with full money back guarantee. 

While Agile practitioners use a large number of stand-alone frameworks such as Scrum or Kanban, many organizations execute their projects with a Hybrid-Approach. Multiple trends on various Agile frameworks inform this reality of Hybrid-Agile. In fact, some reports inform that usage of Hybrid-Agile is more than 80%!

A Hybrid-Agile approach combines two or more Agile and Non-Agile approaches. A Hybrid-Agile approach also follows real-life. Taking an example, no one takes the same prescribed meal (like a prescribed framework) every day! You mix and match the content of your meal based on your appetite, health-condition, and availability. Similarly, many organizations follow Hybrid-Agile approaches, which best meet their project requirements, project type, complexity and associated deliverables.

This course is highly needed by Agile practitioners as Hybrid-Agile projects are quite advanced, complex, and many times difficult to manage. With this course, you will know:

  • Hybrid-Scrum Management
  • Hybrid-Kanban Management
  • Hybrid-ScrumBan Management

You learn and work with a number of foundational as well as advanced concepts in Hybrid-Agile Management

  • Building a variety of Hybrid-Agile projects
  • Adjustment and tracking Hybrid-Agile projects
  • Baselining and Baseline Management in Hybrid-Agile
  • Earned Value Reporting in Hybrid-Agile
  • Hybrid-Scrum Burndown/Burnup charts (for Scrum as well Traditional)
  • Various Histogram and Pie Charts
  • Hybrid-Kanban Cumulative Flow Diagram (CFD) 
  • Closing Hybrid-Agile projects

With this course, you will also have an End Course Exam. On clearing the exam, you get the Certified Hybrid-Agile Master credential, indicating your mastery over hands-on Hybrid-Agile Management. 

Top 10 Features: Certified Hybrid-Agile Master

  1. Total Video Duration: 14+ hours (14h 21m 40s)
  2. Number of Videos: 138
  3. Number of Lessons: 10 (+1)
  4. Total Exercises (Practical): 100+
  5. End-course exam and credential as a Certified Hybrid-Agile Master.
  6. In depth understanding of Hybrid Scrum, Hybrid Kanban, and Hybrid ScrumBan.
  7. Ability to apply the concepts with the Hands-On tool of MS Project Agile.
  8. Generate various reports such as Burndown/Burnup Chart, CFDs, Hybrid Sprint Reports, Histograms and Pie Charts, Earned Value reports, among many others.
  9. A large number of exercise and solutions files (over 100), which you can download, use and practice.
  10. A large number of tips and tricks points to know throughout the course.

Course Breakdown: Certified Hybrid-Agile Master

  • Lesson 1 – Welcome (7 videos): 17m 56s [17 minutes 56 seconds]
  • Lesson 2 – Understanding Hybrid Project (15 videos): 59m 43s
  • Lesson 3 – Hybrid Project with MS Project (15 videos): 1h 49m 27s
  • Lesson 4 – Hybrid-Scrum Project (27 videos): 3h 33m 16s
  • Lesson 5 – Hybrid-Scrum Project Reporting (16 videos): 1h 47m 07s
  • Lesson 6 – Hybrid-Kanban Project (24 videos): 2h 36m 16s
  • Lesson 7 – Hybrid-Kanban Project Reporting (10 videos): 1h 11m 26s
  • Lesson 8 – Hybrid-ScrumBan Project (15 videos): 1h 23m 01s
  • Lesson 9 – Hybrid-ScrumBan Project Reporting (7 videos): 40m 39s
  • Lesson 10 - Conclusion (2 videos): 4m 39s
  • All Exercises (Certified Hybrid-Agile Master)

The details on it this course, with information on additional features, are available also available at:

https://www.managementyogi.com/p/certified-hybrid-agile-master.html


What is the Certification offered by this Course?

This course comes with an end-exam with a set of questions, which covers both theory and practical of Hybrid-Agile Management. To clear the exam, you need at least 70% score. 

With completion of the course and clearing of the end course exam, you will receive the unique credential: Certified Hybrid-Agile Master with MS Project. 

Unlike many courses available in the world today, this course has in-depth theory and practical with an Agile Management software tool. Hence, you can apply the theoretical understanding in a hands-on manner. Your Certified Hybrid-Agile Master credential demonstrates your knowledge of Hybrid-Agile theory and practical. 

What is Full Money Back Guarantee for this Course?

There are no little tricks, such as – “terms and conditions apply”, “** conditions apply”, “guarantee not applicable if you have seen 15% of the course”, “give at least one attempt or we will refund your money” etc., as you would have seen in many places. What you see and read here is what you get.

The premise is simple.

Go through the complete course for 15 days. 100% video content of this course will be available to you. 
If you don’t like the course, I’ll refund your full money. 

Note: You can also evaluate the videos before paying any money. Twenty (20) videos will be available for your evaluation, even before your purchase. 

Applicability and Validity

  • Theory Used – Hybrid-Agile Management combining Traditional, Scrum and Kanban
  • Software Used – MS Project 2019 Online Desktop Client 
  • Price 
    $95 USD / Rs 6,649  (3 months access)
    $159 USD / Rs 11,149  (6 months access)
    Extension is also available. Price calculation will be pro-rata.
  • Payment – paypal.me/managementyogi
    (Enter the amount; Invoice will be generated after payment)
    OR, you can pay via Bank Transfer or Payment. For this, please send a mail to managementyogi@gmail.com to get account the details.
  • Available since – November, 2021
  • Primary Format – Video
  • Status – Available
    (accessible via laptop/desktop)

Detailed Course Breakdown

The detailed course breakdown is shown below. It details hours of learning, number of videos and various exercise details. You can scroll to see the full content. 




If you want to buy this course or have any question, please send an email to managementyogi@gmail.com. 



Wednesday, November 24, 2021

Prioritization Techniques in Agile for Product Managers


Let’s consider two real-world scenarios. In one, a product manager is asked to work on the top priority items in his project’s product backlog for an upcoming iteration. The product manager replies, “It can’t be done because the business executives have set everything to be of top priority.”

In a second situation, a few stakeholders didn’t want to proceed with a compliance requirement, which had a time limit. Rather, they wanted to pursue another feature expected to bring more value. In this case, the product manager said, “We can make that feature happen in place of the compliance one, except that the CEO has to spend some time in jail, because of non-compliance!”

Now, in the first situation, the product manager has been forced to address all items, because all are high-priority. Do you think anything would be delivered properly at all? In the second one, if the CEO goes to jail, do you think the product manager could in any way keep his or her job?

How could these situations be properly addressed?

If you are thinking that we need prioritization or the right prioritization schemes, you are correct, and this will be our topic of discussion in this article. We will focus on prioritizing items in the Product Backlog, which is a key element of Agile development.

The product backlog (PB) is an ordered list of user requirements, typically owned by the Product Owner or Product Manager, who is the proxy for the customer. Do note that Agile practitioners use the term ordered for product backlog items (PBI) in place of prioritized. Prioritization, after all, is a form of ordering; however, going forward I’ll use these terms interchangeably.

Before we cover various techniques for prioritization, let’s understand the essential qualities of a Product Backlog.

A DEEP Product Backlog

The product backlog is characterized by four qualities, i.e., the PBIs in the PB are detailed appropriately, estimated, emergent in nature, and prioritized. The acronym for it is DEEP.

  • Detailed appropriately: It means the high priority items in the product backlog are listed in more detail (or fine-grained) as compared to the low priority items, which are coarse-grained.
  • Estimated: The PBIs are estimated. The high priority items can be estimated in story points, ideal days, or any other estimate, whereas the low priority items can be in the form of epics.
  • Emergent: The product backlog is not a static artifact. When new items are discovered, they are added to the bottom of the product backlog.
  • Prioritized: The items in the product backlog are prioritized, with the highest priority PBIs on top of the product backlog (these items are pulled to be executed in the upcoming iteration). The prioritization of the items is generally done with respect to the value delivered, though there can be other factors as well. We will see more on this shortly. 

As you may have noticed, one of the qualities for the PB is that the items are prioritized. However, not all PBIs must be prioritized, rather you should do it for some immediate Sprints or iterations. This also compliments the first quality for the product backlog, (i.e., detailed appropriately).

In fact, the backlog follows the concept of rolling wave planning, (i.e., we plan for few immediate iterations in detail, whereas the future iterations will at a higher-level). This has been illustrated in the below figure. 

Earlier, I noted prioritization occurs generally with respect to the value delivered, but there can be other factors at play, as well. Let’s take a look at some of the other factors for prioritization now. 

Factors in Prioritization

Below is a list of factors which help to prioritize:

  • (Business) Value of having the features
  • Cost of developing the features
  • Compliance, i.e., set of rules considered safe to be followed such as regulations
  • Knowledge gain, which tells to what extent the team will gain them while working on features
  • Amount of risk removed by having the features
  • Resources available because a particular backlog item may require specialized resources (human or physical) or resource with domain knowledge
  • Dependencies among the features or PBIs

These prioritization factors are depicted in the below figure. 

With these basics in mind, let’s consider some of the techniques used in prioritization. 

Various Techniques for Prioritization

Simple Scheme

Here we label feature items as “Priority 1,” “Priority 2,” “Priority 3,” and so on, or “High,” “Medium,” and “Low” items. One of the drawbacks in this scheme is that business executives want everything to be P1 or high priority types.

Monopoly Money

The sponsors of a project are given an equal amount of money for the project budget, and then asked to distribute it amongst system features. This is effective only when limited to prioritizing business features.

100 Point Method

This is a scenario where each stakeholder is given 100 points that he or she can use to vote for the most important requirements. How points are distributed is up to them – 30 for one item, 20 for another, or even all 100 points for a single item. This method was first developed by Dean Leffingwell et al.

Kano Analysis

Kano Analysis (or the Kano model) informs regarding product features which are perceived to be most important to customers. This method was created by Dr. Noriaki Kano and focuses on differentiating product features, as opposed to focusing initially on customer needs. This analysis involves two dimensions:

  • On X – axis: The product feature presence is listed.
  • On Y – axis: Customer satisfaction is listed. 

The features are divided into three levels, which we will understand by considering an example of a phone.

Must-have or Mandatory features:

These are must have features and mandatory. For example, basic functions of a mobile phone include switching on/off, making calls, receiving calls, sending/receiving text messages, etc.  These are threshold functions, which are basic and necessary to sell the product. Without these, the product is useless. However, beyond a point, on these functions, customer satisfaction does not go up – rather, as shown above, it goes down.

Performance or Linear features:

Here the motto is “the more the better.” The higher the number of performance functions leads to higher customer satisfaction. For example, if the phone is slimmer, and it boots-up quickly, then we have more satisfied customers. The price of the product is related to the linear features, but these are not differentiators to sell the product. For that, we need exciters and delighters.

Exciters and Delighters:

These are related to hidden customer needs, or things that the customer is not even aware of. These provide a unique selling point (USP) for the product; however, absence of these doesn’t necessarily mean that the customer won’t be satisfied. For example, having a face recognition feature in a phone that allows it to unlock. Nevertheless, the presence of such features can lead to premium pricing of the product.

There can also be other levels such as indifferent, which tells us that the feature presence is irrelevant to the customers’ satisfaction, and reverse (i.e., the presence of such a feature will reduce customer satisfaction). 

MoSCoW

MoSCoW is another technique for prioritization. The letters stand for:

  • M – Must Have
  • S – Should Have
  • C – Could Have
  • W – Won’t Have this time (but would like to have!)

The “Os” are added for easy memorization. The idea in the MoSCoW technique is that instead of prioritizing the requirements as high, medium, or low, priorities are specific.

  • Must Have: Minimum Usable Subset (MUS) of features which the project must deliver. The best way to find a must have feature is to ask the question, “What happens if this feature is not available?” If the answer is “cancel the project,” then we have a “must have” feature on our plate.
  • Should Have: These are important, but not vital requirements. If you leave them out, it will be painful, but the solution is still viable. If you skip these, you may need some kind of workaround for it.
  • Could Have: These are wanted or desirable features, but less important. A “Should Have” may be differentiated from a “Could Have” by reviewing the degree of pain caused by the requirement not being met, in terms of business value or number of people affected.
  • Won’t Have this time: These are features which your team has agreed on having in the long run, but will not deliver in this release or iteration. 

Cost of Delay Divided by Duration (CD3)

The CD3 method was developed Donald Reinertsen. The name CD3 comes from 3Ds in “Cost of Delay Divided by Duration.” Cost of delay informs what the penalty of cost of delaying these features. This is expressed in a Money/Time format (i.e., $400/week or $150/day). Next, it is divided by the duration or time that will take to build the feature. The feature with the highest score is tackled first or will have the highest priority.

One frequent question I receive is how to model these prioritization schemes with the help of software tools. Let’s work through an example using MS Project software. 

Prioritization of Backlog with MS Project 2019 Agile

MS Project 2019 supports both Scrum and Kanban. We will use Scrum framework to understand how the backlog items are prioritized, and we will follow the following steps.

Step – 1: Define a Prioritization Scheme

Let’s take a simple scheme, which, as the name tells us, is not only simple, but also widely used. We need to create a custom field. In our case, I’ve created a custom text field “PBI Priority”, which is shown below: 

Next, in the look-up table, highlighted in the above figure, you have the option of defining the priority level – high, medium, low, or undefined. The “undefined” level will correlate to the PBI when it’s newly entered into the backlog. 

As shown above, we have four levels in the list with the “Undefined” one set as the default.

Step – 2: Enter the Product Backlog Items

You can enter the backlog items into the “No Sprints” column, which is for the product backlog in the Sprint Planning Board view. The items should be estimated, and you can use story points, ideal days, or any other format as needed. This is depicted below. 

We have items listed with the default PBI priority “undefined” shown for each item.

Step – 3: Assign Priorities to the PBIs

Next, we will assign the priorities, which, is again, quite simple and straightforward. To do so, I’m using the Sprint Planning Sheet view and choosing the priority for each PBI in the “PBI Priority” field. 

Step – 4: Reorder the Product Backlog

The final step is to reorder the product backlog items. This is done by simply dragging and dropping the cards or the PBIs in the backlog, under the Sprint Planning Board view. As you reorder, the high priority items are moved to the top of the backlog, whereas the low priority items will appear towards the bottom. This is depicted below. 

If you are using another prioritization scheme associated with a formula, you can define the formula and use the look-up table to set the priorities for the PBIs. 

Prioritization of Backlog with MS Project for the Web

Microsoft recently released a new version of Project, Microsoft Project for the Web. With this app or service, you can also create a backlog of items and order the items by dragging and dropping the cards in the Board view. 

As shown above, we have a product backlog where the PBIs are listed and ordered. These items will then be subsequently pulled into various Sprints. One great advantage of MS Project for the Web is that you can drag and drop and in turn, change the dependencies. This can be done in the Timeline view, which is shown in the figure below: 

I hope you now better understand the various product prioritization techniques and how to apply them with the help of a software tool. Though product prioritization is the job of a product owner or product manager with inputs from team members, it is equally useful to know if you are working as a project manager, scrum master, Kanban flow master, or in any other similar kind of role. 

--

This article was first published by MPUG.com on 7th January, 2020.


References

[1] I Want To Be A PMI-ACP: The Plain and Simple Way, by Satya Narayan Dash

[2] Microsoft Project Live Lessons with Money Back Guarantee, by Satya Narayan Dash.

[3] Scrum Product Ownership: Balancing Value from the Inside Out, by Robert Galen

[4] Agile Product Management with Scrum: Creating Products that Customers Love, by Roman Pichler

[5] Documentation for Microsoft Project for the Web, by Microsoft Corporation.


Saturday, November 20, 2021

Retrospectives and Intraspectives for Agile Practitioners


Two woodcutters were assigned to chop wood in a forest. Both formed a team and started early and earnestly. Although working a distance from each other, they felt the competition to produce the best results.

On that first day, the first woodcutter heard his counterpart stop cutting before the day was really finished. He was surprised, but continued none-the-less. In the next few days, a similar thing happened. A couple of weeks passed. The first woodcutter paid a visit to the second one, confidently thinking that he has cut more wood since he had been working such full, long days. He was taken aback seeing that his counterpart has almost completed twice as much work. He asked, “How is that possible? I never stopped or took a rest, whereas you stopped many times!” The second woodcutter replied, “Yes, but I didn’t actually stop. Rather, I sharpened my axe, so that I could continue cutting better for the next day, the next week, and the weeks ahead.”

Perhaps many of us know this story of the two woodcutters and the key takeaway: “sharpen the axe once in a while and you get better results.” Stephen R. Covey slightly reworded the moral of the story eloquently in his book “The 7 Habits of Highly Effective People” by saying, “Sharpen the saw.

Let’s apply this by thinking of a team of Agile practitioners working on a software product. The team has a number of generalizing specialists, who have skills spanning across coding, testing, integration, and deployment among others. They are cutting code instead of cutting wood, are testing the soundness of code instead of the solidness of wood, and so on.

Would you ask them to continue working week after week or month after month without ever sharpening their tools? I guess not.

Retrospectives and intraspectives in Agile development do exactly that. They sharpen the saw, or ask us to reflect, rethink, and act with renewed vigor. They provide a better understanding and also help us to work sustainably over a long period. 

Retrospectives

The importance of taking the time for retrospection comes from one of the 12 core principles of the Agile Manifesto.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In Agile, frequent retrospection is done in order to continually improve the effectiveness of the team, project, and organization. The retrospective process consists of two words:

  • Retro – meaning recent past, and
  • Perspective – meaning the way of looking at things.

Hence, you can say that the retrospective is about looking back or dealing with past events or situations for the purpose of improving in the future. You can define the retrospective process as:

A recurring workshop in which the team looks back on their work over a period, reflects upon it, and learns. The team applies this learning in future work to improve people, processes, and products.

One of the widely used iteration-based Agile frameworks is Scrum where every iteration is known as a Sprint. There is a Sprint Retrospective at the end of every Sprint, and it’s an opportunity for the team to inspect itself and create a plan for further improvements. The plan is preferably acted-upon in the next Sprint. Retrospectives are also applicable in flow based Lean-Agile frameworks, e.g., Kanban, where you can have retrospectives on-demand. 

Types of Retrospectives

In iteration-based Agile development, a project is usually divided into releases and each release into various iterations. Hence, for Agile practitioners, there are three types of retrospectives:

  • An Iteration Retrospective: Usually focused on the team involved in the iteration.
  • A Release Retrospective: A wider perspective because it may involve other people in the organization who have contributed to the release, but are not part of the core team.
  • A Project Retrospective: Also has a wider perspective, and is usually from an organizational point of view.

Retrospectives can happen in the following cases:

  • When the team ships something. In a flow-based Agile (like the Kanban method), a release doesn’t happen during a specific time period. It can happen at any time.
  • When more than a few weeks have passed since the last retrospective. Again, in a flow-based Agile process, there is no specific time a retrospective can happen. You can decide in such cases.
  • When the team is stuck (i.e., the work items are not flowing through the team).
  • When the team reaches a milestone. 

Conducting Retrospectives

A retrospective is not a post-mortem meeting, nor should it be a dissection on what events happened wrongly or why. A retrospective should also not be a witch-hunt meeting to put blame on someone or some group. The key to a constructive successful retrospective is for all participants to adhere to the Retrospective Prime Directive, as noted by Norman Kerth, which says:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Four Key Questions

Considering the prime directive, there are four key questions in a retrospective, which can also be used when creating your meeting agenda:

  • What did we do well, that if we don’t discuss we might forget?
    (or what is going well?)
  • What did we learn?
  • What should we do differently next time?
  • What still puzzles us?

Look at the wording closely. We aren’t asking what went wrong, rather as the third question goes, we are asking what should be done differently next time.

Five Steps in a Retrospective

A retrospective, as noted, can happen as part of both iteration-based and flow-based Agile frameworks. A retrospective is a process, and it goes through a series of steps. See the figure below. It’s depicts a two-hour (120 minute) retrospective with time spread across the five steps of:

  • Step 1 – Set the Stage
  • Step 2 – Gather the Data
  • Step 3 – Generate the Insights
  • Step 4 – Decide What To Do
  • Step 5 – Close the Retrospective


Let’s understand these steps.

Step 1: Set the Stage

Here the time box (how much time), goal (what you are going to do), approach (how you are going to do it), and work agreements or ground rules are set. If any particular Agile method is used, then the values of that method are announced. The principle of “Every voice and early” is followed, i.e., everyone should speak, and they should speak early. If they don’t speak early, then they may not speak at all!

Step 2: Gather Data

Once the stage has been set, the next step is to gather data. Start with hard data such as metrics, events that’ve happened, or stories completed. Create a visual record having events, story completion, date, etc. The visual is very powerful. Data doesn’t have emotions; therefore, ensure that you bring feelings into the data by asking questions such as, “When were the participants excited to come to work?”

Step 3: Generate Insights

After you have gathered the data, it’s time to evaluate, analyze the data, and provide insights. This step tells the “why” i.e., we generate meaningful insights from the data collected in the previous step. These insights help the team to work more effectively and efficiently – the main goal in any retrospective.

Step 4: Decide What to Do

This step reveals the “what to do” part or the planning part. If you have a long list of decision action items, choose a few, which the team can commit to doing – preferably in the next one or two iterations. A good way to have the action items implemented is to create story cards or backlog items and have them available in the product backlog. Ensure that you assign action items because it drives commitment.

Step 5: Close the Retrospective

In this step, you close the retrospective. When you close the retrospective, don’t forget to appreciate your team for the hard work done during the iteration (or release or project) and during the retrospective.

Retrospective Techniques

In each of these above steps, a number of techniques can be used. We will discuss a few of them. 

Techniques to “Set the Stage”

1) Check in: In this technique, we hope that people put aside their concerns and participate in the retrospective articulating what they want from it. The retrospective leader asks only one question and each person answers in round robin fashion. The answers are usually in one or two words or a short phrase. Example questions can be:

“In a word or two, what you expect from the retrospective?” Or “What is one thing in your mind as we begin the retrospective?”

2) Explorer, Shopper, Vacationers, Prisoners (ESVP) Quiz: Let’s first understand what the letters in ESVP stand for.

  • Explorers: Someone who is eager to know new ideas and insights.
  • Shopper: The participant looks over all information, but is happy to go home with one useful new idea.
  • Vacationers: The participant is not interested and happy to be left out.
  • Prisoners: Someone who thinks that he or she has been forced to attend the meeting and should be doing something else.

In this exercise, each retrospective participant anonymously writes sown his or her position and puts it on a slip of paper or index card. Next, the leader takes the responses and put them into a histogram or a check sheet.


After the results have been collected, you should tear up the cards so that no one is worried about being tracked with handwriting analysis! With this information, you will have a good idea of how your audience feels about the retrospective. This exercise informs about the participants’ attitudes in particular.

Other techniques that can be used in the step of setting the stage are: Focus on/focus off, working agreements, or ground rules. 

Techniques to “Gather Data”

1) Timeline: A timeline is used to stimulate memories of what happened in the time period that just passed. The retrospective participants write down memorable and meaningful events on sticky notes and paste them in chronological order on a board. A sample example is shown below, which in this case, is for an iteration.

 

2) Mad Sad Glad: Here you have three posters labeled – “Mad,” “Sad,” and “Glad.” You can also have color-coded cards or sticky notes. For example: red for mad, yellow for sad, and green for glad.

The team members then put the color-coded cards on the labelled posters and describe times during the project when they felt mad, sad, or glad. This exercise gets the “feeling facts” out on the table.

Other techniques that can be used in this step are: triple nickels, color coded dots, locate strengths, team radar, or like to like. 

Techniques to “Generate Insights”

1) Force Field Analysis: This technique was originally used in a change management context (and also in risk management), but it can be adapted for retrospectives. Here, the team defines a desired state they want to achieve. Then, identifies the following:

  • Driving forces (“forces of change”), which affects the desired state positively.
  • Restraining forces (“forces against change”), which affect the desired state negatively.
  • Factors that can influence reaching the desired state—either by increasing the strength of a supporting factor or by reducing the strength of an inhibiting one.

Utilize a white board and markers with this analytical technique. 


2) Learning Matrix: In this case, participants look at the data generated from four perspectives by brainstorming on them quickly. This is a good technique to use if you are pressed for time. The four perspectives can be put on a flip-chart or white board, each in a quadrant, as depicted in the figure below. 

Brainstorming, Ishikawa diagram, patterns and shifts, and the five whys are some of the other techniques that can be used in this step. 

Techniques to “Decide What to Do”

1) Short Objects: This technique helps to discover differing perspectives on what the team members should or should not do, or should do more or less of. The team brainstorms and put their perspectives on three or two posters or flip charts. The titles of each could be:

  • Same as/More of/Less of (SAMOLO)
  • Stop Doing/Start Doing/Keep Doing (StoStaKee)
  • Keep/Drop/Add
  • What Worked Well/Do Differently Next Time (WWWDD)
  • Smiley/Frowny 

2) Prioritize with Dots: This technique is used to check how the team prioritizes a long list of changes, ideas, issues, or proposals. Here each participant is given 10 dots to be used across the issues. A scale, such as shown in the following bullet points, can be applied.

  • Priority 1 issues receive four dots.
  • Priority 2 issues receive three dots.
  • Priority 3 issues receives two dots.
  • Priority 4 issues received one dot.

The issues that have the most dots are chosen, and those should be focused on.

Other techniques that can be used in this step are: retrospective planning game, SMART (speciļ¬c, measurable, attainable, relevant, and timely) goals, and circle of questions. 

Techniques to “Close the Retrospective”

1) +/Delta (Plus/Delta): This technique is used to retrospect on the ongoing retrospective and identify areas of strength and areas needing improvement. It starts with drawing a “T” on a flipchart or white board, divided the space into two parts: “+” and “delta.” The items that the team should do more of should be listed under “+” and ones that can be changed by the next retrospective are put under “delta,” which is the Greek alphabet meaning “change.”

 

2) Return On Time Invested (ROTI):

This technique generates feedback on the retrospective process itself and determines the effectiveness of the retrospective session from team members’ perspectives, by asking if the participants believe their time was spent well. You can use a scale rating system (“0” representing a lost cause and “5” indicating a very high return or the highest ROTI).

Other techniques that can be used in this step are: appreciation, temperature reading, helped, hindered, hypothesis (HHH), etc.

 

Intraspectives

The term, intraspective, consists of two words – intra meaning within (or insider) and perspective meaning the way of looking at things. Hence, intraspective is defined as an inspection or reflection for the team, within an iteration. Like a retrospective, an intraspective is a reflecting practice; however, unlike retrospective, it’s often preceded by an event that didn’t go well. Unlike the retrospective process, which can happen at points throughout the project, at the time of a release, or at the project level, the intraspective process happens within an iteration.

Let’s take an example with Scrum to understand. Post daily scrum, the Scrum Master noticed or heard something about consistent failure in release builds due to frequent configuration changes in the build scripts. The Scrum Master calls for an intraspective meeting on it to figure out if change is needed on the way team is modifying build scripts.

In iteration-based Agile methodology, the introspection meeting is, in essence, a retrospective within an iteration. The need for such can also occur in a flow-based Agile project. The purpose of an intraspective is to discuss a particular issue, event, or activity in order to determine if any change(s) are needed in the team’s practices.

The main goals of an intraspective is to inspect and adapt – the two key foundations of empiricism. Intraspectives happens on an ad-hoc or on-demand basis. It also helps in building a self-organizing team. 

Key Points about Retrospectives

Irrespective of the type of retrospective or techniques used in a retrospective, below are a few key points to note while conducting one.

Item #1: Everyone should participate: If you remember the “setting the stage” step, we first discussed a check-in, which asked for everyone’s participation. When there is buy-in from the team as a whole, it is easier to proceed with further actions and improvements.

Item #2: Choose two techniques for each step (one short and one long). There can be many techniques or activities in the five steps of a retrospective. Preferably have one short and one long for each step, and you may altogether skip the shorter one, if you lack time.

Item #3: The Product Owner (PO) should be present: The PO is a core part of the team and should be present at retrospective meetings. As I interact with Agile practitioners, lack of the PO’s involvement has been noted by many as the most pressing issue. It’s important that the owner is a part of reflection discussions.

Item #4: For a longer retrospective, consider breaks. If the retrospective is more than two hours, ensure you have break on your agenda, even if it is just 10 minutes. Schedule breaks when there is a logical breaking point, when the energy level of the team drops, or when team members ask for one.

Item #5: Retrospective is not a post-mortem session. Any meeting that turns into dissecting issues or finger-pointing is futile. The retrospective should never be a whining session, rather an opportunity to contribute, reflect, and plan actions. Remember the story of the woodcutters and the retrospective prime directive, noted earlier.


--

This article was first published by MPUG.com on 15th October, 2019.

 

References

[1] I Want To Be An ACP – The Plain and Simple Way, by Satya Narayan Dash

[2] Agile Retrospectives – Making Good Teams Great by Esther Derby, Diana Larsen, and Ken Schwaber

[3] Agile Practice Guide, by Project Management Institute (PMI)



Wednesday, November 17, 2021

Fundamentals of Project Risk Management Framework


I’ve compared projects with living entities (like human beings), and the life cycle of a project with life cycle of a person. Similarly, the PMBOK guide, when expanded, is called project management body of knowledge or a body of knowledge for project management. Like every human being has a body which he or she needs to be aware of, every practicing project manager needs to be aware of the body of knowledge for project management.

Your body consists of many critical organs such as brain, heart, kidney, liver, etc. As such, the project management body of knowledge (or PMBOK) consists of many key organs, which PMI calls as knowledge areas. These are identified project management areas defined by knowledge requirements and various components such as processes. Examples of such knowledge areas can be project scope management, project schedule management, and project cost management, among many others.

In this article, we will discuss one of the more important knowledge areas, project risk management. It’s a key organ in the body of knowledge for project management. In the latest edition of the PMBOK guide, the processes, interactions among the processes, and key documents associated with risk management have changed significantly. I’ve also found in my interactions with project managers and risk managers that many struggle with these concepts.

 

Process Flow in Risk Management

Let’s talk about the process flow and overall interaction in the risk management knowledge area.

  1. First, the risk management plan is prepared in Plan Risk Management process. This plan tells how you are going identify, analyze, manage, and monitor the risks.
  2. Next, we identify all possible individual project risks, as well as overall project risk in the Identify Risks process. This process creates two project documents – the risk register and the risk report. Identified individual risks become part of the risk register, and the risk report has information on the overall project risk and also summary level information of individual project risks.
  3. As we have a lot of individual risks in the risk register, we cannot manage them all. Hence, the first prioritization of risks happens in the process of Perform Qualitative Risk Analysis (or Perform QLRA). This step is mandatory. The higher the priority of the risk, the higher the ranking of the risk in the register.
  4. We also have a second level of prioritization of risks where we quantify them in terms of schedule and/or cost. This is done in Perform Quantitative Risk Analysis (or Perform QTRA) process. This step is optional. In this process, we look for combined effect of individual risks on the overall project objectives. Here we get the overall risk exposure for the project and it’s documented in the risk report.
  5. In the next process of Plan Risk Responses, we plan for the responses of the risks, (risks that we have prioritized earlier). The risk responses are developed both for individual prioritized risks and overall project risk, and documented in the risk register and the risk report, respectively.
  6. Then, in the Implement Risk Responses process, we implement or execute the risk response plans for both prioritized individual risks and the overall project risk in order to address the project risk exposure.
  7. Finally, we monitor the set of finalized and prioritized risks throughout the life cycle of the project. This happens in Monitor Risks process and means that we monitor both the risk register and the risk report.

The interaction among the processes are depicted in the below diagram.

As shown in the above figure, all the processes from Plan Risk Management to Implement Risk Responses interact with each other. The process of Monitor Risks is the umbrella process which “overlooks” the rest of the six processes. The dotted line between Perform QLRA process to Perform QTRA process indicates that the former one is mandatory, whereas the latter is optional.

At this stage, we’ve looked at two project documents – the risk register and the risk report – while explaining the process interactions, but you might be wondering what they contain. 

The Risk Register

The risk register is a key project document used in many other knowledge areas and many other processes. Here are the top points about the risk register:

  • It’s a repository in which the outputs of project risk management processes are recorded.
  • It primarily contains the information about individual project risks.
  • It’s progressively elaborated throughout the processes of risk management knowledge area.

Some important fields in the risk register are:

  • Risk Identifier (ID) – It uniquely identifies the risk. The ID is set when the risk is first created.
  • Risk Title – It’s usually a short, one-line description of the risk.
  • Risk Status – It tells the current status of the risk. It can be proposed, open, closed, assigned, managed etc.
  • Risk Category – This informs the category of the risk, which can be taken from the risk breakdown structure (RBS). Examples of categories can be technical, resource, internal, external etc.
  • Risk’s SWOT Value – This is determined by doing a strength, weakness, opportunity or threat (SWOT) analysis, and it tells if risk is a threat or an opportunity.
  • Risk Owner – This informs who will own the risk.
  • Risk Probability (P) – It’s the chance of occurrence of the risk.
  • Risk Impact (I) – It’s the effect or impact of the risk.
  • Risk Score – This is calculated by multiplying the probability (P) and impact (I).
  • Risk Cause – The cause(s) of the risk.
  • Risk Effect – The effect(s) of the risk on one or more project objectives.
  • Risk Trigger – It informs on what events or conditions the risk can happen.
  • Risk Response Strategy – This field notes the response strategy for individual risks. One or more strategies can be applied.
  • Risk Response Actions – These are actions associated with the strategies.
  • Risk Action Owner – This informs who will own the risk response action.

A Sample Risk Register

In the real world, you can use any risk management software tool, a simple spreadsheet, or MS Excel, to create a risk register. A sample risk register looks like the one shown below. I’ve broken it down into two parts because of large number of fields in the risk register. The first part of the risk register has information on risk identifier, title, status, category (which can be mapped to the RBS ID), SWOT value, risk owner, probability and impact values, and risk score. 

For the second part, the risk IDs have been maintained so that you can associate the risks with their respective fields. Here, we have cause, effect, risk response strategy, response actions, action owners, and risk review details.


The risk register can have other details such as contingency plans, fallback plans, secondary risks, and a watch-list. You can add these fields into the above template when you create your own risk register.

The Risk Report

The risk report is another key project document, which is also used in many other knowledge areas and processes. Here are the top points about the risk report:

  • It primarily contains the information about overall project risk and a summary level information about the individual project risks.
  • It informs on the overall project risk exposure.
  • It’s also progressively elaborated throughout the processes of risk management knowledge area.

Some significant components in the risk report are:

  • Overall project risk: The sources of overall project risk which drives the overall project risk exposure. It informs on the probability of meeting:
    • Schedule target
    • Cost target
  • Summary information of individual project risks: Overall detail of individual project risks.
    • It will be updated with prioritized list of risks as you pass through various processes of risk management.
  • Risk sensitivity analysis:
    • You can have sensitivity analysis for duration, cost, tasks and risks.
    • Criticality analysis of the project tasks can also be shown.
  • Calculated contingency reserve for the project.
  • Audit details.
  • Summary conclusion.

A Sample Risk Report

You can create risk report using any software tool such as MS Word/MS Excel. A sample risk report looks like the one shown below. In the first part of this report, you have a summary of the project plan, then overall project risk exposure details and finish date probabilistic analysis. 

In the second part of the report, we have duration sensitivity analysis, risk register summary details, audit information, and summary conclusion.


Expanded Flow of Processes in Risk Management

Now that we know the contents of the risk register and the risk report, let’s extend the risk management process flow with these two documents. See the figure below.


As you can see, after the risk register and the risk report are created in Identify Risks process, they are passed through subsequent processes of risk management knowledge area.

Now, let’s check what happens in each of these processes. 

Plan Risk Management process:

The risk management plan will have:

  • Strategies and approaches to manage the risks of the project.
  • Categories of risks represented in a breakdown structure known as risk breakdown structure (RBS).
  • Probability and impact definitions of risks as well the probability and impact matrix.
  • Risk appetite and risk threshold values of stakeholders.
  • Risk related roles and responsibilities.
  • The format and content of risk register and risk report.

Identify Risks process:

The risk register will be created the first time with:

  • List of all identified individual risks.
  • Potential risk owners, i.e., if you can have a risk owner, you can assign him/her in this process. The final risk owner will be confirmed in Perform QLRA process.
  • Potential risk responses, i.e., if you can have risk responses, you can note these responses in this process. The final risk responses will be confirmed in Plan Risk Responses process.
  • The individual risks will have other details such as risk ID, title, category, status, cause(s) and effect(s).

The risk report will also be created the first time having:

  • Sources of individual project risks.
  • Summary information about individual project risks.

Perform Qualitative Risk Analysis (QLRA) process:

In the QLRA process, both the risk register and the risk report will be updated with:

  • Probability and impact values of the individual risks.
  • The score of the risk, which is basically a multiplication of probability and impact values. It has been shown earlier in the sample risk report.
  • The risk owner will be confirmed in this process.
  • A watch-list containing low priority risks will be created here and it will be part of the risk register.

The risk report will be updated with:

  • The prioritized list of individual project risks.
  • A summary detail of the risk register.
  • A summary conclusion.

Perform Quantitative Risk Analysis (QTRA) process:

In the QTRA process, only the risk report will be updated. It will have:

  • Overall project risk exposure assessment along with information on meeting the schedule and cost targets. These we have seen earlier in the sample risk report.
  • Probabilistic analysis of the project with S-curves, histograms, sensitivity analysis, criticality analysis. Our sample risk report contains results of S-curve and sensitivity analysis. To understand more about criticality analysis, you can refer an earlier published article.
  • Contingency reserve information can be part of the risk report as well. An earlier article explains on it with an example.
  • Prioritized list of individual project risks. The risk exposure of the individual project risks can also be part of the report.

Plan Risk Responses process:

In this plan risk responses process, both the risk register and the risk report will be updated. The risk register will be updated with:

  • Risk response strategies for individual project risks. The risk responses will be confirmed here.
  • For every response, you can response actions for which risk response action owners will be noted.
  • Contingency plan and fallback can be developed here.

The risk report will be updated with:

  • Risk response strategy for overall project risk.
  • The summary level information of the high-priority individual project risks.

Implement Risk Responses process:

In this process, both the risk register and the risk report may be updated. This process implements the risk response plans created in Plan Risk Responses process. The risk register may be updated to have any changes to the earlier risk responses for individual project risks, whereas the risk report may be updated to have any changes to the earlier risk responses for the overall project risk.

Monitor Risks process:

In this process, we monitor the risk register and the risk report, which may be updated. The risk register can be updated with:

  • New risks that are identified.
  • Current status of the existing risks, e.g., the change in status, probability value, impact value, score etc.
  • Closure of outdated risks.

The risk report can be updated with:

  • Current status of the overall project risk.
  • Current status of the prioritized individual risks.
  • Conclusion and recommendations from risk audit.

Summary Video

Finally, a summary video on risk management, which captures the essence of processes and their interactions in project risk management knowledge area. (Duration: 5m 28s) 


For aspiring Project Management Professionals (PMPs) and Risk Management Professional (RMP), understanding of the new risk management framework and process interactions are crucial before getting diving deeper into individual processes. It’s also foundational if you are preparing for the Certified Associate in Project Management (CAPM) examination. I hope the information I’ve presented in this article helps to build your foundation of knowledge on the new risk management framework knowledge center.

--

This article was first published by MPUG.com on 26th March, 2019. 


 

References

[1] PMP Live Lessons, PMBOK 6th Edition – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] Project Management Body of Knowledge (PMBOK) Guide, 6th Edition, by Project Management Institute (PMI)