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. 

Barista Language: Communication Lessons from Local Coffee Shop Visit

I was spending my vacation with my son traveling through places in Colorado. We stopped by a local coffee shop for a little break and supported the local economy instead of the franchise shops! I ordered a regular black coffee and got a Mexican strong roast coffee. It was not Americano. I said that this is not what I ordered, and the shop asked for what I needed and gave me an alternative. As I started to sip my coffee, my son mentioned that I assumed about what a regular coffee meant and should learn about the barista language to order coffee. 

"Barista language" echoed in my ears loudly! As part of the people management aspects, I always used to say, "Communication is not what you say but what the other person understands!" (Rajagopalan, 2018). I often emphasize them in my training about managing stakeholder engagement by push, pull, and interactive communications in formal and informal settings relating to both verbal and non-verbal clues. But my thoughts in all these areas were implicitly focused on formally recognized scripted languages used by people to speak and write! Hence, I missed that connection to the glossary of terms that people use naturally as part of their business.

For those that are not familiar, coffee could be served as "Latte, Caffe Mocha, Iced Coffee, Red Eye, Americano, Cortado, Cold brew, Cafe con Leche, Cappuccino, Caffe Macchiato, Flat white, Pour over, and Long black." For your information, this is not the entire listing! Every type of coffee listed here has a different way of preparation, different origin of beans, different types of mixes, etc. Where is "Regular" here that I asked of the Barista? I assumed "Regular" is always the standard Americano! As I pondered over what my son was trying to emphasize, "Coffee is like a culture with each variation being a tribe of its own!" Naturally, therefore, there is a Barista language. No wonder the "Regular" that this coffee shop served was local to their culture and business! I am sure the same can be said for tea, wine, and other hot drinks. 

This is a new learning twist for me! I have always described communication as not what you said but what the other person understood (Rajagopalan, 2017). Unlike many that may think that this thought process may be aligned with people's personality, I based my thought mainly on people's big picture vs details mindset, the attention span orientation, and their emotional connectivity to the topic! While the personality instruments, such as the most popular MBTI and DiSC are reliable and validated, it is an individuals' self-scoring mechanism. People change and so does their personality! So, if people use these instrument's labels, then, they may bring their bias that may not characterize others.

For instance, while I was studying in India, I never talked with others because I came from a Tamil instructional medium. I felt it was difficult to put my thoughts in words and embarrassed to speak due to the inability to speak and respond. Naturally, I felt like an introvert, but I changed to be an extrovert.  I feel like an ambivert because that level of quiet thinking is required for big picture abstract thinking (without which I couldn't have completed my PhD, pursued several certifications for my growth, or supported a PMO for 10 years) but lobby with many stakeholders and regulators for numerous projects and initiatives.

Yet, with all this understanding, how complacent sometimes I have been! How complacent and sometimes reticent people can be when they lack some of this understanding and fail to make deeper connections! I understand Risk means Hazard, Harm, Issue, Impediment, Obstacle, Blocker, etc. Depending on business, each sector comes up with its own language specific to that company. Let us practice in real life how to do this as I will try my best moving forward. Yes, communication is not  about what you think and say but what others perceive and understand! Learning is fun! Continuous learning is exciting!  Thanks to my son reemphasizing this thought!

Thoughts? Anyone want to express additional insights on? I am sure there are tea aficionados and wine connoisseurs.  Let us enrich communication with languages yet to be recognized formally or not yet adopted widely!

References

Rajagopalan, S. (2017). Organized Common Sense. Outskirts Press.

Risk Management: Birds' Eye View of some Standards and Regulations

I have been doing management training for several years preparing professionals in multiple industries for their career certifications and corporate training as well as mentoring some professionals. Through all these interactions and my personal desire for viewing standards and regulations from the lens of risk management, I have been exposed to some ISO standards and some regulations. At the same time, it has also become increasingly clear to me that many professionals are not aware of these standards and regulations. So, as I wrapped up another PMP session, I decided to capture some of these standards and regulations. 

ISO Standards

1. From my own understanding of the standards and their implementation in multiple industries, I feel some standards are universally applicable to multiple industries. I am calling these standards "core" standards. Such standards include ISO 9001 on Quality, ISO 27001 on Information Security, and ISO 14001 for Environment considerations. 
2. The core standards may not be sufficient for certain industries and "additional" standards are required to put in place guidelines and guardrails to support projects, programs, and portfolios to support the industry specific compliance to operate as a business to serve their targeted customers. For example, the ISO 28005 for giving electronic port clearance before a ship/cruise leaves the port. I call these standards as "additional" standards mandatory for that industry.
3. Furthermore, some reference standards give clearer guidance for multiple industries to benefit from overarching principles. The exact choice of guidance applicable may vary from one industry to another and therefore serve as "supporting" the companies in those industries depending upon the specific products and services. The ISO 31000 gives the risk management fundamentals with many techniques but not all techniques (such as the Fault Tree Analysis may not apply in small enterprises focusing on IT software products) may extend to all the small, medium, and large enterprises.  I call them "supporting" because they serve as an additional reference. 
4. The core and additional standards may act as a de jure standard (i.e., required legally). Some of the additional and supporting standards may act as a de facto (used as a default best practice guideline) standard. 
5. When I list "Multiple" in the "Industries" column, the appropriate standard can apply to any industry, such as the IT, Construction, Telecommunication, Transportation, Manufacturing, Healthcare, Agriculture, Aviation, Event Management, Food Safety, Banking, Financial Services, Investment, Insurance, Automotive, etc.

NOTE: The "core", "additional", and "supporting" are just my own reference classification to guide aspiring professionals in their own industry to gain adequate knowledge as part of their continuous improvement! 

Here is my high-level summary of ISO standards for people to investigate. This table is not a complete summary of all standards in every industry. In fact, some of these standards have so many sub-standards that I will not be able to balance any justification if I go into any more detail. So, please consult the appropriate ISO standard or the appropriate standard body.

Standard	Description	My Classification	Industries
ISO 9001	Quality Management	Core	Multiple
ISO 27001	Information Security	Core	Multiple
ISO 14001	Environment	Core	Multiple
ISO 31000	Risk Management	Core	Multiple
ISO 45001	Occupational Health & Safety: Physical Risks	Supporting	Multiple
ISO 22301	Business Continuity	Additional	IT Industry
ISO 20000	IT Services	Additional	IT Industry
ISO 15288	IT Engineering Services	Additional	IT Industry
ISO 45003	Occupational Health & Safety: Psychosocial Risks	Additional	Engineering
ISO 28805	Electronic Port Clearance	Additional	Shipping, Cruises
ISO 50001	Energy Management Services	Additional	Energy
ISO 27701	Privacy Extension	Additional	IT Industry
ISO 26000	Social Responsibility	Supporting	Multiple
ISO 17025	Testing and Calibration Laboratories	Additional	Healthcare
ISO 13485	Medical Devices	Additional	Healthcare
ISO 22000	Food & Safety Management	Additional	Restaurant and Food Safety
ISO 37001	Anti-bribery Management Services	Supporting	FinTech
ISO 20022	Electronic Data Interchange	Supporting	FinTech
ISO 20121	Sustainable Events	Supporting	Event Management
ISO 14971	Risk Management for Medical Devices	Supporting	Healthcare
ISO 15854	Aircraft Equipment	Additional	Aviation
ISO 17944	Banking Security	Additional	Banking
ISO 12812	Mobile Financial Services	Additional	Banking
ISO 15782	Certificate Management	Additional	Investment Services
ISO 17989	Agriculture Tractors and Machinery	Additional	Agriculture
ISO 22002	Food Safety & Farming	Additional	Agriculture & Farming
ISO 22005	Traceability in the Feed and Food Chains	Additional	Agriculture & Animal Safety

Additional Industry Standards 

 While the above ISO standards are a good reference for the global community, there are also specific standards from other non-profit standards issuing organization (e.g.: IEEE, ANSI) and government entities (e.g.: Department of Defense, Food & Drug Association, Federal Trade Commission, etc.). Given below are some of standards issued by these organizations (The following is neither a complete list nor presented in any priority order). 

• CMMC – DoD’s Cybersecurity Maturity Model Certification (CMMC) is a standard proving risk management structured designed to ensure defense contractors are complying with the current security requirements while dealing with public information 
• NIST CSF – National Institute for Standards and Technology (NIST) has many standards and is frequently known for the NIST Cyber security framework (CSF), which is a risk driven quality management standard for private firms to improve their processes and products while focusing mainly on maturity of security related processes 
• CMMI – It is a Software Engineering Institute’s (SEI) structural quality guidance, called Capability Maturity Model Integration (CMMI) with multiple levels, targeted at the processes and products. Its focus is not only on security but also on overall organizational processes and policies. 
• SOC2 – Has a series of audit controls from the American Institute of Certified Public Accountants (AICPA) on a company’s system and organization controls (SOC) as part of their internal risk assessment and treatment plans. SOC1 controls are mainly on financial controls while SOC2 controls are on CIA triad as well as security and privacy controls. 
• FedRAMP – It is a US based Federal Risk and Authorization Management Program (FedRAMP) focusing on standardized approach to security assessment, authorization and continuous monitoring for cloud related products and services. 
• FIPA is an IEEE Computer Society standard for Physical Agents and similar agent-based technology interoperability. 
• COBIT represents a set of control objectives for information technology from an international association on computerized security governance (ISACA) and is prevalent in many industries. 
• ITIL (Information Technology Infrastructure Library) represents a collection of service delivery guidelines as a library for the entire lifecycle of any IT services within a company. 
• PCI DSS is a set of data security standards (DSS) for the payment card industry (PCI) to address vulnerabilities for point of sale (POS) devices, mobile devices and computers, wireless hotspots, web shopping applications, and transmission of data. 
• Six Sigma is a framework of qualitative and quantitative tools and techniques to aid quality from an operational excellence perspective feeding prescriptive and predictive data analysis.
• DICOM represents a set of digital communication (DICOM) standards for the level of encryption required for data transmission and storage for PACS (picture archiving and communication systems) systems used for medical diagnostic images.
• PMBOK is a collection of business processes governing the management of projects, programs, and portfolios from the Project Management Institute for unique delivery of products, services, and results in any industry or organization.
• PRINCE2 is a collection of business processes governing the management of projects, programs, and portfolios, originally started by the UK government and owned currently by Axelos focusing on projects in a controlled environment.

Regulations

In addition to the standards discussed so far, there are regulations. Like standards, there are too many regulations. Given below are a few for consideration

• HIPAA - Health Insurance Portability and Accountability Act to protect patient health information
• SOX - Sarbanes Oxley Act responsible for internal and disclosure controls
• GDPR - General Data Protection Regulation from European Union governing the privacy rights of individuals
• CCPA - California Consumer Protection Act governing the privacy rights of individuals
• TCPA - Telephone Consumer Protection Act amended to protect individuals against unsolicited text message, robot calling, do not call registry violations, etc.
• COPA - Children's Online Protection Act governing the rights and responsibilities for protecting children from abuse and cybercrimes
• PDMA - Prescription Drug Marketing Act governing the responsibilities for fair balance, efficacy, indicated use, black box warning, and adverse event consideration 
• GAMP - General Automation Manufacturing Protocol in healthcare and allied industries governing the entire GxP (General Lab Practices, General Manufacturing Practices, etc.)
• CSA - Computer System Assurance related practices governing the design, development and testing of requirements (regardless of project delivery frameworks
• ASPICE - Automotive Software Process Improvement and Capability Determination to govern the detailed processes related to the original equipment manufacturers (OEM) whose products are included in the vehicles including but not limited to self-driving autonomous vehicles

Disclaimer: I am not a qualified professional to go into the details of any of these standards or regulations. I have captured them from my own limited understanding very briefly in this blog.  For all, references, please consult the appropriate ISO reference guides or the appropriate governing body for details. 

Do you think I should mention any other standard? Do you know of any industry that I can add to this standard? 

Parenting Lessons: Managing for Happiness while focusing on Relevance

I had a friend visiting my family. With a smaller child who was requiring some attention for food and later for occupying time, both my friend and I were readjusting to ensure that the child stayed happy. After the child had its food, we were showing the limited toys I had or the TV shows the child saw. The friend ensured that both the toys or the shows were relevant and age appropriate. After my friend left, I was thinking about how parents had that innate thought process of managing for happiness while delivering playful things with meaning!  We understand that people learn when they are happy. That learning is channeled for relevance for value. But how much do we practice this "Managing for happiness while focusing on relevance" in managing ourselves, our team, our products, etc.? 

If experience had taught me one thing, then, that is that we don't see things as they are, but we see things as we are. We put our own lens through which we see everything! This is the reason why people with scientific facts and evidence claim there is global warming and then others refute it because of extreme cold and snow in unpredictable places! The truth does not lie but we see the portion of the truth and not the entire truth! Good managers and great leaders see beyond abstraction and see where things could be! Whether it is people for skills and competency improvement or processes for experimentation and continuous improvement, nothing gets accomplished when people collectively don't collaborate and challenge themselves to share the need to be a part of something bigger than themselves. 

When a child is happy the learning occurs. The parent does not give everything the child wants but drives the focus for relevance. Somewhere along our professional journey, people become complacent with the status quo. This could be due to other life priorities or unwillingness to commit to learning! If learning stops, growth stops! If we want to grow, learning should continue! So, why are we limiting ourselves to what we can learn in the early childhood days but fail to continue that childhood like curiosity continuously in personal and professional lives? 

As I thought through this process, I thought that product management and project management as part of program and portfolio management should also look at people and process in a different light! "Manage people for happiness and focus processes for meaning" is my thought. If we ensure people are happy and the processes are meaningful (avoiding mura, muri, and muda), then, people will self-organize, challenge the status quo, and demonstrate leadership. If people are unhappy and processes are bureaucratic or confusing, people get demotivated, settle for mediocrity, and withdraw! Yes, there are many motivation theories (Maslow's Hierarchy, Hertzberg 2-Factor theory, McClelland Theory of Needs, Vroom's expectancy theory, McGregor's Theory of X & Y, Ouchi's Theory of Z) and each has a solid base on multiple fields with their proven track record. 

Suggested Step	Brief Explanation
Build for Happiness	Think of Ikigai that focuses on profession, passion, mission, & vocation) People are not going to be happy if one focuses only on profits, products, platforms
Manage for Innovation	Innovation need not be tied to roles & responsibilities.  Remember that good innovation management means roles & responsibilities are across multiple departments. Incorporate innovation in everything we do - incremental, continuous, and radical.
Accelerate for Learning	Don't promote a "fail fast" culture that compromises learning; instead, nurture the "fail forward" culture where learning thrives.  Don't build methodologies (company specific processes) that deters learning. Fail forward all the time. This is when you learn! Failure is too great an opportunity to miss learning.
Experiment for Customer	Relentlessly focus on customer. The world today is more about the customer's customers than just the paying client! Don't rush to product persona without creating a market persona! "Persona" is not people and so does not represent the voice of customer or voice of business. Actively Listen!
Play for Success	Promote "role" swaps. Don't just think in other's views but walk a mile in their shoes.  Incorporate alternative thinking (risk management) with explorative experiments  Explore childlike testing (unscripted, ad hoc) for quality from the beginning (this is beyond manual and automation testing)
Nurture for Growth	Create the culture that you want Operate as though your work is your own business Lead for transformation and not for transaction

In my humble opinion, none of these theories are adequately accommodated in today's middle management or executive leadership. The rush for quick wins to keep the business afloat seems to have seized the day. Ethics are compromised and design patterns are deprioritized to fit methodologies (note, I didn't say framework). To some extent, the middle management and executive leadership needs to hit the "reset" button and rethink how to manage for happiness and focus on processes for meaning." Tabulated above is my blueprint for these steps.

What are your thoughts? Would you agree? Add, Change or Modify anything? Share your thoughts!

Does Agile Mandate CICD? Lessons from ADO West 2023

I was presenting at the Agile DevOps West in 2023 on business agility. Twice during this conference, I heard people say another presentation where they heard people say that continuous-integration and continuous-delivery (CICD) is required as part of the DevOps and teams are not practicing agility without implementing the CICD.  I feel that these are clear misinterpretations of how Agile is still misconstrued and how the principles of Agile and DevOps frameworks are viewed improperly from the technical lens of CICD. 

First, Agile is about self-organized team empowered culture adapting to change, experimenting with innovation, failing forward, and focusing on value maximization. When Takeuchi and Nonako (1986) first laid the foundation for Scrum, much before the Agile Manifesto was ever written, their focus of new product development was not isolated to IT industry or software development.  However, one of the biggest issues with Agile is that all the 17 contributors were men and came from IT industry representing very little diversity. Their myopic thinking and ignorance can therefore be felt in three areas when they limited Agile to Software.

1. Opening the Manifesto with "We are uncovering better ways of developing software by doing it and helping others do it."
2. Including a statement, "Working Software over Comprehensive Documentation" in the Agile Manifesto.
3. Including the principle, "Working software is the only measure of progress" as part of the 12 principles.
4. Including the principle, "Deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter timescale" as part of the 12 principles.

In my webinars and training, I question these statements. If you replace the word, "software" with "workware" (a term I coined indicating that workware could be software, hardware, firmware, healthcare, Construction contracts, FinTech processes eliminating overhead and waste), the statements do work fine to represent agility. These are the reasons why agility can be applied to individual career management and at home, religious places, and other industries where software is not part of their work at all. While it applies well in software development, it is not limited to software development. In fact, I have applied principles of agility outside of software development in a Theatrical context (Rajagopalan, 2013) and have practiced it at home.

Now, let us look at CICD. As part of the V-Model, any solution developed goes through various stakeholders that shape the solution. Clear and concise representation of the requirements by the business analyst, design of the overarching architecture by system analyst and system engineer, the development of the solution by the engineer. Testing therefore is checking at multiple levels to check for solution developed and system designed against the requirements requiring multiple levels of testing itself. The idea is to minimize waste by progressively testing every increment to the solution and ensure that the increment is a good candidate for deployment. Here is where a few principles must be kept in mind.

Continuous Integration (CI) is required to ensure that every solution increment is integrated and regressed with already working and previously released functionality. This aspect is the first area of CI to ensure the new code has required boundary checking (no uninitialized variables, no memory leak, all code paths are covered) in addition to running automated test cases confirming all previous functionality so that the automation tests can run on the changes. 

Not all new code can be deployed to a production environment from CI functionality. Many reasons, such as multiple staged environment (like test, staging, pre-production, and production) may be required before additional tests like penetration testing and load testing may be mandated. Some industries may require a special group to handle validation as a separate activity outside of quality control, such as in healthcare and life sciences, for performance qualification (PQ handled frequently by the QC team), Operational Qualification (OQ) and Installation Qualification (IQ) that may be handled by a validation team and/or installation team appropriately. Therefore, CD may also mean continuous delivery to other environments in a linear pipeline. So, Continuous Delivery precedes Continuous Deployment. 

Furthermore, even if the continuous delivery succeeds in all the environments or the validation (OQ, IQ, for instance), the new increments can't be released. In some organizations, such as in pharmaceutical companies, new increments cannot be released to production until approval to distribute (ATD) is provided from the OPDP (Office of Prescription Drug Promotion) after medical, legal, and regulatory review and approval. Any functionality released to production prior to this ATD (sometimes called AFD - Approval For Dissemination) is considered a violation of OPDP protocols. 

Alternatively, it is possible that multiple teams are working together. So, it is possible that an additional level of release level testing of all the functionality consolidated from each team's outcomes will have to be assessed. These are called single cadence release at the release level (containing multiple iterations from multiple teams). 

When you factor all these thoughts of why CI is required and the various instances of CD (continuous delivery and continuous deployment), the CICD itself is focused on the continuous improvement (which is also abbreviated sometimes as CI) of software development life cycle processes. So, CICD is supporting agility, but agility does not require CICD at all as agility is not restricted to software development in the IT industry. 

Now, let us extend the discussion to DevOps. The fundamental principle behind DevOps is also a team-based culture focused on collaboration, data-based decision-making, customer-centric decision-making, constant improvement, responsibility throughout the lifecycle, automation, and treating failure as a learning opportunity (Roddewig, 2021). The DevOps institute (n.d) itself proclaims in their CALMS (culture, automation, lean, measurement, sharing) these principles outlining DevOps as a team-oriented culture enabling framework. While CICD is part of DevOps infinity cycle to have the delivery team and the infrastructure team to collaborate on their collective accountability, CICD is only one part of the DevOps framework. 

When all these ideas are integrated together, let us tell the right story. Just because a team does not use CICD or deploy increments to production frequently and directly after successful CI, it does not mean the team is less agile. Agile and DevOps serve as two book ends including Continuous Integration, Continuous Delivery, and Continuous Deployment. All elements of CICD support Agile and DevOps but Agile itself does not mandate CICD. 

References 

DevOps Foundation Blueprint (n.d.). DevOps Institute. https://www.devopsinstitute.com/certifications/devops-foundation/

Rajagopalan, S. (2013). Agility outside of Software Development: A case study from Theatrical Play. https://agilesriram.blogspot.com/2013/05/agility-outside-of-software-development.html

Roddewig, S. (2021). 7 Principles of DevOps for Successful Development Teams. https://blog.hubspot.com/website/devops-principles

Takeuchi, H. & Nonaki, I. (1986, January). The New New Product Development Game. Harvard Business Review, 64(1), 137-146.