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. 

Lessons learned on Strategic Project Management from a Dental Visit

Having trained individuals and companies on strategic project management as well as certification prep for PMP exams, one question that I always repeatedly emphasize is the differences between benefit and value. Even experienced professionals don't articulate these things clearly differentiating how a business case differs from project charter and why it is the foundation for any project or program. I normally try to give examples from the various industries connecting these thoughts. Interestingly, I found a simple and more effective example when I took my son for the orthodontic dental exam. 

As most orthodontic exams do, these exams focused on oral health focusing on teeth alignment using dental braces and retainers. Having gone through a few sessions, the dental assistant asked if my son was using retainers and brushing after heavy meals. My son was responding that he was occasionally doing them and not always using the retainers. The dental assistant replied, "You can only get the value of the retainer if you use it for its intended benefit!" Wow, two words, "Value" and "Benefit" used in the same sentence and made me connect how simple these concepts are. The dental office is providing the benefit by giving the retainers. Only when the retainer is used as required, the benefit is realized! That extent of timely benefit realization is the value for the customer! 

• So, in projects or programs, the deliverables (requirements, design, user stories, etc.) as part of the release, phase, iteration or sprint is just giving the output. 
• But, when these outputs are integrated towards a minimum viable product (MVP) or minimum business increment (MBI), then, these are providing capabilities. That means functionally they are available but operationally they are not ready.  
• When all these capabilities are integrated and transitioned, the combined capabilities become the outcome. Note that transitioned means, the outcome is in an operational state. If the project is not dependent on other project capabilities, then, these capabilities become the outcome. If there are multiple projects working coherently, then, all these capabilities from multiple projects must be integrated further to generate the outcome. 
• When these outcomes are utilized, then they serve as the benefit. Nevertheless, the benefit is what the performing organization is delivering to the customers. 
• Only when the customers use the benefit appropriately or realize an improvement over time, the value is recognized. 

Sometimes, the simpler examples bubble up to the top to illustrate these concepts. Different projects may have been involved in creating the various retainers based on various conditions. These projects may have to be working with other suppliers and vendors, who may have their own projects, to integrate these products, manufacture, and ship them to the dental offices. The manufacture may have realized some benefit because the dental offices paid for the retainers. But, has the dental office realized the benefit? Not until the patients come for regular orthodontic exams and use them. As the people play different persona in the value chain, the concepts of output, capability, outcome, benefit, and value also change. Nevertheless, value is realization of benefit delivered, benefit is the integration of multiple outcomes from one or more projects, and outcomes are the systemic integration of various outputs identified to be delivered at different points in time!

I guess, when we are ready, we see the explanations in daily life! 

What do you think? Thoughts? Please share.