Program Closure: Scenarios for closing or continuing the program

People familiar with program management understand that when all the program components associated with the program has been transitioned, the program enters the program closure. According to the standard for program management, there are two possible scenarios. The first scenario is that the program closes as planned and the other scenario is that the program transitions to another program that continues with the benefit realization. 

People familiar with program management understand that when all the program components associated with the program have been transitioned, the program enters the program closure. According to the standard for program management, there are two possible scenarios. The first scenario is that the program closes as planned and the other scenario is that the program transitions to another program that continues with the benefit realization. 

Based on my practitioner experience in delivering many programs, I see multiple other options as well. Here, I will present other scenarios. 

1. New benefits identified: Either due to finding a new unexpected opportunity (e.g.: patent) or newer strategic opportunities related to the business case to continue being viable (adjacent market expansion), it is possible that the program cannot close as planned. In such cases, the program may be extended by identifying, analyzing, and evaluating the benefit by the program steering committee. The program manager must evaluate the interdependencies with this new component and the previous transitioned components to maximize benefits.

2. Emerging threats or opportunities: A business case primarily exists to justify the business needs. These business needs are going to be influenced by enterprise environmental factors. These are uncertain and unknowable events that the business will constantly monitor. Some of these events may include market, economic and technology disruptions, legal and regulatory changes, governance mandates and compliance considerations, etc. Any combination of these factors may identify newer benefits requiring the program to be extended so long as those benefits are adjacent, relevant, and tangential to the program objectives.

3. Benefits obsolescence: Even when a specific program component is completed, when it comes to the program closure stage may lose its significance because that benefit is no longer needed. This could be due to the competitive landscape where a competitor has released an operational capability that the program component can no longer meet (e.g.: Early patent or regulatory approval, competitive pricing, strategic alliance with significant supply chain advantage). Alternatively, the company may have shifted the organizational priority that the program as a whole or the component alone may no longer be relevant for operations to sustain them invalidating the need for transition.

4. Absence of operational readiness: Another challenge is that the operations team may be having other priorities that make it difficult for the program to transition. This can manifest due to issues that have materialized deprioritizing the component transition over other operational challenges. Alternatively, the operational team may not have the resource constraints (capability, skills, or competencies) or process maturity to be ready for transition.

As part of all these happy path and alternative closure stages, many frameworks can be considered for making the decisions. Some considerations include the following.

1. Strategy Evaluation: Business case validity, market forces review, capability analysis, capacity analysis, and strategic priority review,
2. Alignment Assessment: Strategic alignment, Resource analysis, Cost benefit considerations, Risk assessment and evaluation, and Stakeholder impact analysis
3. Decision Considerations: Modify and transition benefit, temporary hold and release, early closure, and create an alternative program.

Quality Responsibility - 5G of Quality Audit

It is very true that software has undoubtedly dominated the market. There are building information modeling (BIM) systems that help with the design and development of constructing a bridge or a skyscraper. The anti-lock breaking systems (ABS) that everyone is familiar with is having software controls. It is increasingly becoming common for even a medical implant to include software with secured over-the-air (OTA) update capabilities. While all these functions of software are needed and great for the society, it has also reduced the notions of quality to be frequently limited to testing. This was apparent to me when I was moderating the Northeastern University's Third Global Symposium on Leadership and Project Management when I saw attendees ask the question, "Who is responsible for Quality?" 

Simply put, I responded, "Quality is everyone's responsibility!" It is not the responsibility of project manager, program manager, product manager, or product owner or most importantly the quality manager or tester. Despite the predominance of software, there are still physical products and ancillary services that have non-software components. In the raw materials received at a facility that are either assembled (nuts and bolts) or somehow used (cement, chemicals) within the manufacturing facilities or drug manufacturing, there are quality control inspections. Quality audits apply to walking around the facilities observing how people are using their safety goggles, helmets, protective gloves, or safety harness and understanding the reasons for their misusing or abusing them. So, I thought I will discuss what a quality audit is and the lean's 5G contribution to this domain of knowledge.

Quality Audit is a broader domain that involves the verification activity to validate quality of the products and processes. While quality control is often reactive controls (corrective actions) within the context of a product, quality audit extends to quality assurance monitoring (preventive actions) within context of a process. Together, these product audit and process audit also evaluate the system audit ensuring that the systems used in both these product and process controls work as expected. Such an audit is done at three levels:

• First Level Audit: Periodical evaluation by the teams supported by the auditors internal to the organization. In plan driven approaches, the project manager is accountable for this activity but the teams are responsible for this activity themselves. In change driven approaches, the self-governing team is responsible for this activity and the scrum master or the agile coach is responsible for ensuring that this is happening not only in the reviews and retrospectives but also in the subsequent iterations.   
• Second Level Audit: This is the first external audit. The focus is on the suppliers and vendors providing raw materials as well as on the knowledge workers (e.g.: consultants) providing expertise. The contracting organization performs this function on the suppliers used. This external audit is subject to the terms and conditions listed in the contractual documents. As a result, it could be the procurement department, PMO, or a combination of stakeholder groups internal to the contracting organization. These audits ae facilitated by the auditors, mandatory, and formal evaluation of the goods and services provided by the third party providers. Examples of security assessments such as penetration tests and proof of skills and talent management such as professional development certification are the starting points of the numerous procedures evaluated to uphold quality.
• Third Level Audit: This is the second external audit. This audit is more formal, more extensive, and more time consuming because these audits are conducted by a third party independent of the contracting or the contracted organization. Such a rigorous and robust evaluation looks at people, processes, and technology among many things to ensure compliance with a specific government regulation or industry certification. For instance, an organization may perform such an audit to confirm with ISO 9001 or SOC2 standard and/or GDPR or HIPAA regulation. Frequently, such a quality audit is done as part of a program component (project or subprogram) or portfolio component (operations) and so responsibility is multifold with the portfolio or program manager being the accountable owner. 

Understanding the 5G's proposed by Lean Manufacturing is paramount in understanding this quality audit. While these concepts apply to manufacturing mainly (Azzaouri, Yousfi, and Bouamrani, 2022), I believe these concepts are extensible to any domain or industry . These audits focus on five key elements:

1. Gemba: Actual place where the work is performed. Often called Gemba walks, the management terminology is called "Management by Walking Around" (MBWA) to perform "inspection" (observing behavior rather than what is told) and gather data as part of "non-verbal communication."
2. Gembutsu: Actual events that transpired. These are the issues that happened as documented in the issues log, defects, or the voice of customer or voice of business. It is important to note that this could also be things that didn't happen.
3. Genjitsu: Actual situation that contributed to the problem. This engages why the "Gembutsu" happened. This is the root cause analysis that can be evaluated by anyone of the seven quality control techniques and can also be superseded by the force-field analysis.  Examples include: no backlog refinement prior to planning, lack of a clear DoD, not using risks to prioritize, etc.
4. Genri: Actual hypothesis of the scientifically or universally accepted principles and frameworks with a factual correlation of observations. The Genjitsu analysis may involve some hypothesis such as "If we had a tool to perform X, we would not have seen this problem!" or "If we had enough capability, competency, or capacity, we would have avoided this from happening!" While these may be true, these observations may be based on universal facts and understanding the factual correlation is important (How much are we trained on the tool or why are not we using an alternative tool that works well with our processes?) is also important.   
5. Gensoku: Actual verification based on adopted operational standards and practices. Extending the corrective and preventive actions, alternative thinking, and risk driven development (Rajagopalan, 2023a), these thoughts are work done after the audit findings to correct the observations. These observations may be controls implemented are effective or are not relevant (green), observed gaps that needs improvement (yellow), implemented controls with material concerns (orange), and immediate remedial actions required to address ineffective or material issues (red). 

By examining these five 5G elements, quality professionals can gain a deeper understanding of the root causes of quality problems and develop more effective solutions. For example, in the case of a manufacturing defect, a quality control engineer might conduct a Gemba walk to observe the production process firsthand and identify any potential issues. They might also collect and analyze Gembutsu data, such as machine settings and operator logs, to determine the exact sequence of events that led to the defect. This information can then be used to analyze for Genjitsu such as missed maintenance schedule contributing machine calibration errors. When developing such corrective or preventive actions, we can build Genri driven hypothesis such as documenting clear processes and procedures or giving frequent training to build quality into the processes. Subsequently, processes can be audited per Gensoku thoughts to evaluate how controls are working to address the risks and issues. These observations may further lead one to look at Muda, Mura, and Muri contributing to the management debt (Rajagopalan, 2016).

As you can see from these discussions, quality is a function of risks (Rajagopalan, 2023b). Everyone contributes to risk and subsequently therefore to quality. 

What do you think?

References

Azzaouri, K., Yousfi, S., Bouamrani, M.L. (2022). Combining digitalisation with 5G lean tool for quality and competitiveness in automotive electrical wiring systems manufacturing. Moroccan Association for Applied Sciences and Innovation, 1-9. In Proceedings of 4th International Conference on Quantitative and Qualitative Methods for Economics, Management and Social Sciences, Istanbul, Turkey.

Rajagopalan, S. (2016). Management Debt: Cost of non-delivery and non-conformance. Retrieved from https://agilesriram.blogspot.com/2016/10/management-debt-costs-of-non-delivery.html

Rajagopalan, S. (2023a). Risk driven prioritization: Challenges to prioritization techniques. Retrieved from https://agilesriram.blogspot.com/2023/02/risk-driven-prioritization-challenges.html

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

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

Management Plans vs Project Documents

In a few corporate trainings I recently did in the EMEA and APAC regions, there were questions on practices on how to set up the priority schemes, what guidelines should govern when changes and test cases will be approved, etc. The questions further emerged into transforming into agile practices and if these questions are even relevant because agile allows constant change. 

So, I am writing this blog to differentiate the documents used for managing the initiative (project, program, portfolio) from the project artifacts documenting the detailed activities within a project, program, or portfolio. Agile is an approach to deliver on project outcomes based on the level of complication and complexity on the scope being developed. Traditional approaches are not too different and are based on progressive elaboration and rolling wave planning. 

Management Documents

The management documents are used to guide, control, and organize the ways of working within the organization. They are typically broader in scope and deal with overall strategy, resource management, and governance. Given below are some examples of management documents and they are required in both traditional or agile approaches to delivering on projects.

1. Business Case

   • Justifies the initiation of a portfolio, program, or project, outlining the benefits, costs, risks, and strategic alignment.

2. Product Strategy

   • Defines the vision, goals, and roadmap for a product, aligning it with business objectives.

3. Charter

   • Identifies the project/program/portfolio manager authorizing the person to use organizational resources.

4. Benefit Management Plan

   • Describes how and when the benefits of the project will be delivered and measured.

5. Resource Allocation Plans

   • Outline how resources (people, tools, budget) are distributed across various projects.

6. Strategic Planning Documents

   • These involve procurement management plans, quality management plans, 

7. Governance Policies

   • Define the rules, policies, and procedures that govern project management and execution.

8. Risk Management Plans

   • Identify, assess, and plan for potential positive and negative risks at the organizational level along with risk response plans.

9. Performance Appraisal Reports

   • Used to evaluate performance so that these act as a feedback mechanism to continuously validate the business case or alignment to strategic initiatives.

10. Training and Development Plans

    • Detail the training needs and development programs for team members to enhance skills and capabilities.

11. Financial Reports

    • Include budgets, forecasts, and financial performance metrics for the organization.

12. Integrated Project Management Plans

    • Comprehensive plans that integrate various aspects of project management such as scope, schedule, cost, quality, and communications.

Project Documents

Project documents are specific to individual projects and are used to plan, execute, monitor, and close projects. These documents are more dynamic and often updated throughout the project lifecycle.

1. Project Charter

   • A document that formally authorizes the project, outlining its objectives, scope, stakeholders, and high-level schedule.

2. Project Roadmap

   • Visual representation of the project's goals and deliverables over a timeline. This is more detailed than the product roadmap and can be the Gantt Chart, Milestone Chart, etc.

3. Product Backlog

   • A prioritized list of features, enhancements, and fixes that need to be delivered for the product.

4. Sprint Backlog

   • A list of tasks and user stories to be completed in the current sprint.

5. Sprint Planning Documents (Definition of Ready, Release & Sprint Goals)

   • Include just enough plans for what will be delivered in a sprint and how it will be achieved. Recall that product increments can be incremental or unified delivery.
   • Outline the timeline and milestones for delivering product increments to users.

6. User Stories and Acceptance Criteria

   • Describe specific features or functionality from the perspective of an end-user, along with the conditions for acceptance.

7. Burndown Charts

   • Graphical representations showing the amount of work remaining versus time.

8. Logs

   • Summaries of the daily stand-up meetings, including what was done, what will be done, and any impediments.
   • This could be issue logs, change logs, updates to risk register, benefit register, backlog, etc.

9. Lessons Learned and/or Retrospective Reports

   • Documents the outcomes of sprint retrospectives, including what went well, what didn’t, and action items for improvement.

10. Release Documentation

    • System and user documentation
    • Release Notes
    • Updated Product Roadmap
    • Training 

11. Definition of Done (DoD)

    • A clear and concise list of criteria that must be met before a product increment is considered "done."

12. Test Plans and Test Cases

    • Detailed plans and cases outlining how testing will be conducted, what will be tested, and expected outcomes.

Summary

• Management Documents focus on organizational-level planning, governance, strategy, and resource management. Examples include the business case, product strategy, benefit management plan, and integrated project management plans.
• Project Documents are specific to the execution and management of individual projects, covering aspects like scope, schedule, quality, and deliverables. Examples include the project charter, project roadmap, product backlog, and sprint planning documents.

References

Rajagopalan, S. (2020). Five Essential Documents in Project and Program Management. https://agilesriram.blogspot.com/2020/11/five-essential-documents-in-project-and.html

Communication is about Mastering Story Telling

I recently delivered a chapter talk on the silver screen techniques on project management with the PMI MassBay chapter on Mar 27, 2024. I synthesized how script writers and story writers master the art of telling stories in every movie or the popular TV episodes. After the chapter talk and the LinkedIn post, I had about two people reach out asking if story telling techniques are relevant in the daily walk of a project manager. These people were not in my talk, but I thought I would synthesize the essential story telling techniques. 

In my book on Organized Common Sense, I mention that any communication is all about making sure that the other person understands what is expected of them because of what was communicated! Essentially, this expectation further expands to persuasive, informative, and exploratory communication. 

• Discussions on why starting or terminating a project is necessary, investing money or cutting back on resources, and motivating people to the same leveled plane to see or do things differently requires persuasive communication with the right level of stakeholders with the decision authority. 
• Reporting on updates on progress and reviewing steps necessary to address risks or bring troubled projects back on track could involve a combination of transactional or transformational communication primarily focused on informing the right level of stakeholders with the right level of information at the right agreed timeframe using the right channel. 
• Continuous evaluation of new ideas based on the product lifecycle stages or experimentation of new strategies to realize competitive advantages (e.g.: CAGE or VRIO frameworks) may involve exploratory communication with the right level of stakeholders so that the required resources (time, money, people, and other non-human resources) may be allocated.

In each of these approaches, the master storyteller gets through meeting the expectations. This is the power of negotiation as well. So, here are some examples of storytelling.

• Hero's Journey: This is a popular technique where the context is identified in greater detail first. Then, a potential interest is created why such a problem needs to be addressed without giving details behind the solution. How a "Hero" navigates through the challenges forms the story.
• Mountain. This approach builds the tension (problem) and the related connection (solution).  Most TV shows follow this. Almost like Hero’s Journey except that there are no happy endings always just like how experiments do not always give the intended results.
• Nested Stories – It is like someone narrating a story from one person’s point of view! May have some lessons but may miss lessons. (Like Forest Gump)
• Spark Lines – Arousing interest on a topic comparing with reality (Biopics; I have a dream - MLK), Winston Churchill's we will fight … we will never surrender, Ahimsa and non-violence by Gandhi)
• Media Hype – Immediate attention needed, like elevator speech, 3 bullet points, 5 things to do before the next meeting, etc. “Always Be Closing” (Glengarry Glen Ross) sales pitch!
• Divergence & Convergence – How to brainstorm for alternatives (all risky ideas welcome) and how to narrow it down because of constraints and limitations! 
• False Start – “I am successful because of my repeated failures” motto! If I can do it, anybody can do it! Helps with motivation, inspiration, etc.
• Debate and Dialog - Expert Panel, Petal Structure, Pomodoro – Examples of getting multiple views – agreeable or disagreeable 

What techniques resonate with you? Why? Share your thoughts!

References

Rajagopalan, S. (2020). Organized Common Sense: Why do Project Management Skills Apply to Everyone. Outskirts Press. https://outskirtspress.com/sriramrajagopalan

Relationship between Artificial Intelligence and Leadership

I recently attended the Healthcare Information Management Systems and Society (HIMSS) 2024 conference in Orlando, Florida. As the Global Head of Agile Strategy, I represented Inflectra corporation looking up for learning about the growing influence of information systems in the healthcare space. It was wonderful to see the various improvements in the healthcare space in pre-clinical, clinical, and post-clinical stages of drug development, various healthcare and life sciences spaces like ambulatory care, hospital management, emergency care, neonatal and pediatric spaces, and endless array of devices and software products that support these areas. 

One thing that I saw written in many of the sessions, keynotes, exhibitors, and conversations among the attendees was the influence of artificial intelligence. Unlike many other audiences, these discussions were not just on large language models or generative artificial intelligence but also on deep machine learning algorithms within their line of work. While people talked about training data, prompt engineering, privacy and security considerations, there were only a very handful of sessions that I can count in my one hand that I was exposed where people talked about digital ethics or leadership. 

One of the expert panel speakers at the onset of the conference keynote commented about Steve Polack's quote, "... before talking about artificial intelligence, let us talk about natural stupidity!" History has taught that there have been a lot of lessons learned but we continue to learn the same mistakes due to personal egos, bias, labeling, stereotyping, and plain unwillingness to learn. This is one of the reasons why I even say, "Common sense isn't common!"  Therefore, if we take the evolution of people compared to the growth of technology, people have lived longer in relation to technology and yet lack perfection! Then, how can we expect technology to be perfect? 

This is the fundamental reason why we need leadership. Every time people rush to do something, it is the leadership from everyone that puts the checks and balances required in the processes to ensure the right thing is done. For every change, including but not limited to what artificial intelligence brings, it is not about whether you like that change or not, but it is about the rate at which we adopt it successfully. In a couple of sessions, there were experts referring to cases where the ChatGPT based solution was not successful because there was not a clear business case, and that leadership and AI governance were mandatory for AI to be successful ever. We talk about business case as a strategy document balancing the benefits with the risks and how the strategy aligns with the vision (that is from an "as is" state to the "to be" state). Such a business case is not made up of just plain technical experiments without a solid use case to support the business. 

Furthermore, the closing keynotes focused on how 'advanced technology' does not necessarily mean technical elements alone but require strategic considerations for legality and ethics. Embedded deeply in these thoughts is the need for the leadership (not just the people at the top but also the middle management such as product, project, account, program, portfolio, process, technology, HR, etc.) to partner, engage, collaborate and knowledge-share with multiple stakeholders garnering support for the strategy and vision in the business case. This may additionally involve how to crowdsource fund differentiating between investment and funding schedules while simultaneously managing the in-house talent for capacity, transition, and succession planning! I believe if people are not engaged to lead and manage their processes, technology alone will not yield a solution. And, if we don’t think this way, we are not managing risks effectively and efficiently. Don't wonder why quality suffers in this case!

These thoughts are much more than just focusing on Agile and DevOps thinking as part of AI based experiments baked into iterations and spikes. I firmly believe that the ways of working are integrating two big frameworks in today's digital transformation. This integration involves both the middle management frameworks (like portfolio, program, product, and project) with the software development lifecycle (SDLC). So, instead of getting mixed up with plan-driven, adaptive, and hybrid ways of working that is equally important to both these frameworks, we should focus on "Product Application Lifecycle Management" (PALM, in my mind) that brings the frameworks together using multi-artifact traceability and auditability.  As I always say, enterprise business agility is not shifting left and shifting right alone but it is also about shifting up and down. That is how value flows - both vertically and horizontally. 

As a part-time assistant teaching professor at Northeastern University, I can tell that not every graduate courses in digital marketing, informatics, project management, software engineering, and business schools even mandate a good understanding of leadership. In fact, sometimes, project management graduates can't articulate the requirements of a contract or the procurement guidelines. Having trained many professionals for certifications furthermore outside the teaching engagements, I feel that even these tenured working professionals or those holding Certified Scrum Master can't understand the ingredients of servant leadership. 

We are on the cusp of a major change just like Internet or Telephony made waves once changing the landscape of how we work. We have one more opportunity to write history in leading the AI wave on how we work or will work in future. At this juncture, paying attention only to the technological aspects alone or yielding to comfort zones of known technical tools alone is a sure prescription for failure. If we know the principles of leadership, then, we can develop the right AI based solutions ensuring digital ethical principles like beneficence, non-maleficence, justice and autonomy are protected further ensuring that we monitor the AI's ability to explain itself identifying model drifts and hallucinations. 

Let us join forces learning about leadership first and technology next. Share your thoughts. 

Demystifying Technical Project Myths

I had the opportunity to facilitate training for a graduate class where there was an interesting discussion about defining technical projects. Now, the discussions were really inspiring, and we discussed several different characteristics such as novel use of emerging 4th Industrial Evolution related technologies playing a critical role in creating a unique product, service, or result.  At the same time, there were also some definitions of technical projects that need to be debunked. 

Now, one of the promising unbiased definitions of a technical project is that technology is used in achieving project goals that otherwise are not possible or would take time. It is imperative that we don't limit ourselves to the "technology" itself as the use of "information technology". In fact, technology is broadly defined as the application of scientific knowledge or a structured approach to realize an objective. For instance, brainstorming ideas can apply the concepts of design thinking, Delphi techniques, nominal group technique or many other forms such as the 6-3-5 technique (Rajagopalan, 2020). In these brainstorming approaches, a technical tool can be used but it is not always necessary. 

A few things that I would like to consider incorrect for defining a technical project are the following:

• Only technical projects have risks
• Risk is any uncertain event that can positively or negatively impact a project. So, it does not distinguish whether the project is technical or not. If the wrong hypothesis was chosen as the null hypothesis in a scientific project, it is a concept risk that impacts the project's schedule.
• Technical projects always have shorter timeframe
• This idea comes from the application of adaptive approaches (e.g.: Agile or Scrum) in technical projects. The reason for shorter timeframe in adaptive approaches to facilitate faster feedback from the users who may not always know what they want or may have changes in the upcoming iterations. Progressive elaboration has been present in project management frameworks for quite some time and the amount of time given for feedback facilitation is up to the project. 
• Using Jira makes the project technical
• While Jira is an example here, the use of any tool for requirements, test cases, risks, defects, and any other artifacts used in a project does not make a project technical. By that definition, any project documenting its goals and objectives in Microsoft Word or even notepad should call that project as a technical project.
• Non-Tech projects do not use technology
• As mentioned before, technology is the methodical approach of using a technique. A project may use a technical tool like soil analysis to evaluate if a small campsite can be strongly established for training local students in agriculture. A business information modeling (BIM) tool can be used to design the intricacies of a building even before construction begins. Whether we classify such projects are technical or not, we can't say non-technical projects do not use technology. 
• Non-Tech projects do not need special talent
• This is a biased statement thinking that special talent applies to people with advanced computer technology, data science, etc. A plumber, electrician, auto-mechanic, creative artist, musician, linguist, journalist, or market research specialist are all equally qualified special talent. Let us not forget the numerous specialty vocational schools that prepare people for many skills and competencies we take for granted. 
• Quality is not relevant in non-tech projects
• This is a biased statement thinking manual testing, automated testing, robotic process automation, and several other quality control and quality assurance related professions that has emerged. Quality is a function of risk (Rajagopalan, 2023) and wherever there is a project, there is risk. So, to say that quality is limited only to technical projects and furthermore not relevant in non-technical projects is losing the foundations of total quality management principles.
• Cost is not relevant to agile projects
• This is a false thinking primarily because people don't incorporate cost-based decisions in their usual iteration/sprint planning. There is a cost to every iteration (Rajagopalan, 2019). Most often, people are not working freely in most of the professional projects except in the volunteer settings where people volunteer their time. Even in such cases, the opportunity cost of working on a feature that is less customer focused than the feature the customer wants is always at the epicenter of MVP (Minimum Viable Product) discussions as part of risk-adjusted prioritization in product planning. 

Thoughts? Love your comments.

References

Rajagopalan, S. (2020). Alternative Idea Generation: 6-3-5 technique. https://agilesriram.blogspot.com/2020/01/alternative-idea-generation-6-3-5.html

Rajagopalan, S. (2019). Agile iterations also involve cost. https://agilesriram.blogspot.com/2019/04/test-post.html

Rajagopalan, S. (2023). Quality is a function of risk. https://agilesriram.blogspot.com/2023/03/quality-is-function-of-risk.html

Servant Leadership: Demystify the Agile Scrum Scaled Agile misconceptions

Repeatedly, I kept hearing people that I tutor, train, and coach as well as people in the Agile, Scrum, and Scaled Agile communities like SAFe mentioning the role of a scrum master, agile coach, or Release Train Engineer is to be a servant leader. On multiple occasions, I asked what they meant by being a servant leader or if they could name the ten characteristics of a servant leader. Frequently, however, people mentioned that they should guide the team, manage the backlog, and align with value stream mapping, etc. Is that what "Servant Leadership" is? No. Never once have I heard anyone clearly articulate the ten characteristics of the servant leader. 

So, what is the Agile, Scrum, and Scaled Agile communities preaching? Does attending a Scrum Master certification or accruing multiple certifications in this space make one a competent servant leader? If so, there must be so many competent servant leaders changing the world and not thinking of the team or the organization alone. Servant Leadership is not just lip service to the team or business ideas like value, benefits, outcomes, etc. 

In fact, if you look at the original proposal by Robert Greenleaf (1977) on Servant leadership definition, it provided a new way of looking at "leadership." Greenleaf asserted that "The best test is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?" (1977/2002, p. 27; Spears, 2010). Furthermore, Greenleaf asked servant leaders to evaluate their "leadership" effect on the least privileged society on whether the society at large will benefit not be further deprived of the benefits they deserve?  

While I was leading one of the projects early in my project management career in 1998, I asked in one of the status meetings what else I could do for the team. My manager, Beth Hokanson, suggested that I instead train myself to ask, "how may I help you?" She was not a Certified Scrum Master! But she enabled me to think differently. I observed her in many initiatives, such as the Y2K program, walk the talk. Such ideas of promoting one to think differently (individual consideration) providing guidelines such as asking to investigate project management certifications (intellectual stimulation), giving 1-1 coaching at times when I had some challenges (inspirational motivation) are the reasons why I look up to her (idealized influence) even now when I am not in 'constant contact.' These are the foundational principles (4 I's) of the Transformational Leadership for scrum masters, product owners, and project managers. 

Depending upon the extent of maturity and the level of guidance required, situational leadership will be the next one to consider for scaling agile and scrum in organizations. Situational leadership considers the extent of direction required and supportive behavior distinguishing four styles of leadership to practice. This includes directing, coaching, supporting, and delegating. This approach is contingency based and hence extends the transformational leadership (4 I's) for Program Managers, Chief Scrum Master (for SoS) and Team Level Coaches. 

But, if one thinks about these powerful thoughts Greenleaf advanced, it starts with 'servant' first! That means, one should exercise transformational leadership at the team level to make them become better versions of themselves as well contribute towards the organizational objectives! Yet, only when one thinks beyond the team and the organization. The focus should not be on how their product serve the community but how they serve the community. This is where their ethical obligations further carry them forward into the larger society (beyond corporate strategies) into local or global leadership. Writing books, blogging to share their stories, speaking in communities, and volunteering are examples of how they carry out the mission. For instance, connecting with 'beneficence" (effect on least privileged society) and "non-maleficence" (will they be deprived of the deserving benefits?) are examples of how servant leaders can think of the larger society in the solutions they design (Rajagopalan, 2020).   

Spears (2010) synthesizes Greenleaf's (1977/2002) thoughts of the ten characteristics of the servant leader. 

1. Listening: Here, it is not listening to respond but listening to learn, differentiate said and unsaid things (Rajagopalan, 2017) and self-reflect with a goal towards improving oneself.
2. Empathy: Covey (1987) already emphasized "Seek to understand before being understood" and Empathy therefore is action oriented. It is not feeling sorry for something but taking actions to leave the world in a better place than what you found. 
3. Healing: Being able to connect with oneself is paramount to managing others and leading society. One can find connections with Emotional Intelligence dimensions here. Being able to forgive oneself and not linger in the post purifies one's mind to see the world differently. As the old saying goes, "we all see the world not the way it is but the way we are!"
4. Awareness: Bringing thought leadership and market awareness together, they think beyond the status quo and integrates ethics and values in the decision-making. 
5. Persuasion: Social scientists discuss the various levels of power that the project management community also adopted (Gemmill & Thamhain, 1974). These power levels include formal (legitimate), reward, penalty (coercive), expert, and referential powers. One's ability to establish the required trustworthy relationships makes their expert and referential powers persuade others (especially as they lobby the organization and the stakeholders in the society for a larger cause).
6. Conceptualization: Delivering the right solutions the right way at the right time is a critical consideration for servant leaders who both think strategically outside the box (has a huge foresight to dream BHAG) but also focus on tactical operational excellence. 
7. Foresight:  Servant leaders, by their very nature, are comfortable in the VUCA world continuously learning from experiences and still with a childlike curiosity. The serenity prayer "Give me the serenity to accept the things I can't change, the courage to change the things I can, and the wisdom to know the difference" comes to my mind in defining this characteristic. 
8. Stewardship: Standing on top of all the previous characteristics, stewardship is 'leading the world' by 'walking the talk' for the larger society! Without ethical guidelines baked into one's character, it is not possible to be a steward!
9. Commitment to People's Growth: This is where I said servant leaders go beyond lip service by committing themselves to everyone's growth. This is also the reason that the transformational leadership is the platform that is integral to servant leadership because practicing the 4I's in the microcosm of a team makes them excel in practicing them well in the macrocosm of the society as the situation warrants. 
10. Building Community: As the popular saying goes, "Change yourself, and you will change the world," I believe servant leaders change the world by creating, building, rebuilding, and empowering communities. Everyone is responsible for shaping the world that we live in.   

So, servant leadership is a lot bigger than managing the scrum team or product backlog. It truly brings the best in us every day towards the betterment of the work life, home life, and the larger society!

What are your thoughts? Please share.

References

Covey, S. (1987). The 7 habits of highly effective people. New York: Simon & Shuster.

Gemmill, G. R. & Thamhain, H. J. (1974). The effectiveness of different power styles of project managers in gaining project support. Project Management Quarterly, 5(1), 21–28.

Greenleaf, R.K. (1977/2002). Servant-Leadership: A journey into the nature of legitimate power and greatness. Mahwah, NJ: Paulist Press. 

Hersey, P., & Blanchard, K. H. (1969). Life cycle theory of leadership. Training & Development Journal.

Rajagopalan, S. (2017). Listening with Eyes. https://agilesriram.blogspot.com/2017/04/listening-with-eyes.html

Rajagopalan. S. (2020). Artificial Intelligence Solutions: Four Considerations extended from Digital Bioethics. https://agilesriram.blogspot.com/2020/09/artificial-intelligence-solutions-four.html