Program Management: Scenarios and Rationale for Document Selection

As part of a volunteer work in guiding the distinction between project management and program management for their specific contributions within a medical affairs group, I saw questions arise between a business case and a charter. Unrelated to this body of work that I was doing and as part of the management training and independent career-coaching that I do, I felt there was ambiguity between scope statement and charter.  

Previously, I have defined the five essential management documents (Rajagopalan, 2020). So, please consult them for a quick refresher. Here, I am using this blog to demystify the business case, program charter and project (or component) charter, roadmap and the scope statement with a few important scenarios. 

Scenario 1: Stakeholders question the rationale for undertaking an initiative 

Document:  Business Case

Rationale: The business case is a justification document for the expected benefits, created during the program formulation sub-phase within the program planning phase. In the case of a program component, it is part of the component initiation and planning sub-phase for the component in the program delivery phase.

Scenario 2: Steering committee is evaluating the program/project to determine program continuation

Document:  Business Case

Rationale: The business case is a justification document for the expected benefits. That is the primary document the steering committee uses to determine if the benefits are being met. They may also consult the benefits register (this is called the value document) to determine if the benefits have been met according to the planned expectations at the phase gate or stage gate reviews to determine if the program should continue or not.  

Scenario 3: Stakeholders must reprioritize program when the market demands or priorities have shifted considerably

Document:  Business Case

Rationale: First, let us look at the root causes. Say, another competitor has delivered the benefit already at a price that the current program can no longer deliver value for the customer and the benefit. The ongoing continuation of the program can no longer be justified (hence business case). Alternatively, the market priorities (e.g.; pandemic, GDPR regulation) have shifted another program to be more justified than this program (the opportunity cost). The steering committee can kill the program completely in the former case or park the program temporarily reassigning resources to the new program.   

Scenario 4: Stakeholders are unsure about alignment of benefits with the business strategy to commit their resources (people, time, money)

Document: Charter (During Program Definition) 

Rationale: The charter is the authorization document that outlines the high level scope (note, high level; not detailed scope) as well as the resources required to deliver on the benefits identified in the business case. The charter is expected to outline this alignment, commitment, and engagement required for getting stakeholders' support. This is why I call the charter ACEs (alignment, commitment, engagement) stakeholders. So, anytime a stakeholder questions the alignment, commitment, or engagement, go to the program charter or component charter as appropriate. 

Scenario 5: New Stakeholders come to a program. They would like to get a list of initial dependencies and risks identified impacting their delivery. 

Document: Charter

Rationale: As the authorization document, the charter is expected to identify the initial list of assumptions, constraints, dependencies, risks, and known issues. While they are high-level, these are the "initial" set. So, a good starting point is only the charter. Subsequently, if they want to delve deeper they can review benefits management plan, integrated project management plan, assumptions or constraints log (assumptions, constraints), program roadmap, product backlog or project schedule (dependencies), benefit register and risk register (risks), or issue log (issues). Considering the stakeholders are "new" and they want "initial" information, starting with the charter is better.  

Scenario 6: Some risks are becoming more pronounced or secondary risks have materialized. Stakeholders need to consult issuing the change control.

Document: Charter

Rationale: As part of ensuring ongoing ACE, the processes towards the change control (or governance) is mentioned in the charter. The detailed steps may be listed in the project or program governance plan, which is a subsidiary document. So, it is better to start with the charter that may guide on the processes to follow, reporting requirements, authority of the component manager, program manger, and the steering committee. 

Scenario 7: Stakeholders want to understand when certain benefits can be delivered and/or ascertain how changing the order of delivering certain capabilities can impact the overall program 

Document: Roadmap

Rationale: The roadmap gives the high-level schedule with milestones and deadlines for benefit delivery, transition, and sustenance. When risks materialize (that means they are issues now) and stakeholders want to understand timeline for benefits delivery and the impact assessment for any changes to the schedule, the roadmap is the first option. The next document to review is the benefits management plan as it serves as the baseline document for the program benefits delivery. Subsequently, they can delve deeper into the other subsidiary documents as needed.  

Scenario 8: During program delivery phase, new or existing stakeholders would like to get clarity on the deliverables, direct or lateral dependency among requirements or design considerations for some of the requirements.  

Document: Scope Statement

Rationale: Questions around the deliverables to be produced, capabilities to be delivered, or outcomes to be integrated are very detailed. The design considerations for the requirements are frequently detailed - whether it is business, architecture, or technical dependency. Anytime specific details are relevant much more than high-level scope, then, the focus shifts from 'charter' to 'scope statement.' The scope statement can be the project schedule, Gantt chart, network diagram, release and iteration backlog, etc. If the question is more around the benefits and their realization, then benefit management plan (baseline document) or the benefits register (value document) are relevant. More granular focus may be at the definition of done (DoD) spanning completion (tasks) and acceptance criteria (test cases) covering performance qualification (PQ), operational qualification (OQ), and installation qualification (IQ).    

I hope these scenarios and the rationale help you with the importance of selecting the right documents. 

References

Rajagopalan, S. (2020). Five essential documents in project and program management. Retrieved from https://agilesriram.blogspot.com/2020/11/five-essential-documents-in-project-and.html

Qualifying Benefits in Benefits Management

As I was delivering a Program Management certification training, there were some discussions around the phrase, "Qualify Benefits" (Project Management Institute, 2024). Now, I have already blogged about what benefits mean (Rajagopalan, 2020) even within the context of strategic project management (Rajagopalan, 2021) and in a few follow-up discussions, it was clear to me that the action-oriented adjective, "Qualify," needs some explanation. 

"Qualify benefits" in the context of program benefits management refers to the process of defining, assessing, and validating the potential benefits that a project or program is expected to deliver. This involves several key steps. Let us consider an example of a company implementing a new customer relationship management (CRM) system as we identify some activities for each step listed here.

1. Identification of Benefits:

• Strategic Alignment: Ensure that the identified benefits align with the organization’s strategic goals and objectives.
• Stakeholder Input: Engage with stakeholders to gather their perspectives on potential benefits, ensuring that all relevant benefits are considered.

For the CRM system, the potential benefits include improved customer satisfaction, increased sales, and enhanced data analytics capabilities.

2. Definition of Benefits:

• Clear Description: Clearly describe each benefit, including what it is, who will benefit, and how it will be realized.
• Measurability: Define how the benefit will be measured. This often involves establishing key performance indicators (KPIs) or metrics.

The CRM system must define benefits like the a) improved customer satisfaction measured by Net Promoter Score (NPS), b) increased sales measured by revenue growth percentage, and c) enhanced data analytics capabilities measured by the reduction in time taken to generate reports.

3. Assessment of Benefits:

• Quantitative Assessment: Where possible, quantify the benefits in financial terms (e.g., cost savings, revenue growth) or other measurable units (e.g., time saved, customer satisfaction scores).
• Qualitative Assessment: For benefits that are difficult to quantify, provide a qualitative assessment (e.g., improved employee morale, enhanced brand reputation).

The CRM can perform this assessment either qualitatively or quantitatively or a combination of both approaches. The quantitative approach may assess the increased sales by 10% within the first year. The qualitative approach my assess the improved decision-making capabilities through better data insights.

4. Validation of Benefits:

• Feasibility Analysis: Assess whether the benefits are realistically achievable given the resources, timeframes, and constraints of the project or program.
• Risk Assessment: Identify and evaluate risks that might impact the realization of the benefits and develop mitigation strategies.

Validation may employ multiple approaches as well. For example, the CRM may validate feasibility (technical, operational, environmental) feasibility. An example could be validating that the CRM system integrated with existing systems and that training plans are in place.

Another validation is the ongoing risk management throughout the benefit lifecycle. Example risks may involve identifying potential resistance from sales teams and planning for change management initiatives. Quality is a function of risk (Rajagopalan, 2023b) and so it is critical for one to consider multitude of risks for risk driven development. 

5. Documentation and Communication:

• Benefits Register: Document all identified and qualified benefits in benefits register or benefits realization plan.
• Stakeholder Communication: Communicate the qualified benefits to all relevant stakeholders, ensuring transparency and buy-in.

The CRM documentation may involve creating a benefits realization plan outlining these benefits, how they will be measured, and who is responsible for them. The CRM documentation plan may also deeply engage in the transition (Rajagopalan, 2023a) and sustenance plan so that component transition can continue with benefit sustenance in operations. 

6. Establishment of Monitoring and Evaluation Framework:

• Tracking Mechanisms: Set up mechanisms to monitor the progress towards achieving the benefits throughout the lifecycle of the project or program.
• Review and Adjust: Regularly review the benefits realization progress and make necessary adjustments to ensure that the benefits are on track to be realized.

Examples of tracking systems for a CRM may involve regularly tracking NPS scores, revenue growth, and reporting times. Similarly, the review and adjust approaches may pivot around the monthly review meetings to assess progress and address any issues.

By qualifying benefits early and continuously, organizations can ensure that their projects and programs are aligned with strategic goals, have clearly defined and achievable outcomes, and provide measurable value to stakeholders.

References

Project Management Institute (2024). The Standard for Program Management. 5th Edition. Newtown Square, PA: Project Management Institute.

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

Rajagopalan, S. (2021, June 14). How different is Strategic Project Management? Retrieved June 16, 2024, from https://agilesriram.blogspot.com/2021/06/how-different-is-strategic-project.html

Rajagopalan, S. (2023b, March 10). Quality is a function of Risk. Retrieved June 16, 2024, from https://agilesriram.blogspot.com/2023/03/quality-is-function-of-risk.html

Rajagopalan, S. (2023a, October 23). TREAD carefully to transition benefits. Retrieved June 16, 2024, from https://agilesriram.blogspot.com/2023/10/tread-carefully-to-transition-benefits.html