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.

Ingredients of a Growth Mindset: Connecting with Movies

I was watching a few movie clips to pass the time after a long week. And I watched the Harry Potter and Sorcerer stone clip on how Harry Potter was chasing one of the flying keys among many other masquerading keys. I had an idea at that point about having not one key but many keys that must work together to unlock the door of "Growth Mindset." In Lean framework, we categorize the growth mindset as the ability to learn about anything required by learning from failure, growing from challenges, and focusing attitude and efforts towards continuous growth. 

Inspired by this movie clip, I thought of various attributes of a growth mindset. In a fun way, I brainstormed with my sons on what growth meant to them in their school and career. I discussed some of my ideas with my wife and children.  Interestingly and unknown to me, I came up with eight different attributes that seemed to follow a pattern that were alphabetically sequenced. Now, I engaged with some creative fun to model these attributes as a key pointing towards the center (if the key looked like a carrot or radish, that demonstrates my creative ability 🤣) I added five concentric circles. Think of them as the Likert-5 scale with 1 at the outer ring and 5 being at the inner ring. The idea is that all the keys must be locked in simultaneously towards the inner core for growth to completely materialize.

Dr. Sriram Rajagopalan's depiction of Eight Keys to a Growth Mindset 

Attitude is having that "Power of Now" contagious enthusiasm. I am not saying it is being always optimistic but being a realist to "practice the choice to see the brighter side of things" while "mitigating the risks or blind spots" (After all, isn't that what the Johari Window talks about without mentioning the word "Risk!"). As you can see, one's attitude is a function of their ability to recognize that failure is a steppingstone to success. It is like that "Moana" who chooses to fight!

Balance is having the emotional stability to "continuously play both yin and yang to be the best one can be." That is, have the delicate physical, mental, emotional, and spiritual state of mind. It is a demonstration of your practice of choosing the right attitude every day. True that life gets in our way and no plans work out as planned. Balance is recognizing this inner need! It is like that Po in Kung Fu Panda managing to find "inner peace" or "Aladdin" figuring a way out calmly when Jaffar locks him in a cave. Robert Schuller calls it, "Tough times never last but tough people do!"

Commitment is "following up and following through with actions to deliver results." (Please follow my blog on what follow-through is and how it differs from follow-up) It is laying the foundation with training, having mentors and coaches, facilitating and practicing walking the talk. Commitment derives from attitude and balance. Commitment shows character as we put SMART plans to grow and be an example for others. Woody in Toy's story demonstrates commitments towards his other team toys even when the going gets tough. At the same time, Woody demonstrates the right attitude when necessary (when other toys need help) and demonstrates the balance to keep Lightyear in check on his mission.

Divergent is having that "open mindset towards alternative thinking" (T, Pi, V, E/M shaped skill development). Concepts like design thinking and system thinking require one to have a big picture mindset. Our ability to grow will be limited if we are comfortable with what our strengths are. The longer we practice this "comfort zone" approach, the sooner our strengths will become our weakness and threat reducing or removing the opportunities. Be comfortable with discomfort and that is the only way to guarantee success. I always say that the best way to guarantee my stability is how I eliminate myself by leaving behind a legacy while seeking new ways to serve. Edna from Mr. Incredible exemplifies creating suites that best meet the super character's needs with divergent thinking applying multiple experiments.

Empathy is showing that we care! Empathy is demonstrating our commitment (action) towards causes that matter as well as people that matter! It is the "Pay it Forward" (which is a movie by itself) mindset that demonstrate not only divergent mindset towards people. Who else but Cinderella can demonstrates such kindness and empathy with actions to support all the animal friends! She is the perfect example of Empathy! Rafiki in Lion King must demonstrate that empathy and seek Simba out! Everyone needs to empathetically look out for others. Don't show sympathy as part of post-mortem but demonstrate empathy as part of ongoing lessons learned!

Focus is letting "distractions not impede commitment to actions!" Learning from mistakes and applying fail-forward thinking taking responsibility for actions are traits of focus. Not multitasking but getting jobs done even when risks and challenges throw a wrench! Po demonstrates continuous learning from every failure (although he needs his team to keep his balance) and Master Shifu learns from his mistakes that his teaching has to be modified to teach Po.

Global thinking is thinking beyond the local constraints and limitations. It is looking at the macroscopic impact ethically and morally rather than conventional limitations. It requires one to rise above the constraint with "divergent" thinking. While a "selfless" attitude brings a combination of "empathy" and "focus," the resulting commitment also requires one to "balance" themselves in their honest pursuit of results. Mulan may have left as an impostor to save her father from the King's orders, but the pursuit was due to a need to serve the entire country. She never gave up even when her identity was revealed. That's a commitment to global thinking.

Honesty is a commitment to character, integrity, and ethics. "You are your own benchmark, right!" Even when you do something wrong, it takes courage to stand up for your failure or lack of actions. Only then anyone can help you heal so that you don't feel continuously hurt. If Simba was honest about why he thought he was a failure from the stampede fiasco with Rafiki, would Rafiki have been successful? No. It is that commitment to character that stands tall as honesty.  Maui and Moana had to be honest with each other reconciling their fear and goals before they could emerge victorious as a team.

As you can see, each attribute feeds on each other. If Kaizen or Continuous Improvement is important, all these elements are required! I am not talking about continual activities which are events that happen repeatedly which are transactional. I am talking about continuous where we can review, reflect, and do things differently. That is the seeds of Kaizen! But not all of us may be at the level we need to be to lock into the inner core and regain our strengths and unlock opportunities. Whether it is a personal ambition or professional goal, all these elements should be at their maximum before they can be near the field-force of the inner core and bring the ikigai (the reason for existence or the famous questions like "what makes you happy?" or "what makes your heart sing?") to you!

What do you think? This was a fun exercise for me! Look forward to your thoughts on what other attributes I may have missed and how it may be unique and different from any of the eight attributes. I am all ears! 

Disclaimer: All the characters in the movies are referenced only to make connections with the principles. The movies and the character names belong to their respective owners. 

References

Rajagopalan, S. (2018). Reflections on a Group Discussion: 4 F's of Success.  https://agilesriram.blogspot.com/2018/08/reflections-on-group-discussion-4-fs-of.html

Evolution and Revolution of Change Management

As I was in the last training session with my current project management professional training batch, I was discussing how change sticks within an organization. As I differentiate governance processes for managing changes within the context of a project or program related to introducing large scale change management, questions emerged on what is change management. Some members who had attended a 2-day Scrum Master class mentioned about ADKAR and another management learner discussed about Kotter's change management. 

And both these change management frameworks are good and relevant. While both ADKAR and Kotter's change management frameworks are powerful and relevant in today's organizational environment, the knowledge of the change management evolution can help understand how change is perceived, planned for, and implemented. One can then appreciate the richness of history in connections with both the influence and impact of change management framework. 

Dr. Sriram Rajagopalan's Synthesis of Change Management Framework Timeline

Year	Model Name	Brief Explanation
~1947	Kurt Lewin 3-Stage	Kurt Lewin (1947) used the sociology and social science  concepts to introduce a 3-stage process. These 3-stages are "unfreeze, change, and refreeze." Before change can take place, a period must be allowed where no changes are allowed, and change is internalized.  Then change takes place as employees show involvement. This leads to knowledge sharing, leadership involvement to support the experiments, and then plans are put in place to implement the change.  As change slowly sticks, more change may be required where time must be allowed for the new changes to be internalized before the cycle repeats. Lewin used the analogy of a block of ice to be unfrozen to become water and then the water put in desired containers to be frozen again into ice.
~1969	Kuber-Ross Change Curve	Elisabeth Kuber-Ross (1969) ap6roached change from how people on the dying bed teach about change.  This change theory comes from the medical field particularly in hospice and hospital care.  Ross introduced the Change curve to demonstrate how people process change through their emotional lens of nearing end of life or seeing their loved ones or patients approach end of life.  People process the emotions of shock, denial, and disbelief of death. This frustration may turn into fear or anger. Then, they accept the immutable reality and slowly commit to adapting to the required change. During the first two stages of shock or frustration, no amount of motivation or feedback will be processed (because they are not actively listening - emotions have taken over). Slow and steady support and constructive feedback will help in the next stages rather than rushing through change.  While the stages of the Change Curve are very distinct from this field, these concepts really are analogous to how changes to have been unfrozen (not introduced too quickly) in the first two stages and slowly introduced in the change (accept) and freeze (commit) stages.
~1980	McKinsey 7S Model	Starting around mid-1970's, Waterman, Peters, and Phillips (1980) from McKinsey (a consulting organization) introduced the first organizational change management framework.  The seven stages were (no order) are strategy, structure, systems, skills, style, staff and shared values.  Strategy related to firm's alignment of their resources and capabilities to create competitive advantage. Structure focused on the way the firm is organized to deliver value using hierarchical relationships and roles and responsibilities. Systems tied the business and technical infrastructure to realize the goals and objectives. Shared values emphasized the display of behaviors supporting the firm's mission and vision. Style highlighted how the company's leaders demonstrated an inclusive culture for leadership to thrive. Staff comprised of the capabilities, skills, and competencies as well as the firm's ability to manage capacity, transition, and sustenance. Skills showed the firm's ability to deliver work and evaluate performance improvements.
~1991	Bridges Transition Model	Bridges (1991) Transition model differentiates change from transition. It states that changes [anyway] happen to people. Transition, [however], is internal - it's what happens in people's mind when facing and experiencing change.  This model draws parallel with the Kuber Ross' Change Curve Model in terms of emotions felt as change is processed. The three stages in this model include Ending, Neutral Zone, and New Beginning.  In the ending phase, people feel frustrated, show anger, demonstrate low morale and productivity, and are worried about the future. They find it hard to lose and let go. But this ending phase must end before they can arrive at the neutral zone. They are not ready for change yet as they feel adrift and lost. More listening ears are required like the other models in this stage. As they begin to leave the neutral zone, they feel they are facing a new beginning. The promise of the future brings new energy and a willingness to learn. With support and feedback, the change begins to stick with their renewed commitment.
~1996	Kotter 8-Step Model	Kotter (1996) underpinned action-oriented steps for change to stick within an organization. It improves on 7S framework in that the steps are actionable.  The steps are cyclical and iterate progressively on small increments of change. (Perhaps why more Agile practitioners like this approach) The 8 steps in the same sequence include the following. They are self-explanatory.  Creating a Sense of Urgency Forming a Guiding Coalition Developing Vision and Strategies Communicating the Change Remove Barriers to Action Accomplish Short-Term Wins Build on the Change Make Change Stick
~2006	Hiatt's ADKAR Model	More frequently called Prosci's Model due to its adoption in Prosci, this model is relatively recent. The model is build in five stages. These include in the same sequence. Awareness - Creates conscious need for change (Similar to creating sense of urgency) Desire - Shows intent to participate and support change (Similar to forming a guiding coalition) Knowledge - Demonstrates the skills and competencies on planning for change (Connects with developing vision & strategies and communicating the change) Ability - Highlights the desired skills and behaviors to implement change (Connects with removing barriers, accomplishing short-term wins, and building on change) Reinforcement - Shows steps needed to sustain change (Connects with building on change and making changes stick).

Have I missed out on any model or misinterpreted any connections to models? Share your thoughts.

References

Bridges, W. & Bridges, S. (1991). Managing Transitions. Boston, MA: Da Capo Lifelong Books.

Hiatt, J.M. (2006). ADKAR: A model for change in business, government, and our community. Loveland, CO: Prosci, Inc.

Kotter, J.P. (1996). Leading Change. Boston, MA: Harvard Business School Press

Kubler-Ross, E. (1969). On Death and Dying: What the dying have to teach doctors, nurses, clergy & their own families. New York: Scribner, An imprint of Simon & Schuster, Inc.

Lewin, K. (1947). Field theory in social science. New York, NY: Harper & Row

ADKAR Model (n.d.)  Prosci. https://www.prosci.com/methodology/adkar

Waterman, R., Peters, T. and Phillips, J. (1980). Structure is not organization. Business Horizons, 23 (3), 14–26

Quality is a function of Risk

I was recalling the statement, "Quality = f (Risk)," in one of my PMP training sessions and one of them asked how quality relates to risk. The premise behind this thought was on the iron-triangle thinking that quality is controlled by scope, schedule, and cost! It seems like we have a lot of work to do still in understanding about risk and its impact!  

As this person was in semi-conductor space, I reasoned risk is like the hard-wired interrupt that takes precedence over soft logic in the way microprocessor operates. That got the attention. So, I continued to make a connection on the immediate topic of the "Cost of Quality" we were discussing and reasoned out the importance of risk.

Dr. Sriram Rajagopalan's rendition of Quality is a function of Risk

In the diagram above, I have presented the cost of quality made up of two important branches. These are the cost of conformance to avoid risks happening in the first place and the cost of non-conformance to address risks that have happened. 

• To avoid risks as part of the cost of non-conformance, the best approach is to practice the "wisdom of the ages" saying, "Prevention is better than cure!" Here we take proactive steps to ensure quality planning (as part of the Quality trilogy) includes preemptive measures. This involves building quality using quality assurance (QA) with process oriented and proactive steps to train people, have multiple documentation (caters to multiple modes of learning), the appropriate equipment required and the required amount of time to do things correctly (e.g.: right-sizing stories to fit into the timebox, risk driven development methods to prioritize). 
• The next step is to evaluate how well our controls are working by performing quality audit on the work (PM/PO owns the quality audit). Here, quality control (QC) comes from the delivery team that comes in with reactive and product-oriented methods like testing (product testing), inspection (Gemba Walks), etc. 
• Now, if the errors are released such as not missed compliance or security considerations or misinterpreted requirements, or other forms of requests like change request or enhancements are noted, depending upon the triaging process, these could be show-stoppers disallowing the user to realize the intended benefit thus risking value delivery. So, rework may be required, or products may be discarded (prototyping or physical products) as scrap. These corrective actions are adding more time and cost and increase the opportunity cost of people unavailable for improving the benefit in the current project (working on newer functionality) or other business initiatives. Time may translate further into budget risks as available funding may be depleted to pay for contractors and infrastructure.  
• Finally, if these internal errors were not caught and were released to the customer, they become escaped defects! This impacts now the customer's value delivery life cycle as our faulty products may be used in their product assembly or our faulty code may be impacting their applications built. These translates into liabilities for the company, Warranty claims (ongoing free support, recall for the products at our expense) and perhaps even the business lost to competitors. 

As you can see, there are various forms of risks that interface the quality assurance, quality control, and escaped defects side of the equation with some additional risks foundational to the entire quality function in the company through its projects, program, and portfolio functions. The sooner they are addressed (as noted in the green color), the lesser the expenses are. As time passes through this cost of quality function from left to right, the intensity and visibility of risks through corrective and preventive actions (CAPA) to the business is high (as noted in color gradient going to red). 

So, am I not correct to say, "Quality = function(risk)"? Share your thoughts.

Risk Driven Prioritization: Challenges to Prioritization Techniques

I have always felt that if value is the focus of prioritization, the value should be prioritized equally by the risks to delivery. In other words, engaging in powerful questions (Rajagopalan, 2015) helps a lot and this behavior is driven from the leadership mindset (Rajagopalan, 2013). When sufficient focus of risks to delivery or risks to non-compliance exists, value is not delivered as the benefits are not realized! Instead, we run into the challenges of techniques without understanding risks.

Given below are most frequently used prioritization techniques and a brief discussion on what they lack that should be factored if not done consciously. 

Technique	Description	Risk Thoughts
RICE	Uses four different variables (Reach, Impact, Confidence and Effort). Reach (R) is an estimate of the number of people that will be impacted. Impact (I) is an estimate of the extent of impact (like 5-high, 3-medium, 1-low). Confidence (C) is the team's confidence on the estimates given for reach and impact. Effort (E) is an estimate of time in the number of months. The formula is: (R*I*C) / E	On a positive note, it uses some level of analysis to compute the estimate. But this is a very ambiguous approach for the following reasons.  The scale used for R, I, and C are very arbitrary (somewhat ordinal in nature) There is not any data driven or risk planning on the number of people reached. Many organizations even find it difficult to quantify the reach and come up with a guess. Impact could be subjective in people's mind and there is no risk breakdown structure like explanation of what a 5-High is.  Confidence is also subjective and cannot replace the margin of error (or standard deviation). So, the result, while helpful, can't truly help prioritization.
WSTF	Weighted Short Job First addresses are somewhat analogous to RICE approach except that it uses different variables. It focuses on business value in terms of the cost of delay and job size. The cost of delay includes perceived Business Value (BV), Time Criticality (TC) and Risk Reduction (RR) (or Opportunity Enablement (OE). The formula is: (BV+TC+RR or OE) / Job Size	This approach has the same challenges as RICE but also improves on RICE somewhat significantly. It recommends the use of a Fibonacci type of scale for BV, TC, and RR/OE. That is an improvement compared to the ordinal type of subjective ranking.  Unlike RICE that uses a product of reach, impact, confidence, WSTF uses a summation.  Time Criticality is measured as sense of urgency without any due consideration for risks.  Risk Reduction or Opportunity Enablement is specifically listed here. Risk exposure scores are often a product of probability, impact, and sometimes detectability. So, adding risks do not help with true risk driven prioritization.
MoSCoW	Uses approaches like the Eisenhower Matrix. Uses four categories Must, Should, Could, and Wont (This is WONT, i.e., NOT do) to address prioritization. Must is associated critical element without which the project can't provide value Should is associated with important elements but not a must and can be deprioritized or postponed.  Could is considered non-essential or more of a nice to have enhancements or change requests. "Won't" is anything not going to be addressed now or soon.	All these four levels (Must, Should, Could, Won't) are subjective interpretations. Granted that there is some amount of categorization, but several ambiguities remain. The approach is biased based on subjective priority. There is no evaluation of impact (or severity). How are the relative priority between two Must items determined? Why is a Must Item a must? When will a Should Item be picked? As you can see, this approach is a good start but not a good one for prioritization at all. It only helps with a first level of categorization and is not the final level of prioritization. This is the reason why this approach is sometimes associated with Eisenhower Matrix which President Eisenhower used for decision-making on what he needs to address and what he needs to delegate!  Another technique I have heard is Yes-No-Not Now-Never. To me, this is analogous to MoSCoW and not much different.
Kano Model	This model uses delighters, performance, and basic as the drivers from a consumer market perspective. Basic features are those that are normalized and expected. Doing them does not give an edge but not having them will be a competitive disadvantage. (Similar to Hygiene factors in Motivation Theory) Performance features are those that are required. It is minimal expectations of the market.  Delighters are those features that people want to see or didn't expect to see! Doing them gives a competitive edge. (Similar to the Satisfiers in Motivation Theory)	This model is driven from the market research. Almost like a persona expectations of the market behavior. However, while it may serve as an external risk trigger, it does not quantify further (e.g.: deeper dive of PESTLEED, TECOP, etc.) and meet the individual risk driven considerations (e.g.: VRIO) for a product. Again, it is a good categorization for product backlog but does not help with prioritization of the individual items.
100-Points	This approach is an approach to engage stakeholders to prioritize when more than one is influencing or impacted.  Each stakeholder has 100-points to begin with.  Each requirement (or feature) is associated with a value that the team things will take to implement. (More like a price of a feature; hence this approach is also called 100-Virtual Currency Method) The stakeholders place their 100-points spread out on these features. A new cumulative sum is computed for each feature based on the stakeholder input. The highest value items are prioritized based on this cumulative sum (descending order).	This approach is fine but still has the challenge of how risks are communicated to the stakeholders and how much risks are factored by the stakeholders.  Bias and influence can help a feature be prioritized that the team can't handle or deliver.
Relative Prioritization	This approach is for the team to prioritize items already prioritized.	This helps with relative prioritization (for instance if two features are high, which one should be delivered first.)

As you can see, each technique has its own strengths and weaknesses. If it works for you, great! But risks are something that one must quantify and evaluate. In fact, I call such an approach to risk-based prioritization "risk driven development (RDD)". Here, the risks are identified, assessed, and evaluated with a risk exposure score. These risks are associated with requirements as well as the test cases (conformation criteria) as not all requirements are easy to test. Based on the sum of the risk scores on a requirement and test cases, the features can be prioritized. It is possible to use other methods in conjunction with this so long as risks are considered and there is a ratio level scoring mechanism included or at least a good risk breakdown structure included to avoid bias or subjective interpretation. 

What are your thoughts? Please share.

Rajagopalan, S. (2013). Essential Leadership behaviors for Agile Transformation. https://agilesriram.blogspot.com/2013/12/essential-leadership-behaviors-for.html

Rajagopalan, S. (2015). Client Management: The influence of powerful questions.

Model Based System Engineering (MBSE): Relating Systems to Value

As part of the product analysis methods, I was discussing with my project management training class when these discussions really made me feel that there is a lack of fundamental understanding on model- based system engineering (MBSE) and its relationship to value. Much of the value decomposition was conceived by the professionals in my training class relating to the product backlog breakdown splitting a product epic into separate components and subdividing them into features and user stories for MVP and MBI/MMF. The focus was of requirements analysis splitting stories into smaller chunks for estimation and delivery lost the connections to the model-based system engineering (MBSE) concepts, such as the system engineering, systems analysis, value engineering, and value analysis, and their tight coupling to technical subsystem interfaces for a simple, secure, safe, stable, and sustainable product. 

Some of the familiar concepts of model-based system engineering also pave their connections with the processes for procurement and agreement management, project enablement and related outcome management, technical management, and the technology related management itself. Such concepts can be found in the ISO 15288 on how system related processes are mapped not only in designing the system but also in designing the processes around the system (Hall, 2018), which is not the product alone but the processes around operations (which is a portfolio component), programs (which focuses on benefits management) and projects (which focuses on outcome management). 

The concepts of managing these processes within a software context can be seen in the capability maturity model integration (CMMI) and the processes of continuous quality management (both QC and QA) can be seen in 6-sigma concepts. Even ISO 9000 umbrella of the ISO 9001 series to total quality management espouse these processes related to both technology and management of technology to ensure quality in numerous standards and regulations (Rajagopalan, 2023). This is what is emphasized by the agile principle, "Business and Technical stakeholders must work together daily!" While each industry may create different models depending on the specific products and their impact on clients and customers, a few generic MBSE concepts apply in all the industries. 

The MBSE concept is analogous to the fable that I heard in India about six blind children touching an elephant and describing the elephant. If elephant is the system and the blind children are the various stakeholders, we are describing the system from what we think we see/feel. Security, for instance, has a different meaning for the technical team members compared to the end users.

For simplicity, let us define the model as a feature-box (functional requirements and non-functional specifications) that adequately represents the set of inputs that can interface requiring the model to prioritize and the set of outputs it will generate. The model's behavior is controlled by a set of complex rules that are manageable. This model now represents the system that must be viewed closely and from far! This requires the system architect not only to see the auditability of the system for diagnosis (such as behavior, but paths also taken and the trails left, considerations for gracious shutdown, etc.). So, how do the system analysis and system engineering differ? 

The system analyst will use a combination of techniques (e.g.: data modeling, interface analysis, data flow diagram, and alerts & event triggers) to refine the model! This is reviewing the model at a close distance. So, the system analyst frequently will consider using class diagram, functional decomposition, sequence diagram, network diagram, entity-relationship model, and deployment diagram as well as the total-quality-management (TQM) foundations like the flowchart, scatter diagram, checklist, root cause analysis, and histogram. But the system engineering discipline observes the model from a long distance. 

Therefore the system engineer focuses on interference defining the boundary of the system (where the system can no longer sustain itself to be valuable), behaviors that exposes the system's vulnerabilities (model is no longer safe or secure without subjecting itself for damage or causing harm to others). The system engineer then uses market analysis, business rules analysis, concept modeling, scenario analysis, risk analysis, state modeling, interface analysis, decision-modeling, Gemba Walks, workshops, focus interviewing, SWOT/TOWS analysis, benchmarking, and brainstorming further supplemented by TQM techniques like control chart and pareto charts. Please note that these are additional techniques beyond the techniques used in the system analysis.

Now, both the system analysis and system engineering concepts can be extended to the extent of benefit (value) derived by the users and the performing organization.  These values can be looked at from multiple angles. One approach is the approach that I normally recommend as custom value, business value, technical value, and process value (Rajagopalan, 2019).  The goal of these exercises is not only to protect the customers and business but also look at efficiency gains through the combination of both the process and technical value giving a competitive market value! When all these areas are reasonably protected, they also enhance the future value (that can be measured using ROI, NPV, IRR) of the product within the product portfolio. The short-term focus will be value analysis and the long-term focus will be value engineering. 

Another lens, that in my humble opinion, extends from the previous discussions is how the model is sustained and supported. From this lens, we can evaluate model from flow (hence Lean), governance (hence Change Management), behavior (Systems Engineering and Value Engineering concepts mentioned earlier) and decision-making (hence Risk Management discipline, Costing Principles, and Costs of Quality considerations). A few refinements are required here.

• Flow is often thought of as work progressing across various statuses. This is horizontal flow. Flow also should be looked at vertically between projects, programs, and portfolios and multiple systems or projects that must work together. 
• Change Management concepts extend in such vertical value flow in terms of risk management, decision-making, funding, and resource planning that happens in program management, PI planning in scaling agile approaches, etc. 
• Governance can be supported at a lower level with workflows that enable faster decision-making and system traceability & auditability. 
• Behavior can vary very widely depending on the organizational processes as well as the maturity/direction required by the team. Hence, it could range from as simple as time tracking, waiting time evaluation, burn rate as well as evaluating negotiation considerations, team health, conflict resolution, etc. 
• The decision-making can be supported by some of the governance considerations, but it could also transcend other work authorization systems based on extensive funding considerations (e.g.: Efficient Frontier, portfolio balancing, resource optimization, etc.). 

What else I may be missing in MBSE definition? Please expand.

References

Hall, D. (2018). Systems Engineering Guidebook. Toney, Alabama: Hall Associates. https://www.incose.org/docs/default-source/default-document-library/systems-engineering-guidebook---isbn-9780692091807bb88028572db67488e78ff000036190a.pdf?sfvrsn=365365c7_0

Rajagopalan, S. (2023). Risk Management: Birds' Eye View of some Standards and Regulations. https://agilesriram.blogspot.com/2023/08/risk-management-birds-eye-view-of-some.html

Rajagopalan, S. (2019). Requirements Management: A value mapping exercise. https://agilesriram.blogspot.com/2019/02/requirements-management-value-mapping.html