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. 

Agile's Amigo: Process

Stuck in flight delays at the Airport in the last few days, I was sitting at the Gate near the corner of a terminal where I could see through the glass windows the crew that was using the back doors along with the customer service representatives answering the stranded passengers and interacting with the flight crew for boarding preparation. Simultaneously, maintenance crew was inspecting the plane, another group loading the baggage, and yet another group fueling the plane. None of these various groups were visibly communicating among each other at the same time but the whole flow seems so orchestrated. If getting the plane to fly were to be considered as an agile project, then, the tasks associated with checks and balances is so much grounded in process which made me reflect on some comments by a few agile practitioners that there is no value in process documentation.

It is true that Agile Manifesto associates a higher value to “Individuals and interaction” over “processes and tools” and “Working software” over “comprehensive documentation.”  But does Agile truly suggest not having any process to follow or ignore writing any documentation? Let us challenge the agile purists then why is Agile so heavy requiring a process to capture user stories to have some minimum qualifications emphasizing the INVEST principle and backlog entries to follow a DEEP property? Why the developer can’t be left to interpret what should be developed instead of requiring to also understanding how it should be tested?  One may then associate that such silo-ed thinking may lead to failures from waterfall to repeat requiring collaborating using the daily sprint and using the agile dashboards for communication.  In that case, let us reflect further.

1. If projects are successful because of people, then, let us also accept that not all people absorb and consume information at the same pace even in a self-organized team – requiring at least some level of process enforcement such as the same repeated questions used to uproot challenges in a daily sprint. Isn’t this some level of process?
2. Even from a pure engineering and development standpoint, then, why is Agile putting such an emphasis on Refactoring going down to the level of documenting specific smells (Agile terminology indicating a symptom of a problem) collapsing classes to simplify object inheritance design, long parameter list, and even recommendations of how much should be in a specific try/catch block? Isn’t this substantial documentation of processes to be used in agile projects?

Most of the contributors to the agile manifesto came from a strong technical background with a focus on developing IT projects. The logical breakdown of thought process is inherent in the IT discipline. Yet, these practitioners carefully drafted the four manifesto statements where processes, tools, comprehensive documentation, contract negotiation, and following a plan were not considered effective or essential. To those agile practitioners avoiding creating documentation or valuing following a process, let us emphasize that Process is the Agile’s Amigos!