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 indicates 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 represent the benefit and the extent to which the benefits are realized represent the value. So, the concepts of benefits belong 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) are 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 increase 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 all the 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 with project/program managers to think of transition activities. These include:
- Transfer of 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).
- 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 instance, in order 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.
- Evaluation of 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.
- 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 process may have to be reviewed and modified to facilitate continuous learning and continuous improvement.
- Disposition of 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 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.
