TREAD carefully to transition benefits

Earlier this month, I had the opportunity to deliver the benefits management module as part of the Program Management (PgMP) certification preparation class delivered by Kailash Upadhay from AddOn Skills. Subsequently, I was doing another corporate training where people were discussing about benefit as the financial gain to the organization as part of "Program Increment" planning in Scaled Agile. When I tried to explain the differences, people felt that program management is not relevant in adaptive approaches as agile focuses only on value.

As I reflected on these combined discussions, I felt that there is a larger disconnect on benefits and value and when different emerging frameworks play with words, the fundamental meaning is lost! I would like to call out my reflections from a dental visit blog (Rajagopalan, 2020) where I synthesized the importance of output, capabilities, outcomes, benefits, and value. Consequently, I would like to address two big myths!

• First, in the world of project, program, and portfolio managing focusing on product management, benefits are program level deliverables. Programs represent the integrated outcomes that indicate an operational state. This outcome is derived from the integration of one or more components (which include projects, sub-programs, and program related activities). The utility value of these outcomes represents the benefit and the extent to which the benefits are realized represent the value. So, the concepts of benefits belonging to traditional approaches and value belongs to adaptive approaches are incorrect.
• Second, benefits lifecycle (these include the stages benefits identification, benefits analysis & planning, benefits delivery, benefits transition, and benefits sustenance) is done throughout the program lifecycle (program definition, program delivery, and program closure). Benefits are not related to financial ROI alone as customer satisfaction and employee morale are intangible benefits that can't be measured in financial value. I recall reading about Infosys being the first Indian company to ever record human resources capital and brand value as an asset in the balance sheet. Similarly gain can be increased in non-human capabilities, such as the facilities, equipment, materials, infrastructure, and supplies that can come through vendors, consultants, partners, and suppliers among many things. Companies launch programs constantly to address these types of customer and employee satisfaction initiatives as well as non-human resource capabilities (partner expansion, new vendors in the horizontal and vertical integration, mergers & acquisition, strategic expansion initiatives, etc.) So, to say that programs focus on financial metrics alone is incorrect. 

So, benefits are realized only in the operations and programs as well as the component initiatives are focused on benefit transition (I am sure the Steven Covey's "Start with the End in Mind" is so relevant; this is even more reason, why program management becomes a leadership role). When I managed my PMO, through experience and lessons learned, I created a mnemonic to help my team. It is called,  "TREAD" which helps project/program managers to think of transition activities. These include:

1. Transfer Risks: Risk Register is maintained throughout the program and its components. When we are ready to transition outcomes to operations, some of the risks may not be closed, some risks may be residual, and new risks may be present during the transition (e.g.: Training delivered needed to include subtitles because of the new operational team members have hearing disabilities and will have to have video subtitles for training to be effective).
2. Review Documentation: One of the things that very frequently slips through the cracks is the documentation. Whether it is system or user documentation required for operational success or as part of contractual agreements or for training and maintenance, ensuring that these documentations are accurately reflecting the reality is important. Please don't limit yourself to thinking of software specific documentation alone. For some benefits to be valuable, there may have to be consumer specific documentation (Patient Guide), physician specific documentation (Important Safety Information, Prescribing Information) and branding documentation (brand guide, style guide, annotated visual aid, etc.) will be mandatory.  
3. Evaluate Performance against acceptance criteria and metrics. Now, these are not just test execution and inspection but a deeper governance review with critical success factors (CSF), objectives and key results (OKR), and the key performance indicators (KPI). Ensuring such acceptance criteria against the business case along with potential lessons learned is important.
4. Assess Approval and Readiness: Emerging from all the above is the readiness of the governance to validate against traceability, auditability, and compliance to approve the transition to operations. Based on lessons learned and retrospectives, additional processes may have to be reviewed and modified to facilitate continuous learning and continuous improvement.
5. Dispose Resources: Finally, matching against the guarantee and warranty requirements aligned with the procurement domain as well as resource domain, existing resources (people and non-people resources) may have to be relieved. This makes these resources either available in the resource pool for other capital projects or avoid accumulating costs unnecessarily to the performing organization. 

So, TREAD carefully when transitioning benefits and don't fall victim to benefits are no longer relevant in Agile approaches or benefits only represent the financial ROI.

References

Rajagopalan, S. (2020). Lessons Learned on Strategic Project Management from a Dental Visit. https://agilesriram.blogspot.com/2020/08/lessons-learned-on-strategic-project.html

Singh, J.V. & Trivedi, B. (1999). Infosys Technologies Limited (A). The Wharton School of Management, University of Pennsylvania. 

Using Time to manage Risks associated with Stakeholders

Often, in my project management experience, I see that people miss engaging with the required stakeholders proactively to deal with risks. When stakeholders have not engaged appropriately, then, risks go uncontrolled making it impossible to mitigate them. Based on my experience, I see three types of stakeholders that need a good project manager must identify to proactively manage.

1. Too much engaged to the extent that they suck up all the oxygen in the team. They knowingly or unknowingly give the indication to the team that their ways are the common-sense way and everything else is almost wrong. 
2. Missing in Action stakeholders are too busy never to be around but when decisions are taken without them, they appear immediately. They are the constant speed breakers, breeding distrust and sometimes fear.
3. Ambiguous stakeholders who are in between these two above extremes can never figure out what they want, changing the priorities repeatedly making it difficult for the team to progress or slowdown. 

All these three types of stakeholders bring several types of risks - business, technical, and people among the many risks. The most important thing is to "Taking Initiative Managing Energy" that I call TIME management. This energy can be translated into how we manage "expectations". This is the reason why the project management discipline uses engagement for "stakeholder engagement" but management for other areas like knowledge areas like "Scope Management", "Schedule Management", etc. When you look at prioritization, it is all about taking initiative managing energy!

Consequently, while principles like start list, wish list and stop list exist that have been further enhanced by MoSCoW principles like (Must, Should, Could, and Won't) to prioritize requests, tasks, features, etc., TIME management considers a few simple things that anyone can do manage the stakeholders. These are asking a few questions like the following to set the expectations with the stakeholders.

1. Is this required? Particularly when #1 and #3 types of stakeholders are involved, determining the customer or business value of any proposed technique would take these discussions far along in avoiding tangential discussions and focusing on value-added work. Including timeboxing principles such as a definite amount of time for every actionable outcome from every agenda item can further keep the focus and remove other discussions to the parking lot.
2. Can you help me solve this, please? This approach can be used in all the three types of stakeholders. By setting one-on-one discussions with the stakeholder to mention how their values are important but how their continued presence is eliminating any creativity from the team due to their inclination to agree with the stakeholder's views or long absences taking any timely decision making away from the team can take the stakeholder management very productive. 
3. What's the ROI? Particularly in the stakeholder #3 situation, refocusing on the efforts versus cost/benefits can bring a distinct focus back to the project's objectives. Refocusing on the opportunity costs due to the cost of the meeting in discussing features that may not be a value add unless the stakeholder can unambiguously quantify will require the stakeholder to think of the Pareto principle and focus on "DONE"!

In the end, engaging stakeholders is an art that any project manager must spend time on. Regardless of how well one is, without a kaizen attitude towards continuous improvement, such arts of engaging stakeholders depreciate exponentially with time. So, use TIME to manage risks associated with stakeholder engagement. 

What other thoughts do you have in engaging stakeholders productively? Please share/comment. 

RACI Errors: Impact on Project Integration Management

In developing a good project integration management, it is critical to understand the role of responsibility assignment matrix. The goal of project management primarily is to deliver results through other people. This involves a clear role and responsibility for every work package or function that will play a critical role in project delivery. One such responsibility assignment matrix is the RACI.

I have often seen RACI filled incorrectly and have blogged (Rajagopalan, 2014). However, I would like to discuss the following two issues further as they have a relationship on other aspects of project management knowledge areas.

1.  Mixed roles with "A" and "R": When a person or function is marked with both these roles, then this may introduce the risk of project schedule slip. If the individual responsible for doing the function fails to perform, then typically the accountable person will monitor the slip and ensure that the work is getting done. Alternatively, if the work is not completed satisfactorily, the accountable person shares the onus to check on the quality and the cost of poor delivery. However, if the "R" person also is the "A" person, then the latter will not put any pressure on the former because they are both the same. This impacts risk, time, cost, and quality. Similar challenges can be seen with "R" and "C" or "I" overlap.

2. Too may "A"s: If two people are accountable, then there are two types of problems. The first is the blindness game each "A" role plays thinking that the other role will keep an eye in ensuring the task is completed. When this task fails to be done, the blindness game becomes the blame game reasoning with the "I thought you would have done it." This introduces project delays that may impact time and introduces challenges with procurement. The second issue is the team gets conflicting directions from each "A" person leaving the team to get caught between power plays. The resulting team dynamics may lead to HR and stakeholder challenges.  Furthermore, these issues may impact other areas of project management.

There are several symptoms that a proper RACI may resolve for the project manager to proactively address. But unless a project manager has a good understanding of RACI, the symptoms deteriorate leading to major problems requiring surgical intervention from executive management.  The project manager can avoid these strategically by planning to succeed with end in mind. 

References

Rajagopalan, S. (2014). RACI: Errors and Implications in building the right one. https://agilesriram.blogspot.com/2014/07/raci-errors-and-implications-in.html

Dependency is a Risk to be Managed

Anyone in project management knows that dependency is a risk. When tasks are using the most common finish-to-start dependency, the delayed completion of predecessor task introduces a risk to the project. When resources are unavailable to start the tasks or their capacity is reduced to work on a project, their dependency on other project commitments poses a risk. Waiting time on processes, such as workflow approval, or not having a clear process, such as a lack of documented code review guidelines, introduces dependency on others. Technical architecture decisions requiring a dependency on other SMEs or dependency on training due to the lack of knowledge on the technology or tools adds risk. Organizational cultural considerations on budget approval, procurement considerations, or hiring processes are dependent on stakeholders for decision-making. 

So, as you can see, there are people, process, technical, and organizational dependencies either deliberately introduced (hard logic) or mandatorily included (hard logic) can be looked from internal and external considerations. The internal considerations may be within the team or within the company. As a result, we can come up with a table as below. Given below are some examples of dependencies that may be a risk.

How do you think this will work for your organization? Share your thoughts.