Author: Satya Narayan Dash

Satya Narayan Dash is a management professional, coach, and author of multiple books. Under his guidance, over 2,000 professionals have successfully cracked PMP, ACP, RMP, and CAPM examinations – in fact, there are over 100 documented success stories written by these professionals. His course, PMP Live Lessons - Guaranteed Pass, has made many successful PMPs, and he’s recently launched RMP Live Lessons - Guaranteed Pass and ACP Live Lessons - Guaranteed Pass. His web presence is at https://managementyogi.com, and he can be contacted via email at managementyogi@gmail.com.  

Understanding and Using Resource Graph View in MS Project

The Microsoft Project software tool comes with a number of view options, which, at a high level, can be thought of as Task Views and Resource Views. While views such as Gantt Chart, Team Planner, Resource or Task Sheet, Resource or Task Form, Resource or Task Usage are well used by project managers, many management practitioners often overlook the Resource Graph view or use it less frequently. As I have ongoing opportunities to interact with MS Project practitioners, I’ve realized that this view is not all that well understood. As a result, its usage is limited; however, in practice, this can be a very useful view if one can learn a little about it. In this article, we will discuss various ways to launch it, formatting options, a plethora of data representations, and other usages of this view. Let’s begin with the launching options of Resource Graph view. Launching the Resource Graph The Resource Graph view can be launched in many ways. You can go to the Views tab à Resource Views group à Other Views, and, from there, choose Resource Graph view. You can also launch this view by going to the Views tab > Split group, and enabling the Details checkbox. Then, from the available dropdown menu, select Resource Graph for the Details Pane. A third way to launch the Resource Graph view is by going to the Assign Resources dialog box, and clicking on the Graph button. The Assign Resources dialog box can be opened by going to Resource Tab > Assignments group and using the Assign Resources command. Do note that for the Graph button to be activated, some work resources should be available in the project! Formatting the Resource Graph The Resource Graph view primarily pulls data and values from task assignments. In other words, you need to have both tasks and resources assigned for such to populate the Resource Graph view. By default, when you launch the Resource Graph, the below comes up as shown. As you can see in the screenshot, we have just one resource (Resource 1) assigned to one task (Task 1). With the launch of this view, the Resource Graph Tools menu has been activated, as well as the Format tab enabled. In fact, this tab, has three groupings of tools: Format, Navigate, and Data. Do note that the graph, by default, uses Peak Units for graphical data representation. There can be others, as well, which we will see shortly. An important functionality available under the Format grouping is the Bar Styles command, which you can use to unleash the power of this view. Bar styles can be opened by going to the Format tab > Format group, and clicking on Bar Styles. Bar styles shown clearly indicate blue colored bars for the allocation and deep red colored bars for overallocation. Bar styles are important, so that you can visualize and interpret various possible usages of the Resource Graph. Let’s interpret the dialog box shown above: It’s divided into three parts or sections – top, middle, and bottom. The top part has styles for overallocation, the middle styles for allocation, and the bottom styles for proposed booking. The left side of this dialog box refers to the group data or the selected/filtered group of resources, whereas the right side defines one selected resource. In the bottom section, we also have three options to show value, show availability line, and define the desired bar overlap. Do note that the bar style is contextually sensitive, and depending on the data selected under Data Group > Graph: …, some parts may be disabled. For example: If you select Graph: Cost under the Data group, the top section will show the resource cost, but the middle section will be disabled. This is because when considering the cost aspect, there is only allocation, no overallocation. The style of the bar shown in the above figure is vertical. There can be others as well, such as Area, Step, Line, and Step Line. You may also choose not to display a bar style in any one of the aforementioned three sections for a single resource or a group of resources. Key Points about Resource Graph To operate within this view effectively and efficiently, you need to understand certain key points. They are explained in the video [duration: 5m 12s], which I’ve prepared in support of this article. For the best experience, you may want to go full-screen in HD mode and plug-in your earphones.   With these fundamentals in mind, let me explain a bit more about the graphical data representation of the Resource graph. Resource Graph Data Representation The Resource Graph view’s data representation is driven by measurement chosen under Graph: command within the Data group under the Format tab as shown below: As we have seen earlier, by default, the Peak Units will be chosen, but you can switch among the data/measurements, as per your need. For example: Work is the amount of work assigned. The unit will be taken from the Global settings of MS Project. Cost is the cost of assignments. This unit also will be taken from the Global settings of MS Project. Peak Units are the largest percentage of effort (peak) assigned to a resource within a time period. Do note that Peak Units refer to the effort assigned, not the work assigned. Overallocation refers to the work overallocation of the resource. Cumulative Work is the total amount of work assigned till date. Remaining Availability is the effort remaining, i.e., still available for assignment. This unit will also be taken from the Global settings of MS Project. Usages of Resource Graph The Resource Graph can be used as a visual display and can really help you to solve a number of problems with regard to scheduling, costing, resource assignment, resource leveling, etc. I will cover five ways to use the Resource Graph view now. Usage – 1: Checking Resource Availability The availability of a resource can be checked before you assign a resource to a task. This is very useful as you launch the Resource Graph view from Assign Resources option (as we saw earlier) and see displayed the remaining availability of a particular resource. As shown above, the availability of the resource is shown with vertical blue bars. If the resource is fully occupied, blue bars won’t be available for those respective days. With this application, you will also easily see the current resource(s) working on a selected task above in the Gantt Chart view and can determine what others can be allocated. Usage – 2: Viewing Proposed Booking You might be wondering about the purple bars in the previous figure. As indicated in the graph, these show proposed booking. Resources, when added to MS Project, can be either committed (this is the default) or proposed. Committed resources are ones which are definitely available, whereas proposed resources refer to those for which you unsure of availability. Now, for the same resource (Satya Dash) in the previous figure, I can double-click on the resource and change it to proposed by going to the General tab of the opened Resource Information Dialog box. The graph in the timescale portion of the view will change, as shown below. As you can see, the vertical purple bars are now changed to blue, and the availability is also shown. This can be reconfirmed by changing the Remaining Availability in the bottom right part of the legend section to Work. You have to use the Graph: option under the Format tab to switch to work data in the Graph. It’s shown in the below figure. Usage – 3: Checking Overallocated Resources As you may have noticed in the previous figure, a red colored coding has appeared in the legend section of the Resource Graph.  This, as informed by the indicator column, is for overallocation. However, the current resource assigned to the task of “PRD Approval” is not overallocated. Rather, there is an overallocation indicator (red person icon) in the indicator column for the task, “PRD Preparation,” – the task just above with Task ID 4. You may be wondering how will you know why, when, and which resource(s) is/are overallocated for the concerned task? In this case, the concerned task is “PRD Preparation.” To know more, we will change the top panel of the split view to Resource Usage view, while keeping the bottom half as it is. The split Resource Usage view with the Resource Graph view is shown below. The resource assigned to the PRD Preparation task (John Robinson) is clearly highlighted as red, which means this resource is overallocated. This is also reflected in the Resource Graph view in the bottom pane. I’ve changed the data part of the Resource Graph to display Peak Units, which informs the highest assigned resource units (in terms of effort) within a time period. You can switch to other options, and corresponding values with indications for overallocations will display. For example, in the below figure, instead of Peak Units, now we’re looking at Overallocation data for the Resource Graph in the bottom pane, and it’s showing the only overallocation in hours. Usage – 4: Adjusting Critical Resources There is another very useful scenario for which the Resource Graph can be used. To compress the schedule of the project, it’s natural for a project manager to look at the critical path and the critical tasks. There are many ways to look this data, such as using Tracking Gantt view or formatting options in Gantt chart. The problem lies in that with these views, you really won’t know which resources are free and if they can be employed in critical activities. In such cases, it’s useful to bring up the Resource Graph view in the bottom half of the Gantt Chart view and see first if a resource is available for the concerned tasks. One such scenario is shown below. While the resource (Mohan M R) is occupied with the “Design and Develop Backend – 1” task, he is actually also available for “PRD Preparation” and “PRD Approval” tasks. This is shown with the Remaining Availability data view of the Resource Graph and highlighted with the blue color in the bottom pane of the split view. Note that both of these tasks are also critical tasks. This is shown with a light red color in the Gantt Chart view at the top of the split. You may be wondering if the concerned resource can now be utilized in these critical tasks to compress the project schedule. The answer is yes! The PM can analyze this scenario and reduce the schedule from here. Usage – 5: Knowing the Cost Distribution Over Project Life Cycle With the Resource Graph view, you can see the total cost distribution of a project over its life cycle. This can be shown by enabling a group of resources and using the Cost data from the Graph: command under the Format tab. As shown, we have the cost distribution of the project over its life cycle, which is low during the initial stages, goes-up in the middle. and tapers off towards the end of the project. You can also show the cost of a specific resource along with the total project life cycle cost as shown below. The Resource Graph view is a powerful feature in MS Project, and I hope with this article has given you a fair understanding about the usage of this view. References: [1] Online Course: MS Project Live Lessons, by Satya Narayan Dash [ezcol_1third] FREE MPUG Resources Microsoft Project Tutorial Tips from a Microsoft Project MVP Webinar: Microsoft Project Do’s and Dont’s The Project Communication Plan Creating an Agile Schedule 15 Tips for New Users MPUG Newsletter Want access to more? Join MPUG Today! [/ezcol_1third] [ezcol_1third] Microsoft Project Resources Microsoft Project User Group Online Training Microsoft’s Project Website Try Microsoft Project for FREE! Microsoft Project Certifications [/ezcol_1third] [ezcol_1third_end] Additional Resources Create a Monthly Cash Flow Report in Microsoft Project 2016 What is Project Management? [/ezcol_1third_end]  

Planned and Actual Percent Complete in MS Project

While interacting with MS Project users across a couple of industry verticals recently, I encountered a question from a senior mechanical engineering lead regarding Planned and Actual Percent Complete fields. The lead was managing a bridge construction project in the Middle East. The client’s requirement was to show both Actual Percent Complete and Planned Percent Complete in the MS Project Plan. The (Actual) % Complete should have been visible in the tabular view of the Gantt Chart and in the generated histogram reports for L2 or L3 tasks of the work breakdown structure, but MS Project doesn’t have a Planned % Complete field. This had to be created. Another problem the engineering lead faced was getting negative values while having the planning percent complete with the created custom fields formula for the milestones. Obviously, this stemmed from the way the formulas were put in! Inspired by his project, I decided to write this article on the topic of Planned and Actual Percent Complete data within MS Project. We will explore the concept of Planned Percent Complete and how to track it using the custom fields available in MS Project. I will also show the scenario by insertion of the milestone/task and recalculation. In the end, I’ll be creating a histogram report which compares the Planned and Actual Percent Complete. Fundamentals–Baseline and Status Date As a management professional, you need to understand that comparison always happens against the latest baseline after one sets the status date. Many miss this aspect. The whole idea of having a baseline is to have a comparison and measure progress. To explain how to spot this comparison, I’ve created the below video [Duration: 3m:44s]. For the best experience, you may want to go full-screen in HD mode and plug-in your earphones.   With these fundamentals in mind, let’s proceed to checking a few functions and fields in MS Project. Functions and Fields MS Project becomes a very powerful tool when you use its custom fields, functions, and build your own formulas. Rarely a software project management tool comes with such a large number of in-built fields and functions. For the purpose of this article, we are going to use the Date() function. ProjDateDiff As per MS Project software API documentation, this function returns the duration between two dates in minutes. Hence, when we wish to calculate in days, we have to divide by 480, because a day will have 480 minutes. Syntax: ProjDateDiff( date1, date2, calendar ) In this function: date1 (required field): The date used as the beginning of the duration. date2 (required field): The date used as the end of the duration. calendar (optional): The calendar to use when calculating the duration. DateDiff Another widely used Date() function is the DateDiff() function,  which, as per MS Project software API documentation, also returns a time interval between two dates in a long format. Syntax: DateDiff( interval, date1, date2[, firstdayofweek[, firstweekofyear]] ) In this function: interval and dates (required fields): The interval time between date1 and date2. firstdayofweek and firstweekofyear (optional fields): The first one is a constraint constant that specifies the first day of the week, whereas the second one is a constraint constant that specifies the first week of the year. For the sake of example, I’m going to use the ProjDateDiff() function. Nevertheless, you can use the DateDiff() function, as well. Fields Used Of the available built-in fields in MS Project, we are going to use: Baseline Start: Gives the baseline start date of the task. Baseline Duration: Gives the baseline duration of the task. Status Date: Gives the status date of the project. The Project Plan As you can see, we have the below project with its phases, work packages, and milestones. Note: There are two phases, Phase 1 and Phase 2. Each phase has four work packages and ends with a milestone. I am going to show you how to put in formulas to calculate the Planned % Complete for all the tasks in MS Project. Steps Involved To build and calculate the formulas, I’ll follow five steps. Step – 1: Set the Baseline As I’ve said before, without setting the baseline, we can’t do the calculation. To the set the baseline, go to the Project tab > Schedule group > Set Baseline. Then, execute the “Set Baseline…” command, as shown below. Step – 2: Set the Status Date Next, we are going to set the status date, for which you have to go to the Project tab > Status group, and use the “Status Date:” command. Note that as one works with the project and its progress, the status date can be updated accordingly. You may want to see the status date in the Gantt chart view, which can be done by going to the Format tab > Format group > Gridlines, and executing the “Gridlines…” command. For the sake of this example, I’ve set the status to show with a normal line and red color coding. The status date will be visible now in the Gantt Chart View along with the baseline. This is shown below. Step – 3: Create the Needed Custom Fields For the purpose of our calculation, we are going to have three number custom fields and one text custom field: Number1: This will hold the difference between the status date and baseline start. Number2: This will hold the baseline duration of the task concerned. Number3: This will hold the formula comparing the position of the status date with respect to the baseline values. Text1: This will convert the “Number3” into percentage representation. To use these custom fields, go to the Format tab > Columns group, and execute the “Custom Fields” command. As highlighted above, we will be using three number custom fields (and a text custom field). Ensure that the formula is applied and the calculation for task and group summary rows use the formula embedded into the appropriate custom field. Step – 4: Determine Planned % Complete For each of the three number fields, we will be using these formulas. Number1: ProjDateDiff([Baseline Start],[Status Date])/480 The Number1 field will hold the value of difference between Baseline Start and Status Date. If the Status Date is ahead of the Baseline Start, then it will be positive, whereas if behind the Baseline Start, it will be negative. Number2: [Baseline Duration]/480 This will hold the Baseline Duration of the task. Number3: IIf([Number1]<=0,0, IIf([Number1]>=[Number2],100, IIf(([Number1]<[Number2]) AND ([Number2]>0), [Number1]/[Number2]*100,0))) This custom field holds the main algorithm and uses the IIf() function of MS Project. The algorithm is built on explanations given in the first video. Step – 5: Format Planned % Complete Finally, we will convert the Number3 custom field into a Text one. I’ve used the below formula for the Text1 custom field: Text1: cStr([Number3] & “%”) We need to concatenate the string value of Number 3 with “%.” The “Text1” custom field also has to be renamed as “Planned % Complete”. After you have populated the custom fields with the above formulas, you’ll see the below. Let’s interpret the above figure: The status date is set as Sept 12, 2022. For Phase – 1: All tasks (work packages) are planned to be completed by the status date. Hence, these are shown to be 100% complete. The cumulative planned % complete for Phase – 1 is at 100%. For Phase – 2: “Work Package A2” and “Work Package B2” are planned to be completed fully. Hence, these are shown as 100%. The status date is 1 day into “Work Package C3,” because it starts on Monday, Sept 12, 2022. Hence, the planned % complete for this task will be 1/5 = 0.2 or 20%. The cumulative planned % complete for Phase – 2 is at 55%. The cumulative planned % complete for the entire project is 77.5%. Planned Vs. Actual Percent Complete Now that we’ve walked through how to calculate and use the Planned % Complete, let’s look at it alongside the Actual % Complete column. As noted earlier, “% Complete” in MS Project informs on the actual percentage completed for a task. To show both, I’ve added one more column into the tabular side of the Gantt Chart, as depicted below: I’ve renamed the title field for “% Complete” by going to the Format tab > Columns group > Custom Settings, and executing the “Field Settings” command. As we track the project’s progress, both planned and actual percent complete fields will populate, respectively, as shown. Let’s interpret the above figure: The status date is again on Sept 12, 2022, when we started tracking. For Phase – 1: As on the status date, Work Package A1 and B1, as well the Milestone “Phase -1 End,” are actually complete, and, hence, are all showing to be at 100% completion. Work Package C1 started on time, but took 2 more days to complete. Work Package D1 has seen 2-days’ worth of work, but has 4-days remaining. While the actual % complete is 2/6 or 33%, the planned percent complete is 100%, as we have seen earlier. The cumulative actual % complete for Phase – 1 is 83%. For Phase – 2: Work Packages A2 and B2 are at 75% and 50% actually completed. Compared to the status date, the planned percent complete is 100%. Work Package C2 has seen 1-day’s work and still has 6-days of work remaining. Hence, the actual % complete is 1/7 or 14%, whereas the planned % complete is 20%, as we have seen earlier. The cumulative actual % complete for Phase – 2 is at 33%. The cumulative actual % complete for the entire project is at 58%. On the other hand, as seen earlier, the cumulative planned % complete is 77.5%. More on Planned % Complete There are certain scenarios where ‘#ERROR’ notifications are shown in the MS Project software. These confound many MS Project practitioners, and I felt that exploring a few such scenarios would be best done in the below video [Duration: 6m:07s], which I’ve created for this article. The scenarios explored are: No Status Date, No Baseline, Addition of New Tasks and Re-baseline.     Creating Histogram – Planned Vs. Actual % Complete So, what do we do with the data? MS Project comes with a large set of built-in reports, as well as allows you to create your own customized reports. Let’s create a histogram to show the Planned vs. Actual % Complete data to a customer or stakeholder. Create a custom Histogram Report by going to the Report tab > New Report > Chart, as shown below. Select the custom field related to Planned % Complete and the already available field of (Actual) % Complete in the “Field List.” The histogram report will show both these fields in its report. With a little bit of further customization, labelling, axis value population, and formatting, the histogram report will come out as shown below. References: [1] Online Course: MS Project Live Lessons, by Satya Narayan Dash [2] Documentation: Project Functions for Custom Fields in MS Project, by Microsoft Corporation.

The Rhythmic Dance of Agile with Cadence

Odissi is one of the classical dances of India from the coastal state of Odisha. Based on archeological evidence, it’s possibly the oldest living classical Indian dance. The Massachusetts Institute of Technology (MIT), US, notes in its web-archives that Odissi is two to three thousand years old. In recent decades, it’s been popularized by well-known artists—one being singer, Michael Jackson. In his famous 1991 song, Black or White, Jackson danced a fusion of Odissi and pop-rock, with his companion dancer, on the highways of the United States. A unique dance position in Odissi is “tri-bhangi” (‘tri’ meaning three and “bhangi” meaning stance or position). Together, loosely translated, it means “thrice deflected stance,” and is quite difficult to master. In this position, there is a three- or tri-fold shape in the body forming an S-curve. To get into this stance, the upper part of the body such as head and hands are rhythmically moving in one direction, while the middle and lower parts of the body move in other directions with different rhythms. The joy of the dance for the viewer and performer alike comes through, in that parts of the dancer’s body are moving in rhythm, as well as the entire body moving, at large. Now, you might be thinking what exactly a dance has to do with cadence in Agile? Let’s start first with the definition of cadence. Cadence – Definition and Basics One can define cadence in Agile as follows: Cadence is a regular, predictable pattern of development work in Agile. It’s timeboxed and comes with consistent duration to help scheduling.   Simply put, cadence is a rhythm of execution. The concept of cadence in Agile is suitably explained with a dance. With dance, art meets science, and in the same way, management meets life. Like dance, cadence creates a predictable pattern of work or rhythm of execution. Also, like dance, which can come with different rhythms for the different parts of the dancer’s body, cadence can be different for the different practices of Agile development. For example, you can have one cadence for Agile planning events, a separate cadence for Agile demonstrations or reviews, and a completely different cadence for Agile retrospectives. You can also have a single cadence for all events, for example, every two weeks, you may have planning, demonstrations, and retrospectives. We will explore a number of such situations shortly. Taking another example from our own human bodies, many organs function in various cadences. For example, our heart beats on a cadence, our breathing or respiratory organ works on another, and so on.  In fact, if these vital organs of the body don’t operate on their respective cadences, life won’t exist! That said, let’s explore how cadence can be applied in various Agile frameworks. Working with Single Cadence We have learned before, there can be two Lean-Agile frameworks at a high-level: iteration-based and flow-based. Irrespective of the type, cadence can be applied to development effort. In iteration-based Agile, such as Extreme Programming (XP) or Scrum, an iteration length is prescribed. For example, in Scrum, where an iteration is called Sprint, the iteration length is usually less than a month (four weeks) as per my article on the latest Scrum Guide, 2020, and it’s always timeboxed. When you keep the length of the iteration fixed over a period (and it is a good practice to do so), you develop a cadence. As we saw in our initial definition, it’s a predictable, regular pattern or rhythm of execution. When the iterations are repeated consistently over a period, a cadence is formed. In other words, in an iteration-based Agile, cadence is created with iterations, as depicted in the below figure. Considering Scrum framework, the cadence is timeboxed, usually from two to four weeks and is created by a Sprint. Within the Sprint, you have a cadence, and it is a single one. When we modify it for Scrum, the figure will change to what is shown below. Working with Multiple Cadences Whereas in iteration-based Agile, the cadence is formed by iterations; in flow-based approaches such as Kanban, timeboxing is not prescribed. However, you can apply cadence here, too. You can choose when you do planning, when to release, and when to do a retrospective. You can decide on a set basis, such as a release every Friday, or you may choose an on-demand basis. It can also be based on when there is something valuable to release. Below is an example of a team working with three cadences. As shown above, we have: Every week the team releases whatever is ready for release, Every second week they have planning, and Every third week, they have a retrospective. Working with Event-Based Cadence A project manager could develop cadence based on events, as well. This approach is employed in flow-based Agile or, if the stakeholders decide to do so, in an iteration-based Agile. Below is a case depicting that. A planning meeting is started when the team runs out of items to complete. A release is triggered whenever the team has a set of features ready. A retrospective is done every two to four weeks. Looking at the above figure, one could say that these are the event-based cadences: Planning Cadence: A planning meeting is started when the team runs out of items to complete. Retrospective Cadence: A retrospective is done every two to four weeks. Release Cadence: A release is triggered whenever the team has a minimally marketable feature (MMF) and/or subsequently, a set of releases Cadence and Intensity of Work We know that an alert and healthy staff will always be more productive than if folks are tired or burnt out. For that, a sustainable pace is needed. However, in sequential/waterfall development model, this is not always the case. Many times, it has been found that teams really can’t or don’t work with full productivity at the beginning of a project, especially, and it’s likely that they will start spending long hours and sleepless nights towards the end. In other words, the intensity of work goes-up towards the end of the project. Note the depiction of this in the below figure. This late work towards the end of a project is known as death march, and it refers to the burnout and exhaustion of the team members. Obviously, this type of late work can lead to high attrition and the loss of talented resources. The Agile framework intentionally tries to put a stop to this risk. Hence, one of the principles of Agile Manifesto reads as: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. With short iterations, intense work doesn’t peak towards the middle or end of the project, but remains steady throughout the project’s life cycle. This is because a project consisting of multiple iterations, will have similar intensity densities. Cadence – Advantages There are many advantages of cadence, some of which are: It is easier for project managers to manage with an understanding of cadence in place. Imagine having twenty planning meetings for twenty iterations; with iterations operating at one-cadence, scheduling becomes less challenging. It builds muscle memory. When you have a rhythmic set of activities, it builds familiarity, and keeps the mind free of trivial (but, needed) details. When the mind is free of such, time is better spent on value-added work. There is a big reduction in coordination, which is an offshoot of the first advantage. Some critics of Agile say there is a large overhead involved, due to the need for coordination with short iterations. With cadence, this overhead is guaranteed to be less. Scaling the effort of Agile becomes easier. In scaled approaches, it’s usual to see multiple teams operating at the same cadence. Even if an iteration is cancelled or abnormally terminated, recovery is possible by going back to the cadence. As we saw earlier, with right cadence, the intensity of work remains even throughout a project. More on the Topic of Cadence As we reach closure of this article, I want to summarize the concept of Cadence used in flow- or iteration-based Agile with a video. It’s taken from ACP Live Lessons course. [Duration: 4m:26s]. This video uses a real-world example to explain the concepts I’ve written about above. For a better audio-visual experience, you may want to go full-screen with HD mode and plug-in your earphones.   Conclusion The classical dance of Odissi starts with a solo form of pure-dance, where the performer emphasizes the execution aspect. It’s about knowledge, skills, dance patterns, and execution. The dancer, at this stage, excels with pure technical performance. In Agile methodology with daily cadence, the emphasis is also on execution–a bit of planning, a bit of design, a bit of development, a bit of testing, a bit of integration–daily. The individual developer is primarily involved in this technical work. After the start, highlighting technical skills, we see the Odissi performer dancing with emotion, communicating feelings, and expressing nuance. Multiple dancers often come together at this point in the performance. In the context of Agile, within iteration (or flow) cadence, individuals come together to decide which items will be taken-up as they interact and communicate. Next in the Odissi dance, it’s about group performance, or a team delivering together (i.e. they work on the whole drama part of the dance with a story). Similarly, in Agile, as the team comes together, delivery is made in release cadence. This can be after multiple iterations, every iteration, or on-demand. In most cases, these releases are given to the customer. Finally, when pure-dance and dance with emotions combine with group-dance and delivery happens frequently, the Odissi dance becomes something else entirely. It is climatic, liberating, and often even stunning when this occurs. This stage is known as Mokshya in Odissi, meaning liberation or freedom. In Agile parlance, this stage will be called a hyper-performing team, and it delivers highest-valued deliverables frequently, without interruptions. The team performs as a single, immutable unit, giving hyper-performances. While doing so, a constant pace can be maintained indefinitely. This is the essence of cadence.   * The opening photo of Odissi dance is by Bijay Biswal, who graciously agreed to share his ball-pen painting for this article. — This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away two years ago on June 11. He, along with my mother, introduced me to Odissi dance, taught me the importance of dance and music in our daily lives. It’s a tribute to them and their teachings. Men and women around the world have kept alive various forms of dance, which calms our minds and nourishes our souls. I take a bow.   References: [1] Online Course: PMI-ACP Live Lessons – Guaranteed Pass, by Satya Narayan Dash [2] Online Course: PMI-ACP 21 Online Contact Hours, by Satya Narayan Dash [3] Book: Kanban and Scrum, Making the most of both, by Henrik Kniberg and Mattias Skarin [4] Book: I Want To Be An ACP, the Plain and Simple Way to be a PMI-ACP, 2nd Edition, by Satya Narayan Dash              

Top Frustration #2: End to End Risk Management

Imagine you are managing a large project, which is strategically important and complex. At the outset, you realize there will be a number of risks, which if not managed well, could paralyze the outcome and have negative impacts on the project objectives. You want to proactively identify, analyze, respond, track, and monitor your project’s risks. And, it would be great to have a dedicated risk management tool to use alongside your project management software. What are your options? Will software tools like Excel help? Will a software tool for only project management meet your needs? If you have ever managed risks, you know a spreadsheet is not the answer. A spreadsheet is not at all designed for project management–let alone risk management. It’s likely that a project management software tool only meets your need half-way. Recently, the MPUG team conducted a survey on the most frustrating experiences faced by management practitioners with respect to software tools and one response was related to risk management and tracking, specifically in a scenario where spreadsheets were being used. Another aspect that came to light was the need for an integrated and risk-adjusted schedule-cost management system, which brings up questions like: what are the duration estimates and cost estimates associated with the risks? How can a PM manage risks in with a single, centralized tool? In this piece, I’d like to present an integrated approach to project management with strong end-to-end risk management capabilities. For this purpose, I’ll be using two software tools: Microsoft Project (MSP) 2019 for project management, and Primavera Risk Analysis (PRA) 8.7.5 for risk management. The practical examples and samples for this article have been taken from Practical RMP with Primavera Risk Analysis, whereas the theoretical explanations are from RMP Live Lessons. Let’s start with creating a project plan with MS Project. Create the Project Plan While you can directly use PRA to create your project plan, most project managers use MSP frequently for planning because of its simplicity, ease of use, and user friendliness.  For this reason, we will create the plan first in MS Project. The plan depicted in the below figure. The statistics of the project are these: Duration: 38 days Cost: $67,680 USD Finish Date: June 30, 2021 (06/30/21) The project is the creation of a Smart Site and involves multiple resources. Do note that if you have modified the calendars for the project and/or have added custom calendars, you’ll need to ensure you have the corresponding calendars in PRA. Set-up PRA for Risk Management Before importing the plan, ensure that the settings for MS Project in PRA are correct. This can be opened by going to PRA tool’s File à Microsoft Project à Edit Default Import Mapping… menu. Keep the “Show this dialog…” checkbox enabled so that when you open the MSP Plan in PRA, you can have a quick look at the settings before actual import happens. Import the MSP Plan into PRA Now that we have set the MSP related settings in PRA, we will import the project plan created in MSP into PRA. It will happen in a few seconds. Post import, in PRA, the plan will be shown as below. The imported project plan in PRA has the following statistics: Remaining Duration: 38 days Remaining Cost: $67,680 USD Finish Date: June 30, 2021 (06/30/21) This is perfectly in sync with the statistics of our project plan created earlier in MSP. It’s also a good idea to check a few of the tasks in the project to see that the import has happened properly. In our case, the task/activity “PRD Preparation” has been considered. It matches perfectly with the MSP Plan considering Dates, Resources, and Cost, among other fields. Important Notes At this stage, I’ll recommend that you read this Risk Management Framework for Projects article to understand how risks are managed and monitored over various Risk Management processes. Here, I’ll be using only the Risk Register, not the Risk Report. In addition, I’ll explain some key points with respect to risk management, which will help you to understand why I’ve taken the following steps and performed the associated activities. Take a look at the video [Duration: 4m:12s] below—it’s been taken from RMP Live Lessons. For a better experience, you may want to go full-screen with HD mode and plug-in your earphones. Risk Identification and Risk Register Now, we are going to prepare the Risk Register. Preparation of this key project artifact happens during the Risk Identification process. To create the Risk Register with PRA software, go to Risk à Register… menu, or click on the Risk Register icon on the Risk Toolbar of PRA. The Risk Register creation dialog box will pop up, and we will use the standard risk register option. When the standard Risk Register first opens, of course, it will be empty as shown below. You can enter new risks easily by adding details for the identified individual project risks. As you can enter the risks, provide all the needed information such as Risk ID, Threat or Opportunity, Risk Title, the Pre-mitigation information such as Probability scales, Impact Scales, etc. You can also add the Risk Details such as Cause, Effect, and Risk Category, among others. As shown, we have four identified risks (threats) for this project with their respective details entered. The cause, effect, description, owner, RBS type, and status values have been entered for each of the risks. Do not worry about the risk responses now. We will address them in the step for risk response planning as I explained in the earlier video. The risk score is calculated by taking the risk parameter values from the Risk Probability and Impact (PI) Matrix. For the sake of this example, I’ve used the following matrix. The probability and impact scales notations in the Risk Register are these: Very Low (VL) Low (L) Medium (M) High (H) Very High (VH) As you multiply the probability and impact values, you will get the Risk Score. For more depth, refer to this detailed article on Risk Matrix Reporting. Risk Qualification Our next step is to qualify these individual risks. We will determine the probability and impact values of these risks. You can have other risk assessment parameters, as well, such as Risk Manageability or Risk Proximity, among many others. Considering the probability and impact values of these risks, as we qualify them, the Risk Register will be updated as shown below. As you can see, the current Risk Register has seen a number of updates. Considering Risk ID – 001, some of the key updates are: Risk Score is now 21. (change from 72 to 21) Risk Owner is confirmed. (John R is the confirmed owner) Risk Status has been modified. (Status is “open” now; earlier “proposed”) Similarly, we have also qualified other individual project risks: Risk 002, Risk 003, and Risk 004. Risk Quantification This step of risk quantification is optional, as we have seen in the RMP video. Though our project is a simple one, let’s do risk quantification for one individual risk (Risk 001: Poor understanding of design specification). After quantification of this risk, the pre-mitigated Quantified Risk Register will show as follows: Note that Risk 001 has now been quantified from a schedule perspective by associating it with two tasks in the Project Plan, i.e. Task ID 000009 and Task ID 000010, from “Phase – 1” under the WBS element of “Design and Development Phase” at Level – 2 of the work breakdown structure (WBS). I’ve used BetaPert probability distribution for the tasks mentioned and have entered the minimum, mostly likely, and maximum duration estimates. Similarly, you can also quantify with respect to cost estimates. Post quantification, you can do a variety of analyzing such as: Monte Carlo Analysis, Criticality Analysis, Probabilistic Branching and Analysis, and Sensitivity Analysis, among many others. Risk Response Planning and Response Integration Next, we will do the risk response planning for the individual risks to bring down the probability and/or impact values of these risks. With this, we can keep the risk score within the risk threshold. For this purpose, we again have to go to the Risk Register and modify the risk response strategies along with the associated risk response actions. The modified risk register is shown below. Considering “Risk 004: Key resources unavailable,” the Risk Score has been reduced from 56 to 1, and similarly for certain other risks. For Risk 004, the associated actions are noted under the highlighted “Mitigation” tab. There are two mitigation response actions: Risk Response Action – 1: Get the resources from other functional departments. Risk Response Action – 2: Prioritize project resources. The assigned risk response owners and associated cost are noted. The associated cost also reflects on the top panel for Risk 004. Risk Monitoring and Tracking Our final step relates to risk monitoring and tracking. During risk monitoring, new risks may be identified, an existing risk status can change, an existing risk can become obsolete, or an existing risk may not occur. Let’s say a new positive risk (opportunity) is identified, and we need to add this risk into the register. As we have seen earlier, risk management is both iterative and integrative in nature. As shown, we now have a new risk—“Risk 008: Reuse of previous design module.” As this risk is freshly detected, default values have been populated. The blue letter “O” represents an opportunity. Subsequently, we have to determine the initial characteristics of this risk, followed by qualification and quantification (optional), and have the needed risk response strategies with associated risk response actions. Finally, we have to monitor this new adjusted risk with response and associated actions. As we reach the end of this article, some of you may be thinking can this risk register be exported to MS Excel? After all, not all stakeholders will have MS Project 2019 and Primavera Risk Analysis software installed. The answer is yes! You can export the Risk Register to MS Excel by going to Risk Register’s File à Export Risk Register As… menu. From there, while saving, choose “Microsoft Office Excel (.xls)” option to save. With this process in mind, I believe you will have a sound understanding of end-to-end risk identification, analysis, response planning, and implementation, followed with risk monitoring and tracking. References: [1] Online Course: Practical RMP with Primavera Risk Analysis, by Satya Narayan Dash [2] Online Course: RMP Live Lessons, Guaranteed Pass, by Satya Narayan Dash [3] Online Course: MS Project Live Lessons, by Satya Narayan Dash

Enterprise Risk Management (ERM) and Risk Governance

Let’s consider the following scenario based true events which occurred within an organization I worked closely with recently. This company had a long-running project with a number of uncertainties. Risks were identified, then qualified, and risk responses planned. For implementation of these risk responses, a number of actions were needed. Some were taken, but most ignored or overlooked because of other projects and lack of understanding of risk management at an organizational level. I came to know that there were no consistencies within risk governance parameters, such as risk appetite, or risk threshold, for example. In fact, there was no structured and uniform way to define the probability and impact scales, no standard form of risk reporting, and little to no accountability for addressing risks. Hence, when risks were reported, team members didn’t understand, or if they did, they wouldn’t know how or whether to act. What happened? As you may have correctly guessed, this project was in trouble. And, despite, it continued to run for a long time! It was a classic watermelon project, where everything looks green from the outside, but is all red when you open it. In this article, we will explore how to manage such massive gap at an organizational level considering Enterprise Risk Management and Risk Governance. If you are preparing for the Risk Management Profession (RMP) examination, you need to be aware of both these concepts. In fact, in a recent RMP Success Story, a senior program management professional emphasized it.   What is Enterprise Risk Management? Projects can exist independently, but usually they exist within a program or a portfolio, which in turn are held within an enterprise or organization. In most cases, such is the case for a program or portfolio. Hence when we talk of risk management, we also need to know how risk management happens in the context of enterprise: It has been found that organizations require risk management practitioners to use the risk management practices in project, program, and portfolio management, which are an integral part of the ERM framework. In other words, ERM addresses risks at an enterprise or organizational level. ERM also addresses all the risks associated with an enterprise’s portfolios, which internally contains all programs and projects. A “Risk Governance Framework” for an organization is set at the enterprise level. There is a governance board which oversees the ERM and its framework. On the other hand, portfolio risk management derives its policies, processes, methods etc. from the ERM framework, and program risk management, as well as project risk management, adopt their risk management practices from the portfolio risk management umbrella.   Why Go for Enterprise Risk Management? Enterprise risks are also known as the business risks, and organization leaders must manage these to stay relevant and stay in the business. Typically, an organization runs many individual departments such as Development and Delivery (or Production and Distribution), Finance, Human Resources, Sales and Marketing, Legal and Compliance, among others. All these functional departments may have their own risk management as shown in the below figure. If the risks arising within these departments are managed individually, without a holistic or overall view of the risks from the organization’s perspective, the result is siloed risk management.   PPP Approach to ERM Alternatively, organizations can take a common approach to risk management across the organization or enterprise, considering all the departments. In a projectized organization, ERM will consider all layers of management – project, program, and portfolio (PPP). Portfolios of programs, projects, and operations are created to achieve strategic goals and objectives. In other words, portfolios are created to achieve an organization’s strategic goals and objectives. A portfolio internally contains programs and projects. Considering PPP based management approach, the following should be noted about ERM: Enterprise risk functions and management are performed by the Executive Management. The ERM process is also determined by the Executive Management. Best suited to handle ERM, the Executive Management is accountable for strategic goals and objectives. Based on this understanding, we follow the below figure: As shown, ERM supports an organization’s vision, mission, goals, and strategies. In fact, this support is the main objective of the ERM.   ERM Considerations for PPP Based Risk Management ERM ensures that all organizational risks are properly identified, addressed, managed, and monitored. However, for the best application of ERM, a common approach to risk management is needed. This is because ERM should be considering all of the organization’s risks as an interrelated collection. A common approach to risk management enables two things: Normalization: The risk prioritization schemes, risk probability, and impact scales for the risks are standardized across the board. Aggregation: Aggregation results in a combination of a number of risks coming from the portfolios of programs and projects. With normalization and aggregation, one can state the risk at any level in the organization, making it understandable to everyone. There can be bi-directional movement and management of risks, or a cascading of risks from a higher level to PPP level or escalation from the lower level to the enterprise level. Hence, modifying our previous figure with respect to layers of risk management, we can consolidate and present as the below figure. This bidirectional movement of risks, results in integration, as well as alignment of ERM and PPP risk management.   Governance and Its Elements Governance, as the name indicates, is the way to govern an “entity.” The purpose of governance is to ensure that the “entity” is managed in a proper way. Governance can exist at the level of enterprise/organization, portfolios, programs, or projects. In such cases, they will be known as respective governance or governance framework. The governance framework is part of governance. The major elements of an entity’s governance are these: The Governing Body is a temporary or permanent group of members with responsibility and authority. This body provides the needed guidance and decision-making for portfolios, programs, and projects. An example is an executive board. The Governance Framework contains governing domains with functions, processes, and activities for projects, programs, and portfolios. Examples of domains are governance communications, governance performance, The Governance Domain refers to a group of functions carried out by an individual, group, or organization to address a specific area of concern. For example, the governance communications domain is about dissemination of information. Governance Functions are a group of related processes executed/performed to support the governance of portfolios, programs, and projects. The elements and interactions among the elements of governance are shown in the below figure. Types of Governance There can be various types of governance such as organizational governance, portfolio governance, program governance, etc. at the respective levels. Organizational governance is a structured way to provide governance at the organizational level. The focus is to meet organizational strategic and operational goals. Portfolio, program, or project governance refers to the framework, functions, and processes that guide portfolio, program, or project management activities, respectively.   Governance Vs. Management At this point, you may be wondering: What are the differences between governance and management? Does not the portfolio, program, and project management exist to guide the respective management activities? If so, why is governance needed? Yes, portfolio, program, and project management will still exist, but when it comes to governance there are some key distinctions, which can be summarized by this line. Governance informs the “what” aspects. Management, the “how” aspect. The “what” aspects are about decisions, guidance, and ensuring PPP management. The “how” aspects are about organizing and doing the work. Beyond the above key difference, I’ve noted some more differences between governance and management in the below table. Risk Governance With this background in mind, let’s now consider risk governance and the risk governance framework. Risk management in the enterprise context is primarily about enterprise risk management (ERM), and it involves an integrated view of portfolio, program, and project management. In this organizational context of risk management, these are the key points related to risk governance: Risk governance is created, and the risk governance framework is also elaborated. Remember that the governance framework is an element of governance. Within this framework, risks are identified at each level, i.e., the enterprise/organizational level or PPP. Identified risks are analyzed—both qualitatively and quantitatively. Then, the best suitable governance layer is decided. It can be the portfolio governance layer, program governance layer, or project’s governance. It’s possible that at each level of PPP governance, one can have a risk governance model, which is part of the corresponding P’s governance. For example, within the project governance, one can have project risk governance. The respective governance layer decides on the escalated risks and what to do with them. Enterprise risks can be cascaded down to the respective suitable layer, if they can be managed at that level. As we have seen earlier, there can be bi-directional movement of risks in an organization. Risk governance, at the chosen layer, guides in identification and assignment of risk owners. Next, it’s responsibility of risk owner to delegate risk actions to respective risk action owners. Risk governance, at the chosen layer, guides on risk response strategies and risk response actions, which are associated with the response strategies. Risk governance, at the chosen layer, also decides on the continuance or termination of a portfolio, program, or project.   Video – Risk Governance Vs. Risk Management   Now, let’s look at the differences between Risk Governance and Risk Management. For this purpose, I’ve put together a video [duration – 8m:36s], with additional explanations. For a better audio-visual experience, you may want to go full-screen with HD mode and plug-in your earphones. It’s one of many, from my RMP Live Lessons. Conclusion Let’s revisit the scenario explained at the beginning of this article, where a project had been running without any proper risk management. If you’ve watched the aforementioned video, you should be able to answer the following questions: How did the ‘watermelon’ project exist? Why was it running for a such a long time with little or no risk management? How come no one was held accountable for it? More importantly, I hope you have realized the importance of both Enterprise Risk Management and Risk Governance. I welcome your feedback below in the comments section.   References: [1] Online Course: RMP Live Lessons – Guaranteed Pass, by Satya Narayan Dash [2] Online Course: RMP 30 Contact Hours, by Satya Narayan Dash [3] Book: I Want To Be A RMP, The Plain and Simple Way To Be A PMI-RMP, Second Edition, by Satya Narayan Dash [4] The Standard for Risk Management in Portfolios, Programs and Projects, First Edition, by Project Management Institute (PMI)    

Troubleshooting in Lean-Agile Development

Many project managers utilize a Lean-Agile approach when there is high change or churn in project requirements, significant lack of clarity in scope, high complexity to their projects, and/or a larger number of risks associated with such. As these approaches have gained wide acceptance in a number of industry verticals, there has also been an increase in the problems being reported. In this article, we will explore some of the practical problems faced by Lean-Agile practitioners during development of a new product or service and/or the building of a solution. When facing these challenges, Lean-Agile approaches have certain inherent or built-in mechanisms and execution best practices. At this stage, I want to inform that problems and subsequent troubleshooting challenges the occur in a Lean-Agile approach can be divided into two broad categories: Iteration-based Flow-based Two Lean-Agile Types Earlier, in one of my articles, I had mentioned that Agile is both iterative and incremental in nature. We also previously explored the differences between iterative and incremental development with an example. I’m using the Lean-Agile approach here because many aspects of Lean are becoming increasingly a part of Agile (i.e., pull system, just-in-time planning, flow, visualization, waste elimination, error-proofing, and small batch-size, among others). When I referred to the two Lean-Agile types, the categorization is based on an incremental delivery aspect. Let’s understand these two types a bit more. Iteration-based Lean-Agile In this type, the iterations are prescribed. Each iteration is timeboxed to the same size. Each timebox results in a working a set of tested features. The team pulls the item from a backlog of features, decides which can be delivered at the end of an iteration and usually provides an increment at the end. An example of this type can be the Scrum framework. As shown in the above diagram, we have a number of iterations, and each iteration length is timeboxed to the same duration. Flow-based Lean-Agile In this case, the iterations are not prescribed. Rather, the emphasis is on flow while having incremental delivery. The team pulls item from a backlog of features based on their capacity, and it’s not based on an iteration timeline. When the feature is complete, it can be delivered. It’s usually based on a cadence. The number of features that can be taken on is based on a work-in-progress (WIP) limit. An example is the Kanban method, which has its original roots in Lean manufacturing. As shown in the above figure, there is no regular timeboxed iteration, but incremental delivery can happen in cadence. With these fundamentals in mind, let’s now explore the problems faced by Lean-Agile teams. In some cases, I’ll be using the terms Agile and Lean-Agile interchangeably. When the Product Owner is not Available Full-Time for the Team This problem is predominantly seen in geographically distributed teams, where developers are working in one continent, but the product owner (PO) is operating from another. The product owner, while closer to the market, manages multiple products. This results in constraints because the PO is not fully dedicated to one team or present with them. Any Lean-Agile team needs strong product ownership. This is crucial for the success of the team and the product being built. The PO needs to be committed to the long-term objective(s) of the product (Product Goal or Vision) and continuously participate in the team’s project activities. To resolve the problem of a PO being only partially available for the team, ensure that the PO is full-time, irrespective of the size of project or his/her location. An absence of this can lead to handicapped team performance and may even little value delivery. To reaffirm, one of the principles of the Agile Manifesto is: Business people and developers must work together daily throughout the project. The PO can be the business owner or in some other structure, the PO can be paired with the business owner directly or via the Agile Project Management Office (PMO). Nevertheless, the PO should be involved daily with the team members, not on a part-time basis. The PO is the team member who is responsible for the business success of the product. He/she is also accountable to the business. When There is too Much Complexity in Product Architecture As noted in the beginning, Agile approaches are designed to tackle complexity, but sometimes project complexity can be too high and one may not know where to begin. In such a case, one can use: The concept of Sashimi, or Take a tracer bullet approach Sashimi is a Japanese word particularly used within the context of food. In Japan, a delicacy is thin slices of raw fish and sometimes served with rice—it’s called Sashimi. Each slice of fish is complete in itself, as well as tastes similar to other slices. This concept can be applied in Agile. When using Lean-Agile approaches, we develop functionality that cuts across all the layers of a product, which has multiple layers – say front end, middleware, and backend. We are not developing the backend first, or the middle part or frontend. Rather, we deliver functionalities by cutting across all the layers. The tracer bullet concept is based on the idea of firing in the dark! When you fire a gun in the dark, it’s difficult to aim due to the lack of light. However, when the path of a bullet is lit up (tracer bullet), you can see the trail and use it to inform your next aim. In other words, the tracer bullet helps to improve your aim for subsequent firing. You can say, a tracer bullet of functionality is very similar to a Sashimi approach. We see the path of a bullet passing through all the layers or a functionality consisting of all the layers of a product. We are shown the path to build other functionalities. When Inaccurate Estimation Results in Delayed Delivery This is another problem frequently seen irrespective of industry verticals. Developers, with all due respect to them, are generally optimistic people. The trouble is that when there are high uncertainties or complexities in a project, optimism may not be your best friend. Estimates are often inaccurate because they are made in absolute numbers. For example, it will take five days to complete a feature/backlogged item or six hours to complete an activity. One way to resolve this challenge is to use story points for estimation. Story points are relative estimation techniques and have unitless measure. Story points are relative estimates because they compare size, complexity, difficulty, and risks among other items being estimated. To utilize story points, estimate the tasks (i.e., stories decomposed into tasks) into ideal hours. While the usual time unit used is eight hours a working day, it’s not always the case because of other activities such as meetings, unforeseen customer escalations, and interruptions, among others. When estimating using ideal hours, the time consumed for all non-productive, but necessary work is not considered. This is depicted in the below figure. Ideal hours are considered here to be four/day. When Backlog Items are Insufficiently or Improperly Refined Backlog refinement is a common practice and widely used in both iteration- and flow-based Lean-Agile types. The team starts off on the iteration or can take the item to the flow of work. Let’s consider an example of an unrefined backlogged item: As a user, I can manage my settings, so that I’ll have the latest information. This is not exactly a small user story, but a very big one. In fact, this story can be decomposed further into three: As a user, I can manage my address details. As a user, I can set or reset my password. As a user, I can set my email preferences. The address part alone comes with multiple parts, and a user has to utilize multiple operations to manage it. For example, add, edit, and delete. For this purpose, the product owner or product manager needs to have a good understanding of (user) stories, as well as refinement techniques. To address this issue of improperly refined backlogged items, one can use the Definition of Ready (DoR) skill. Definition of ready is a checklist, which needs to be checked off step by step to see if the team has all the needed information before working on the item. DoR can be used before the beginning of the iteration or before taking a work-item into the flow of work. When a Deluge of Defects Occurs There are many scenarios in which this can happen: Team is new to development The team has a lack of strong engineering practices, among others. When the team is new to Lean-Agile development, it’s always a good idea to have training to understand the values and principles of Agile. The most difficult part, however, is the internalization of these values and principles (i.e., applying them daily during the project work). With a correct Agile/Lean coach, this understanding will be needed to sustain the project. In addition, good engineering practices are not only necessities, but vital to stop deluge of defects and provide good-quality products. Some are noted below. High test coverage and testing at all levels: You can implement high test coverage both at the system level, as well as unit test level, with automated test cases. The team should have testing at various levels, such as: Unit testing: Testing done at the lowest level. System testing: End-to-end testing of the full system or product. Smoke testing: Lightweight testing to ensure workability of the most important parts, and others such as black-box testing and regression testing. Refactoring: Many associated refactoring is done within the context of software, but it can very well be applied to any product work. In fact, it’s a product quality technique with which you improve the design of the product through maintainability, but without changing the external behavior. Simply put, with refactoring, you can change the internals of a product without changing the external behavior. With continuous refactoring, technical debt (i.e., legacy debt due to deficiencies in design, documentation, code (or product work), associated third party tools) is gradually reduced and defects are kept in check. Continuous Integration: Any (product) increment given at the end of the iteration or continuously as in flow-based Lean-Agile, should be incorporated into the whole product. Post integration, the product still should work as intended. Test first, develop next: In XP lingo, it’s called test first programming and in common Agile parlance, one can call it test-driven-development (TDD). Automated tests are written before doing the product work or creating the product. Next, work (or coding is software) is done to meet this test. This results in a built product with lesser defects. Collective Ownership: In XP parlance, it’s usually referred to as share code. This concept says that the product work is owned by everyone in the team. You can also say, product quality is everyone’s responsibility. When Rework or Incomplete Work Happens While working with an iteration-based Lean-Agile approach, an increment can be achieved on a cadence or on-demand. One the principles of the Agile Manifesto tells us this: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (or product). If increments are not being delivered early and frequently, then the main purpose of going with a Lean-Agile approach is lost. When the team delivers an increment, it must be fully “done” or complete. For this purpose, Definition of Done (DoD), an Agile artifact is used. Definition of done is primarily a checklist of items, which needs to be crossed-off, before a backlogged item or a story is considered finished. To have proper work completion, the DoD should be exhaustive and clear. A sample DoD is shown in the below table. Only when a backlogged item has cleared the checklist of items listed in the DoD, is the work considered to be complete. Within this context, the issue of rework and/or incomplete work is addressed. When Product Demonstrations or Reviews are Dysfunctional While retrospectives are considered to be the most important practice in a Lean-Agile approaches, a close cousin is the practice of product demonstration or reviews. This is a very important event because Lean-Agile is fundamentally about value delivery to customers early and frequently, getting feedback, and customer collaboration – all of which happens in a demonstration or review collection. While new teams can have failures during demonstrations, it’s also seen for experienced teams. Here are some situations that may occur: The (product) increment is not behaving as expected Features promised have been missing the demo The product crashes, or Worst of all – the PO and key stakeholders don’t accept the increment Multiple dysfunctional product reviews can have a serious impact on the trust customers have in the team and equally, the self-confidence of the team who is delivering. To resolve this challenge, several things can be done. Prepare early before the actual meeting: You should have a set of items or checklist of items prepared prior to the review or presentation. Not only should the team should take some time preparing for the meeting, but for an iteration-based type, they should use a checklist similar to the sample template below. Next, while running the meeting, document the decisions being made. This event, as noted before, also involves getting feedback from the customer/stakeholders and incorporating that feedback subsequently. With an eager clientele, a number of enhancements, new stories, or workflows will come up and it’s important that you note them. Towards the end of the meeting, ask for acceptance on the increment. The acceptance may be conditional or there may be a time lag, before formally being accepted, but do ask for this, as it allows the increment to be released. This also tells the team that the increment delivered has met the definition of done (DoD). Above all, never cancel the meeting. Sometimes it’s possible that you have very little to show or even that you know your product increment may crash. Still, go ahead with this event, as you will get feedback, and can make course corrections, if needed. — There are a number of problems or issues that can come-up while implementing a Lean-Agile development approach. In this article, I’ve outlined some of the challenges along with possible solutions. What are the problems that you face? What approaches do you take to meet these challenges? Let me know in the comment section below. References: [1] Book: I Want To Be An ACP, The Plain and Simple Way, by Satya Narayan Dash [2] Agile Practice Guide, by Project Management Institute (PMI)

The Value of an Agile Project Management Office

Imagine this scenario as you start off your day: You open your business site and the message says: “it doesn’t exist.” You then try to log in to your email account, which also displays the same message. Your heartbeat goes up and you rub your eyes in disbelief. You remember receiving emails from customers about payments via payment apps, but there too, the same message is displayed, “this account doesn’t exist!” Overall, you feel like the character of the 1998 movie, Enemy of the State. Is my imagination running wild? Not really. Such a scenario happened to many in mid-December 2020. A number of service providers’ sites and applications were hacked and systems were brought down. In fact, I thought my personal computer had been hacked, and I rebooted a couple of times without knowing what exactly to do because my service providers’ status dashboards were all green–a good 10 minutes into the internet outage. Now imagine that a senior executive starts off his day and decides first to have a quick look at the project dashboard expecting to see metrics such as the current status of projects, earned value indices in terms of money and performances, and top risks. Instead, he sees storyboards, iteration and release burndown charts, and velocity graphs. Can you feel the frustration, confusion, and possibly anger? What could have been done differently? Welcome to the concept of the Project Management Office or PMO. In this article, we will learn about PMOs as organizational structures, various types of PMOs, and traditional roles within a PMO. Then, we will dive into the topic of Agile PMO, its relevance, and a number of roles that can be played by such a PMO. What is a PMO Any organization exists primarily to provide business value to its stakeholders–internal or external. A PMO, like the service providers I mentioned in the example at the beginning of this article, also exists to provide value and insight into project performance. The Project Management Institute (PMI) provides a broad definition of PMO as: A project management office (PMO) is an organizational structure that standardizes project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques.  As noted in the definition, a PMO is an organizational structure. If it exists, then a number of Project Managers (PMs) can be a part with various roles and responsibilities. Do note that the “P” in PMO can stand for a project, program, or portfolio, and the “O” can refer to the organization itself. With a standardized set of processes, practices, and metrics, enabled by a PMO, the executive stakeholder would not have faced the “it does not exist” situation as previously mentioned. Types of PMOs As per PMI, there are three types of PMOs: A supportive PMO largely plays a consultative role such as providing templates, imparting training and coaching, and storing lessons learned across projects. A controlling PMO plays a role in project compliance to standards and/or regulations, and it ensures conformance with various governances and associated frameworks. It can also be involved in audits of projects and project works. A directive PMO exerts the highest power and has the ability to initiate and/or terminate projects in an organization. You can say, this PMO directly manages all of an organization’s projects. While the degree of control provided by the supportive PMO will be low, controlling and directive PMOs will have moderate and high degrees of control, respectively. Traditional Roles of PMO If a PMO structure exists in an organization, then the main role in a traditional set-up is to support the PMs. Beyond that, the PMO holds some or all of these listed responsibilities: Standardization: Standardization of processes, policies, procedures, templates, and other documentation, along with compliance. Knowledge sharing and retention: Acting as a repository of lessons-learned and providing access to projects as and when needed. Training: Facilitating or conducting, providing coaching, and mentoring. Consulting: Adopting various project management frameworks or methods. Resourcing: Managing shared resources across projects. Communication: Coordination communication across various projects. For a PMO, unlike a program or portfolio, it’s not necessary that the projects are related or managed as a collection. With this background, let’s proceed towards the concept of Agile PMO. The first question that comes to mind in having a PMO coupled with an Agile approach is this: Is a PMO really needed at all in an Agile setting? Are not Agile teams cross-functional, self-organizing, and self-managing? Isn’t there a leader who serves the team and removes the impediments? At first-glance, having an Agile PMO may look contradictory–not only to the way Agile teams operate, but also to Agile values and principles. However, it need not be the case. As noted in the definition, a PMO is an organizational structure. Your organization may or may not have such a PMO structure, but if your organization does and your organization is transforming itself to adopt Agile practices, then it must change to have an Agile PMO because agile creates structural, as well as mindset changes. Agile PMO Instead of a traditional directing or commanding/controlling PMO which first dictates and enforces standards, policies, procedures, an Agile PMO is more facilitative in nature. An Agile PMO takes the most effective practices used in other projects and shares them across the organization. An Agile PMO is useful when an organization is doing a transition to an Agile approach, and particularly can play a crucial role if the organization is planning to undergo an Agile transformation. In the context of Agile, PMOs will have the characteristics shown in the below figure: Let’s break these down one at a time. Value-Driven This is the most important aspect of an Agile PMO. The PMO’s goal should be to deliver the right value. An agile PMO should have a customer collaboration mindset. Customers, in this case, are the internal customers within the organization and can also be external customers. In many cases, this may result in PMOs working as a “consulting business unit” in an organization. The PMO can tailor their work to meet the customer’s need. For example, the PMO is responsible for providing the template for use story or the template for Product Review/Demonstration. Multi-Disciplinary An Agile PMO should have competencies other than project management, e.g., organization design, change management etc. Center-of-Excellence (CoE) With a plethora of Agile frameworks available, it’s easy to get lost in the woods. An Agile PMO deeply understands a variety of approaches available and can adopt or tailor the ones that best meet the organizational needs. Change-Agent An organization usually struggles while transforming to fully adopt Agile values, principles, and practices. It’s never easy to move into a different mindset and way of working. An Agile PMO acts as a change-agent and guide. Invitation-Oriented An Agile PMO invites for its services only the projects or project teams that are interested in PMO services. This kind of engagement ensures that the practices are followed vs. a PMO forcing its practices on teams. Roles Played by Agile PMO Let’s consider some of the roles played and responsibilities that can be taken up by an Agile PMO. There are many applicable roles here, and I’ve highlighted a few of them in the below figure. Let’s consider them one by one. Multi-project Management Whereas the Agile project manager is the obstacle remover for the team, many times an Agile PMO overlooking a number of projects is an obstacle remover for the program (defined as a collection of interrelated projects, sub-programs, and other works). At the level of a portfolio, which is a collection of programs, projects, sub-portfolios, and operations, the PMO can work on investment themes, i.e., which project to take on or invest in. Stakeholder Engagement In the beginning stages of an Agile transformation, it’s highly likely that there will be resistances to the changes being brought in. The PMO, in this case, informs, communicates, educates, and gets buy-in from the stakeholders having Agile mindset, values, and principles. Simultaneously, when a trial project is undertaken by an Agile PMO, the team members may not get the needed support from stakeholders across the organization. Here, too, an Agile PMO can help provide training to existing or aspiring POs, SMs, Agile PMs, and team members. Standard Development and Implementation Earlier we saw the roles played by PMOs in a traditional set-up. In the context of Agile, the PMO can provide: Templates for user stories, Tools to be used for wireframes, Samples for burn-down/up charts, Metrics to be used, among others… If different teams have different metrics, it doesn’t help the organization at all. Sometimes, teams may even inflate data to show they have done more than planned. An Agile PMO helps to standardize on meaningful metrics such as release burndown, cycle time, etc. Compliance and Audit An Agile PMO can act as the informant on compliance issues and/or amplify the teams’ external department needs regarding compliance. The Agile PMO, in this case, should try to be facilitative, i.e., listen to what is working for the team instead of dictating or directing. If it’s regulatory compliance, then the PMO can find ways to get it done, e.g., putting it as a backlogged item in the Product Backlog in collaboration with the Product Owner (PO). The Agile PMO, like its traditional counterpart, can participate in audits, which is basically to see if project activities comply with organizational, as well as project policies, processes, and procedures. An example is participation in Quality Audit. Resourcing In any organization, there will be critical resources, which are shared across Agile teams, e.g., architects, database administrators (DBAs), technical writers, etc. Sometimes, non-human resources have to be procured from outside, and these are used on a shared basis. An Agile PMO can work with the POs, Agile PMs, Scrum Masters (SMs), and Functional Heads to satisfy the need of such resources. The Agile PMO can also help in hiring resources and evaluating team members. An example is developing interview guidelines for Agile practitioners. Training, Coaching, and Mentoring Here the Agile PMO can act as a coach, trainer, and educator by themselves or by partnering (or coordinating) with the training unit of the organization or external training organization. The Agile PMO can conduct sessions on: Test Driven Development (TDD) Behavior Driven Development (BDD), Retrospectives and intraspectives, Story writing workshops, Story mapping workshops, Backlog prioritization, among others. Strategic Focus and Alignment In an Agile PMO setting, the product backlog is executed over a number of iterations or with a flow-based cadence in order to move towards the vision or goal of the product. This, in turn, is usually linked with the strategic objectives, mission, and vision of an organization. However, a large organization can have many initiatives with hundreds (or thousands) of projects running. In such cases, it’s possible to miss the strategic alignment for all projects in the organization. The Agile PMO defines and ensures a strategy deployment method. In addition, an Agile PMO can also have additional roles such as that of a traditional PMO—facilitating learning by storing, managing, and dispensing lessons learned from various retrospectives. Conclusion In the beginning of this article, I raised the question, Do we really need Agile PMO when Agile teams are self-managing and cross-functional?  Over the course of this article, we discussed various utilities of having such an organizational structure. However, if it’s a small organization, if the owner of the organization is driving few projects on his or her own, or if there are dedicated departments for compliance, audit, training etc., then an Agile PMO may not be needed. Nevertheless, for a large organization that requires a complete Agile transformation and/or has a large number of projects running, the Agile PMO structure will bring a number of benefits and business value. References [1] Book: I Want To Be An ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash [2] Book: I Want To Be A PMP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash [3] The Project Management Body of Knowledge (PMBOK), Combo 6th Edition, by Project Management Institute

Risk Management Life Cycle in the Context of Project, Program, and Portfolio

Event Description: With the COVID-19 pandemic, risk management is taken with increased interest by professionals, communities and organizations across industry verticals. Particularly within the Project-Program-Portfolio (PPP) community, risk management has been asked to be taken-up on a proactive and priority basis. The risk management life cycle (RMLC) works within the context of risk management framework. It ensures risks are managed in a structured and integrated manner in an organization irrespective of life cycle approaches chosen. Understanding of risk management framework across portfolios, programs and projects, is foundational to have tangible results coming from risk management. While a project’s risk management life cycle is somewhat known and practiced, there are a number of variations when programs and/or portfolios are taken up in an organization. Many risk management practitioners miss these subtleties! In this webinar, we will explore: Presenter Info: Satya Narayan Dash is a management professional, speaker, coach and author of six books.  He has created hands-on courses on Risk Management, including the course of “Practical Risk Management”, which has been used by many professionals and a number of candidate PhDs. His latest book on Risk Management – “I Want To Be A Risk Management Professional (RMP), Second edition” has created many PMI-RMPs and it has a 100% success rate so far. His web presence is at https://managementyogi.com  and he can be contacted at managementyogi@gmail.com. Have you watched this webinar recording? Tell MPUG viewers what you think! [WPCR_INSERT]