Strategic Frameworks beyond SWOT

I was having a great discussion about strategic frameworks with my family members and friends in India during my personal visit. Whether it is small scale product development or large scale initiatives, most of the references I heard were SWOT. Yes, SWOT is a good framework but I found that in my discussions no one had even aware of other frameworks that should be evaluated first before documenting their results in SWOT for discussion. 

SWOT Analysis (Strengths, Weaknesses, Opportunities, Threats):

o  Strengths and Weaknesses focus on internal factors.

o  Opportunities and Threats focus on external factors.

o  Provides a comprehensive look at a company's internal capabilities and external environment.

Other Frameworks

AFI Framework (Analyze, Formulation, Implementation)

o  Comprehensive: Covers the full cycle of strategic management from initial analysis to the execution and monitoring of strategies.

o  Structured: Provides a clear sequence of steps, which helps in systematic thinking and decision-making.

o  Flexibility: Can be adapted to different types of organizations and industries.

PESTLEED Analysis (Political, Economic, Social, Technological, Legal, Environmental, Ethical, Demographic):

o  Analyzes macro-environmental factors that can affect an organization.

o  Helps in understanding market growth or decline, business position, potential, and direction for operations.

TECOP

o  Technical Considerations

o  Environmental Challenges 

o  Commercial Constraints

o  Operational Excellence Thoughts

o  Political Influences

This is often considered in connection with the PESTLE.

BCG Matrix (Boston Consulting Group Matrix):

o  Stars: High growth, high market share.

o  Question Marks: High growth, low market share.

o  Cash Cows: Low growth, high market share.

o  Dogs: Low growth, low market share.

o  Helps in portfolio management by evaluating product lines and business units.

VRIO Framework (Value, Rarity, Imitability, Organization):

o  Analyzes a firm's internal resources and capabilities.

o  Determines whether they provide a sustainable competitive advantage.

Ansoff Matrix (Product/Market Expansion Grid):

o  Market Penetration: Existing products in existing markets.

o  Product Development: New products in existing markets.

o  Market Development: Existing products in new markets.

o  Diversification: New products in new markets.

o  Helps in identifying growth opportunities.

Value Chain Analysis:

o  Identifies the primary and support activities that add value to a product or service.

o  Helps in understanding cost advantages and identifying areas for improvement.

CAGE Analysis

o  Cultural Differences: Perceived differences within the home/host and within those demographics.

o  Administrative Considerations: The modus operandi in how work flow within multiple groups and companies

o  Geographical Distance: The distance geographically separating companies impacting supply chain, tax, trade, etc.

o  Economical Power: The power of the currency, gross domestic product, etc.

Blue Ocean Strategy:

o  Focuses on creating new market space (blue oceans) rather than competing in existing markets (red oceans).

o  Encourages innovation and value creation.

Balanced Scorecard:

o  Measures organizational performance across four perspectives: Financial, Customer, Internal Processes, and Learning and Growth.

o  Aligns business activities with the vision and strategy of the organization.

McKinsey 7S Framework:

o  Analyzes organizational effectiveness based on seven elements: Strategy, Structure, Systems, Shared Values, Skills, Style, and Staff.

o  Helps in ensuring that all parts of the organization work together harmoniously.

Porter's Value Chain:

o  Identifies specific activities within the business where competitive strategies can be best applied and where improvements in efficiency and effectiveness can be achieved.

In summary, SWOT is not the only framework but one of the frameworks. After all, strategy is about 'competitive advantage' and we current operate in a VUCA (volatile, uncertain, complex, and ambiguous) world. 

What can a Scrum member do when they have finished commitments but Sprint is not done?

Frequently, this question comes up in agile and scrum teams. And, it did come up with senior officer I was mentoring on agile practices. The scenario was that a team member had finished their sprint commitments and had capacity. The team member has also asked other team members about assisting in their work. The other team members were self-sustaining and were focused on their commitments and reasoned that breaking their commitments could only increase more context switching and delays. What should we do? 

To a large extent, this is a good situation because the team is self-organized and showing good signs of maturity. From a Bruce Tuckerman's team point of view, they are in a "performing" stage. But, should the team member waste their capacity? Let us look at a few scenarios. 

First, should the scrum master assign any task to fill the capacity? Well, the scrum team breaks the user stories into tasks. So, assigning new tasks to that member is not promoting self-organization. On the other hand, the scrum master should coach the individual to look for opportunities where they can add value. If the goal is delivering incremental value, then, what can they do? Updating documentation, refactoring code, taking training, and improving CICD processes are all examples where they can add value. 

Second, should the team member review the backlog and pick up user stories to add to the current sprint? Well, this is a two-part question that has different answers depending upon the business practice. Anyone following the Scrum in theory would advise that additional user stories can not be pulled into the current sprint that would endanger sprint commitment. If you parse this point, no work can be added that would compromise sprint commitment. That is true! But sprint commitment is by the team and not by an individual. If the individual has already asked the other team members to support on their sprint commitments and have no team member needs the assistance, then, sitting idle and wasting capacity is not going to add value! This is where the Scrum is also forward looking suggesting backlog refinement as an additional ongoing/continuous activity. So, the team member can rightfully review the backlog (which by the way should be prioritized by the product owner for at least two upcoming sprints) and more clarity from a customer, business, technical, and process stand point. 

A good product backlog should also have some experimental stories - not himportant now but may be in the future. Recall Scrum approaches also recommend the MoSCoW (Must, Should, Could, Won't) for prioritization. So, reviewing and perhaps even picking those research oriented spikes is definitely an option. Since not finishing them does not compromise the team member's commitment, unless of course their work is in the direct critical path of the existing sprint commitment of others, then, working on such experiments only add value. For instance, an AI based experiment to do things better or automating some work to improve CICD processes, etc. 

Finally, can the team member pick one of the prioritized stories and possibly begin working on them. Designing or developing on that user story is sometimes looked down upon because that work can not then make it to the current sprint. If work done on that user story not committed to the current sprint is proactively being worked on, only because the current team member does have excess capacity that the scrum team cannot leverage, then, such a proactive work can make it to the next sprint (because it is prioritized high already in the backlog) with a lead on the schedule for the next sprint. That is facilitating the delivery of working software faster! 

In summary, having excess capacity is an opportunity. Scrum is mainly about working agreements among the team members. It is an opportunity to look at these ideas and see how cross-training, documenting, role-playing, and experimentation can all be factored into backlog and agreements made when such opportunities arise. Wasting valuable resource time neither contributes to productivity or throughput and only contributes to waste (non-utilized resource is one of the lean waste). So, build quality more consciously in scrum.

Thoughts? 

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

Kanban India 2023: Reflections on Kanban Awareness

I had an opportunity to present a 90-min workshop on boosting business agility leveraging Kanban principles in the Kanban India 2023 conference organized by Innovation Roots in Bengaluru, India. This conference was represented by various types of people from many industries but mainly from project management offices and information technology professionals. So, it was not surprising for me to see the diverse roles of project manager, product manager, product owner, director or project management office, agile coaches, scrum masters, and a small percentage of resource managers and senior leaders. However, what surprised me largely was the complete unawareness of the Kanban principles by almost all the 30+ members that sat in my workshop across all these previously represented roles!

First, Kanban is not a framework or methodology! It is a method because Kanban can be adopted within any plan-driven or adaptive framework as well as the organization specific methodology adaptations of these frameworks specifically within their organizations! Without understanding these distinctions among framework, methodology, and methods, people have rushed to the same thought process of how they conceived waterfall methodology when the original author never even promoted the concept of such linear waterfall thinking (Rajagopalan, 2014). Instead, Kanban has been conceived as a set of cards organized in status-driven swim-lanes such as "To Do", "Doing" and "Done". 

Figure 1: Dr. Rajagopalan's synthesis of value flow

Contrary to popular thinking of Kanban cards in such statuses reducing the Kanban implementation as a tactile execution, Kanban has a set of principles that promote business level systems thinking among the team members for strategic value delivery. Since value itself flows both vertically across projects, programs, and portfolios (and hence the notions of benefit management in programs, value stream mapping in product management, and expanding these concepts with risk management in programs and portfolios), Kanban applied the lean manufacturing concepts combining managerial (efficiency) and leadership (effectiveness) with a concerted qualification efforts (efficacy) applying five important principles. Without all these five thoughts, business agility with both horizontal and vertical value delivery simply does not exist!

Figure 2: Dr. Rajagopalan's adaptation of Kanban Principles

First among these principles is the Andon thinking promoting the notion of team accountability through a transparent visual factory. While the Andon thinking emphasized team level ownership by allowing the team members to self-organize using the visual cards and queue buildups towards better documentation and training as needed to ensure cost of quality! 

This team accountability was supplemented with Jidoka that ensured people thought value delivery from an overall system (not just tactical cards like how people conceive of tasks and subtasks) but the combined influence of all these tasks towards benefits (requirements, specifications, design, quality, etc.). This "systems thinking" thought process also elevated people to relieve themselves of mundane tasks (for the sake of doing them - remember being busy is not being productive) by intelligent automation wherever possible. 

This simultaneous concept of thinking both from a systems perspective and automating mundane activities intelligently also was supported by teams and their line managers (hence project managers, product owners, scrum masters, agile coaches, managers) thinking of Heijunka bringing the resource optimization principles of reducing unevenness and minimizing overburden in distributing work for people or load with systems and processes. The entire notions of the total quality management (focusing on muda, mura, and muri) emerge from these Heijunka thinking for cost of quality!

As people owned the processes (means to end) that supported in delivering products (evaluating value for customers), the focus on Kaizen emerged on continuously improving the processes (simplifying documentation, training, reducing errors (Poka Yoke, for instance), risk management, etc.) and evaluating customer success factors and business benefits. This is when objectives and key results (OKR) were evaluated with the right level of key performance indicators (KPIs) along with built-in quality thoughts of critical success factors (CSF). 

Just to ensure that Kaizen thinking itself didn't apply to product and process increments in a monotonous way, the systems thinking was further advanced by radical innovations of continuous experiments. This thought process led to Kaikaku ensuring that everyone contributed researching market trends in augmenting business value by doing something innovative avoiding the notion of "this is how it is done here" (Kotter & Rathgeber, 2016)

As Kotter & Rathgeber (2016) very nicely discuss the using of meerkat colonies organizing differently to deal with emerging threats to their survival, it is pivotal to understand the principles of Kanban rather than bring it down to its knees by reducing them to a set of nice visuals (cards and swim-lanes) limited to the tools used! If all these principles are not understood and practiced, no tool or technology can help the teams to swarm, self-organize, and survive!

References

Kotter, J. & Rathgeber, H. (2016). That's Not How We Do It Here!" Plantation, FL: J.Ross Publishing.

Rajagopalan, S. (2014). Review of the myths on original software development model. International Journal of Software Engineering & Applications, 5(16), 103-111.

Music Performance: Reflections towards Change Management

I was very excited to attend my niece's solo music performance as part of her Music program graduation requirements. There were postures of the "Soul Quest" posted in many places outside the auditorium announcing her solo performance with QR codes for registering for the event. As I sat in front row in the theater, I reviewed the program schedule before the program began! Now, I didn't relate to the list of songs selected, the genre of emotions it invoked, and the time of the composers or the story behind those compositions. But I very much related to the multitude of things that happened as the program started with my niece performing on flute and singing in Western and Eastern styles. 

A music performance such as this program needs to be viewed from multiple angles. There must have been several discussions between the student and the teachers in selecting the songs to ensure that the songs were challenging, bringing the maximum out of the student. There must have been multiple rehearsals from the student personally and specifically staged performances before the teachers to confirm "go live" readiness. Throughout these processes are instances of change management initiatives demonstrating how people pivoted themselves. Not a single song was instantly selected, the iterative practice avoided, and approval granted. This is exactly how strategic initiatives are identified, evaluated, executed, and approved at various stages for both proactive and reactive change. 

Did this program only conclude with the song selection and practice? No! There were creative postures designed, a program title carefully selected, and the entire design and development process executed in parallel. Production of such colorful displays was further compounded by logistical complexities around where these postures can be displayed around the campus. Furthermore, there were digital media approaches to QR code generation, website for program announcements, and scheduling the campus theater for the graduation requirements. Every one of these needs had to go through many rounds of changes. I only saw the result, just like a project manager stages the outcome or the product owner approves the product increment! There were many other team members that staged this performance!

Then, the post-production processes like the post-deployment considerations or the operational excellence initiatives.  Were they left out in this music program? No! I saw people who were streaming the performance for online audience, people collecting the photographs others took for photo albums, and others, such as the teachers confirming the satisfaction and providing feedback.  There were also website updates about the program's success. 

So, the concepts of risk-based thinking towards delivering a quality performance satisfying stakeholders with the agreed upon scope within the confirmed schedule and cost considerations involving appropriate timely management of resources and procuring work to other subject matter experts were all evident! Little do people relate to the concepts of integrated change management in delivering projects such as this music performance! 

This is the reason why I keep mentioning project management principles are integral to everyone pursuing any degree so that they can excel in what they prepare themselves for! I was able to implement what I call Projecting Leaders of Tomorrow (PLOT) sowing the seeds of project excellence and also wrote the book, "Organized Common Sense". 

I believe we will see when we are ready. What do you think?

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.