Powerful Communication: Lessons learned from High School Essay Writing

As part of my projecting leaders of tomorrow (PLOT) initiative, I try to introduce the concepts of project management and agility to high-school students and sometimes non-project managers. One opportunity presented itself to me when a student approached regarding preparing to write a compelling essay for the scholarship. The student had some knowledge about the essay types such as argumentative, expository, narrative and descriptive styles but was still having 'writer's block'. I viewed this problem analogous to how many professionals communicate leaving the stakeholders to wonder what is being asked of them! Any artifact, project status report or graphical widgets, like essays written in school should focus on what is the outcome desired from the report, graph, or essay delivered. 

Let us first differentiate the four essay types. An argumentative essay uses credible research to develop a factual or evidence supporting opinion. For instance, "Did remote team environment exist before the COVID-19 pandemic?"  To some extent, this argumentative essay builds on a hypothesis or a thesis statement. Instead of asking a question, one can make a statement that "Remote team environment exist before the COVID-19 pandemic" and use research from credible sources to support or refute it. In statistical circles, we call this approach null hypothesis and alternative hypothesis where we use data to support the evidence. The difference in this argumentative essay is that we are not building statistical or empirical data analysis to support but to use insights and opinions using qualitative research. 

The expository essays come from a position of knowledge or sometimes to test the understanding of your subject. These essays are more of an "an expert's take" approach. The goal here is not to evaluate whether you are using your analytical skills to support your thesis. Instead, the approach takes on bringing a delicately balanced views so that the knowledge to avoid any appearance of motivational or cognitive bias. For example, "The COVID-19 pandemic tested everyone's digital literacy to work remotely!" is a statement that you would like to test your understanding. While you may prove the plethora of tools that came up during the pandemic and how it facilitated people to maintain relationships, you can also discuss the challenges of computer literacy and security issues that made many people vulnerable to hacking. Again, this essay can leverage from both qualitative, quantitative, or a mixed research style. 

The narrative essays are built on a personal touch! This essay is more of an opinion piece! They could be emotional or factual depending upon the specific story. For instance, the "Heroes Journey" to storytelling (Rajagopalan, 2020) is a narrative essay approach. One can write "Global Warming was reduced because of the COVID-19 pandemic where people worked remotely!" Most of the moviemaking is a story telling exercise that weaves a personal message. I recall a technique (Skip Weisman, personal communication, Jun 13, 2018) from my coach. This approach here is to leverage curiosity by setting the characters in the circumstance, existence or development of conflict, definition of cure, appearance of change during the pursuit of cure, ability to callback or carryout the activities amid the challenges and finally come to the closure. 

The descriptive essay is becoming a creative artist in telling a part of the narrative essay. It frequently makes emotional connections! We all know Yoda and Dark Vader or Simba and Pumpaa. As soon as you read these character names, they appear in your mind! When you think of Spiderman, you think of his lifestyle in a busy New York downtown. You are not thinking of Simba in downtown New York or Spiderman in Pride Lands in Africa!  Such an artist's rendition of the place the story took place or the object/person that had the challenges is brought in the form of powerful words. I recall one of the best opening statements from Jeffrey Archer's book, Kane and Abel, that reads, "She only stopped screaming when she died. It was then that he started to scream" describing how a mother gave up life during childbirth. 

So, how do these four essay types compare with project level communication (or for that matter communication in professional lives)? I have mentioned in my book on organized common sense that the communication falls under persuasive, informatory, or exploratory (PIE) communication. I call this the communication PIE. 

1. The persuasive communication is required when you are recommending a decision (terminating a project, funding a program, etc.). These types of communication are therefore either argumentative or expository depending on the level of subject matter expertise you bring to the table. 
2. The informative communication is more of a status quo balancing multiple elements (scope, schedule, cost, quality, risk, procurement, stakeholders, resources, change) and so is often an expository level of communication. 
3. The exploratory communication is often taking some level of persona to try out an experiment and so I view them as narrative essays. 

The descriptive can be used in combination with the narrative essays for larger level vision and direction to motivate people! For instance, by integrating our processes around one application lifecycle management tool, we benefit from reducing the operating expenses by 30% increasing our likelihood of employees receiving annual bonus. Imagine what that extra bonus in your hands can do! Fund your children's education, make that dream vacation possible, etc. Now, you are painting a picture of what is to come and what people need to do to realize that reality.

What are your thoughts? Thoughts? 

References

Rajagopalan, S. (2020). Leaders are good story tellers. https://agilesriram.blogspot.com/2020/03/leaders-are-good-story-tellers.html 

Team Management Guidelines: Treasure from my Archives

As I was doing Fall cleanup of my room, I felt ecstatic when I found one of my scribbled notes on an old journal record on the guidelines on team management. It was one of the preparations I had done for a PMO round table on team management. The guidelines were the recommendations of  Jerry Wellman (2011). While the concepts were straight forward here, I decided to put this here with some additional thoughts and share it for the community. All the eight habits are recommendations from Wellman (2011) and although these are recommendations for project teams, I feel that it applies to any type of strategic and executional team.

1. Shared Vision
• Establish Clear Roles - This is not to indicate titles but roles with broader responsibilities
• Develop the Objectives together to foster buy-in - Teams work together better if they co-author the working agreements
2. Set Expectations
• Translate overall vision into specific objectives - Discuss in clear unambiguous terms how the vision is mapped into strategic objectives (product, program, portfolio, etc.)
• Discuss commitments - availability, updates, process checks - As people commit to work, ask them to think about other elements that will endanger their commitment. 
3. Integrated Plan
• Decide on deliverables for the project - What, when, who, how, why? - While we discuss deliverables within in the project context, explore alternative thinking on these same thoughts for backlog refinement and phased approaches to rolling wave planning.
• How do you measure success? - Ensure that we agree on what matters to the team's health! Measure what matters rather than what can be measured.
4. Measure Performance
• Synchronous and asynchronous focus on status - With remote teams, don't ask for meetings at hours that make it difficult for team members in other time zones to meet. Use both synchronous and asynchronous means to validate success. Promote unambiguous written communication.
• Act as each other's eyes - Don't just see what you want to see - Yes, although is a cliche that it takes a whole village to build a village, it truly a fact! 
5. Allow for Uncertainty
• Be flexible - Identify risks and prepare for them - What more can I say here that I have not already said!
• Discuss risks and treatment plans identify triggers in advance - Identify triggers that can make the risks materialize! Have a plan to monitor risks!
6. Manage Change
• Identify slips proactively and have a plan to manage change - There are supposed to change management protocols and governance. Use an audit-based governance mechanism to promote expedited approvals. 
• Monitor change with client and internal teams - Remember change occurs everywhere all the time. So, be an agent of change from both the external and internal environments!  
7. Continually Influence
• Think outside the box - clients are reasonable and understanding - Don't complain about unreasonable clients. Are you ready to listen to their "unreasonable vendors"? 
• Think laterally to influence - Influence is all about leadership bringing behavioral changes to others - external and internal to the delivery team.
8. Regularly Over-Communicate
• Understand various means to communicate and use all channels effectively - Be comfortable with writing/speaking on all the channels of communication
• Even if it is common sense, communicate. - Let others be the judge of the information they receive!

Thoughts not in bold and italics but after the hyphen in every element are my extension of ideas! Happy to hear your thoughts.

References

Wellman, J. (2011). Eight habits of successful project teams. New York, NY: Palgrave Macmillan 

Product Backlog is not a Queue

Following up with a few PMP certification candidates during their preparation, I heard people say, "We put any idea into a queue in the backlog." In general, lean management thinking discards the concepts of large queues or batch sizes as these large queues increase the risk of non-delivery and non-compliance. I am sure we have all written a large list of things to accomplish in a day or week only to find that we accomplished only a percentage of them. Fundamentally, queue and backlog serve different purposes and to say that we queue up ideas in a backlog means we may set ourselves to fail without clear understanding of these terms. 

Both the backlog and queue are containers for work. But the type of work in them is different. The fundamental difference is that the backlog continuously grows requiring prioritization, but the queue is fixed and work in progress. Consequently, the backlog contains future oriented ideas to develop the product. It could be a type of change requests, experiments, enhancements for currently working functionality, and non-functional features. But the items in the queue are work in progress items frequently mentioned in the iteration backlog or the release backlog depending upon how agile is practiced in an organization (single cadence due to the nature of the product, for example).

Items in the backlog therefore require research and evaluation by both stakeholders and team members to assess their market fitness of these capabilities on several different attributes such as alignment to strategic initiatives (objectives and goals) as well as the ability to deliver (infrastructural considerations and team's ability to deliver and sustain). So, backlog items are often evaluated for desirability, viability, and feasibility and these concepts are discussed as part of Design thinking as well (Chasanidou, Gasparini, Lee, 2025).  The prioritization techniques (Rajagopalan, 2023) could involve Kano Model, MoSCoW model, etc.

Items in the queue are supposed to avoid buildup. This is the reason why Lean Manufacturing introduced the Work-In-Process (sometimes called Work in Progress) or WIP to limit them. The idea is that the flow is maintained. Everybody should be able to remove the WIP and pick up the next prioritized item, thus requiring the cross-functional orientation (Here is where T, Pi, V- and E-shaped skills came into existence). I am sure people can relate to the notions of FIFO or LIFO queues with the goal that we are constantly cleaning the queue. These are items committed to be done by the team and hence prioritization may be already addressed. But their ability to unblock themselves cannot be ruled out. Therefore, people employ other techniques like RICE (Reach-Impact-Confidence, Effort) or WSTF (Weighted Short Job First) as well (Rajagopalan, 2023). 

Last but not the least, the product backlog, release backlog, and iteration (or sprint) backlog are the same containers. 

1. When no release/iteration is assigned to an item in the backlog, the backlog is called the product backlog. This could contain a high-level use case good for research, experimentation, exploration, or spike, or a major epic that is a breakdown of the capability which is still too big for the team to do anything about it. It could also contain other features or user stories that the team decided to park for later consideration. 
2. When a group of iterations are packed due to the need to integrate the increments from each release and release as part of a single cadence, then, the items assigned to a release belong to the release backlog. Frequently, features and user stories are part of this release backlog.
3. When backlog items are in fact assigned directly to an iteration rather than a release, these items belong to an iteration (or sprint) backlog. Items in the iteration backlog could be part of the single cadence, multiple cadences, or release on demand. Iteration backlog contains both the user stories (Iteration Planning - Part 1) and tasks (Iteration Planning Part 2). 
4. Queues apply in the iteration backlog as that is where work happens to create the increments. Based on the working agreements negotiated within the team's ways of working, many activities may exist for some release level tasks or activities that make up the definition of done for the user stories, etc. The more cross-functional and self-organizing the teams are the better the queues will be managed.

The diagram below illustrates.  

Dr. Sriram Rajagopalan's synthesis of Backlog and Queues

So, let us make sure that we understand the terms right so that we don't propagate confusion and compromise clarity. 

What are your thoughts? Have I missed, misinterpreted, or miscommunicated any concepts. I am all ears! 

References

Chasanidou, D., Gasparini, A.A., Lee, E. (2015). Design Thinking Methods and Tools for Innovation. In: Marcus, A. (eds) Design, User Experience, and Usability: Design Discourse. Lecture Notes in Computer Science, vol 9186. Springer, Cham.

Rajagopalan, S. (2023). Risk Driven Prioritization: Challenges to Prioritization Techniques. https://agilesriram.blogspot.com/2023/02/risk-driven-prioritization-challenges.html

Critical Path: Does it still apply in today's digital projects?

Some of the questions that come up in my project management training oscillate between when to use the critical path techniques and why to use critical path in an agile context. My analogy to these questions is, "If the job required a wrench, why use a screwdriver? If the job really requires a screwdriver, why not use it?"  I am sure some of you may recall the inspiration behind my question comes from the very old discussions on the common object request broker (CORBA) where one of the cartoon pictures summarized, "If every problem is a nail, a hammer is the only tool required!" So, the question to ask us is if all the projects are the same! The project management framework identifies several techniques and tools (not commercial tools) that must be evaluated for its purpose to solve. 

Extending this analogy, let us first understand the critical path. This technique has been present for several decades and was introduced in the middle of the 20th century around the mid-1950s. Construction, Defense, Manufacturing, Supply Chain, and Transportation industries were predominant during that period building infrastructure like raising huge cities, shipping yards, rail roads, hospitals, defense systems, and highways. While there was also a limited amount of computer-based software and research and design initiatives, the mindset was that most of the projects should have a detailed breakdown of jobs to ensure resources were lined up when needed to avoid delay. 

For instance, when certain workers were required to offload shipments when the ship arrived, this project was staffed with these workers around that time rather than wasting their capacity waiting for the ship to arrive. Such a concept of just-in-time (JIT) costing models were pivotal to using the capacity and capability and so projects required understanding what types of activities are crucial. So, finding the longest path in the project that can't afford to slip (hence the term Float came up) was required given the two sets of book ends (early start, late start and early finish, late finish). This is the reason why the concept of critical path emerged. 

Now, let us fast forward about 50 years! We still build/upgrade infrastructure, we are also building new innovative products in the digital sphere. Software has completely eaten the world where there is not a single industry that does not have some kind of software tool or software simulation. The notion of plan-driven (Traditional), change driven (Agile) and flow-driven (Kanban) are coexisting today. In the case of Adaptive or Agile initiatives, the same team is working on the functionality in a timeboxed manner and so why is critical path required? Similarly, when flow driven initiatives apply, it is still the same core team working to eliminate queue and streamline flow invalidating the need for critical path as the focus is only on one or two items in the swim lane. One of the very reasons why the INVEST property come into picture is to eliminate the dependency among the work committed by the team (Independent). Consequently, these approaches eliminate dependency in the first place invalidating the need for critical path (activity sequencing) and using the critical chain (schedule based). 

Nevertheless, still some projects may benefit from a critical path. This may involve projects in the early stage that evaluate the approximate cost required or the approximate time required to deliver. So, when Agile itself is an overhead as projects need not have such an increased interaction (e.g.: A continuous email marketing project) or the risk of experimentation may be too high (not doing the soil study before laying the foundation for a skyscraper), then, the critical path foundations may still apply. 

So, the critical path is just one more tool. Use it wisely where it is needed. Not apply it in all types of projects. 

Thoughts? 

Am I Ready to Manage? Lessons from Risk Management

One of the people I was mentoring mentioned to me that there is a possible promotion with the expectation of managing people. Having been a project manager for some time, the person asked me if the person is ready to manage people. I have always felt that "P" in "Project" is all about managing "People" (Rajagopalan, 2015). So, naturally I felt that this person had the capabilities, skills, and competencies. The larger question is not being ready but being good enough to manage people. There are things about managing people's performance and having responsibility for their career, some of which can be known. Then, there are areas about equal employment opportunity, diversity and harassment considerations, and many other human resources related concepts. The lack of knowledge about unknowns morphs the question of being ready. 

I reasoned with the concepts of risk management discipline that this person was confident about. In my mind, Risk Management is about using change management principles to balance chaos and control. The risk management discipline promotes the notion of risks that we know about and the risks that we know about their impact on objectives. Consequently, extending the risks that we don't know, or we don't know the impact of, we come up with four categories of known-known, known Unknown, Unknown-Known, and Unknown-Unknown. 

I view the unknown-unknown as a category of risks that belong to chaos. Due to the unpredictable nature and the unknown impact on our objectives, we need to be diligent. Regardless of how diligent we are, we can never be prepared enough. So, this is where we connect with probing for what happened, analyze what we could have done, and we can sense them better in the future. As you can see, the more we do this type of probe-analyze-sense, the more we are becoming of the impact and so moving them towards the right to establish chaotic control.  So, when such similar risks hover on the horizon, we can now probe but our prior knowledge helps to categorize (risk breakdown structure) and sense the preemptive treatments. So, although it is somewhat chaotic, we are establishing some level of chaotic control. 

On the other hand, if we can study the chaos and understand its root cause, we know more about its existence but require more understanding of these risks manifest. These types of risks are then becoming controlled chaos requiring us to sense-analyze and then categorize. The more we analyze both these chaotic control and controlled chaos, the more we are controlling the influence (both their likelihood and impact) of risks on the project objectives. I am sure some of you can relate to the similarities of categorizing projects like the Fog (Unknown-Unknown), Quest (Known-Unknown), Movie (Unknown-Known) and Paint by Numbers (Known-Known) (Rajagopalan, 2018) based on risk management discipline. These concepts are illustrated below.

Dr. Sriram Rajagopalan's synthesis of Emotional Intelligence Concepts with Risk Management

So, how does this risk management discipline help with our questions of assessing if we are ready to manage or lead? The important thing in managing people is to illustrate to ourselves that we are good leaders. This means that we use ourselves as the instrument of emulating the behaviors we want in the people we manage. That thought borrows from emotional intelligence by first becoming consciously aware of us (self-awareness is rooted in known-known) and then engaging in self-management (known-unknown). Consequently, we move on to Unknown-Unknows (social skills) and work with people instilling trust to get them to known-known (relationship). 

I recall an excellent article by Hill & Lineback (2011) guiding us in this space. They recommend that we ask ourselves questions relating to how we manage ourselves, how we manage the network, and how we manage our team (Hill & Lineback, 2011). The list of questions they promote in this area are as follows:

Manage Oneself [Known-Known]

1. Do you use your formal authority effectively?
2. Do you create thoughtful but not overly personal relationships?
3. Do others trust you as a manager?
4. Do you exercise your influence ethically?

Manage Network [Unknown-Known]

1. Do you systematically identify those who should be in your network?
2. Do you proactively build and maintain your network?
3. Do you use your network to provide the protection and resources your team needs?
4. Do you use your network to accomplish your team's goals?

Manage Team [Known-Unknown]

1. Do you define and constantly refine your team's visions for the future?
2. Do you clarify roles, work rules, team culture, and feedback about performance for your team?
3. Do you know and manage your people as individuals as well as team members?
4. Do you use your daily activities and problems to pursue the three imperatives?

All these questions are exactly from Hill & Lineback (2011). As you engage in this experiment, you are consciously using your network and team to elevate unknown-unknown (blind spots). So, instead of being complacent that you know everything or sometimes even overdoing the strengths, you use humility and trust to let your team. I recall Barbara Trautlein's change intelligence concepts here as she asked people to ask themselves the following four questions:

1. What is your primary change leadership style - Using Hearts (People), Head (Purpose), or Hands (Process)?
2. What are the strengths of your style as a change leader?
3. How do you sometimes overdo your strengths making you less effective as a change leader?
4. What are the blind spots of your styles making you miss or neglect elements as a change leader? 

The more we become complacent or comfortable as a manager without continuous improvement on ourselves, the more we turn our strengths into weaknesses. As the recommended strategy is to always lead with your strengths, the less you sharpen your skills as Stephen Covey (1987) says, the more you are not ready. As my Chief Operating Officer once told, a good manager lets the team manage the manager. When we rate each of these questions on a scale of 1-5 and get 3 or more in each question, we are just ready. If any section is <=12, then, we must evaluate improvement opportunities. Check with a better mentor or coach and a good manager will sometimes find them in their own people they manage! 

References

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

Kent, L.A. & Lineback, K. (2011). Are you a good boss - or a great one? Harvard Business Review, January-February, 3-8.

Rajagopalan, S. (2015). Project is a verb in Project Management. https://agilesriram.blogspot.com/2015/10/project-is-verb-in-project-management.html

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

Trautlein, B. (2016). Communicating Change: Tell your story (Handout). Distributed in the PMI MassBay Professional Development Day 2016.

Agility and Scrum: Conversations outside of IT Software World

Through some of the corporate training work I had done, I got a referral to work with a couple of professional entrepreneurs in India. They were trying to introduce efficient ways of working through a combination of process improvement concepts and tools in the construction space. As part of the initial interview, I found out there was an executive level interest in increasing focus on building people up with experimental ideas to pilot and pivot! Naturally, I explored the notion of Scrum or Agile and there was an almost immediate dismissal of these concepts. The two people echoed, "I am not sure how much these IT thoughts apply in improving ways of working!"

Although our conversations never materialized in any work after 3-4 months, I felt compelled to write about how much work Agile and Scrum must deidentify themselves from their use mainly in the IT industry. I guess the Agile Manifesto principle, "Working Software over Comprehensive Documentation" has served itself to exclusively apply to the software product world. Perhaps the lack of diversity and inclusive thinking in the original Agile Manifesto thinkers has created a stigma about the Agile ways of working to the IT industry. However, as I have already mentioned about Agile being applicable in a non-IT setting (Rajagopalan, 2013), agility can be extended to healthcare (Rajagopalan, 2021). For example, replace "software" with "healthcare" to read as the "Working Healthcare over Comprehensive Documentation," and the principles can extend outside of software development.

Both Agile and Scrum are about empowering the teams to have a working agreement to solve a problem identified (or self-identified) for them by the organization. If the organizational culture is conducive to failing forward rather than punitive, any industry can apply these frameworks, which shouldn't be restricted to any industry. Consider, Andon Chord, that originated in the manufacturing assembly where all works stops to ensure that the team collectively engaged in problem solving! Examples of Andon Chord from Lean Manufacturing have found themselves applicable in many industries with the simplest example of "Stop Requested" in public buses! So, Agile and Scrum are both about the 'ways of working' where the teams are enabled to improvise with experiments to pilot and changes to pivot. 

Now, if you look at Dalmia cement, there is a lot of information about their partnership engagement with KKR (2016) that made them prosper. In that video they talk about five pillars such as learning & humility, teamwork, speed, excellence, and transparency (Alchemy: The Dalmia Bharat - KKR Partnership, n.d.). These are directly related to principles of courage, focus, openness, respect, and commitment of Scrum which emerge from the agile empirical pillars namely transparency, inspection, and adaption. Similar concepts can be seen in the US based Holcim Group, one of the famous cement producers where the very first sentence talks about the industry's focus on using agile management.

Transparency is already identified in the Dalmia/KKR partnership as pillar #5. When you look at the thoughts on speed, they talk about having a 100-day plan, metrics, process, roadmap, and experimentation! It is about the ways of working which enable the second pillar of teamwork. The focus of experimentation without the fear of failure is already mentioned that talks about trust, communication, and teamwork without which excellence does not come in. I challenge that the principles of agile and scrum are already applied but not understood. If the right tool and the framework is further identified, think about how it could improve! 

Example Scenarios presented by Dr. Sriram Rajagopalan

Similar examples are found in other industries as well. The Food & Drug Administration (FDA) allowed the use of Agile in Life Sciences and Healthcare (Deloitte, 2020). Here, there were focus on adopting risk- based governance in an iterative way addressing toxicology and pharmacology safety in clinical studies, adverse reaction protocols in later phases, and occupational hazard protection before, during, and after drug development. Centrus Energy, an international commercial nuclear power plant completed their R&D initiatives using Agile approaches (Stracusser, 2015). Telpak (n.d.) using the robotic process automation (RPA) for good manufacturing practices (GMP) and CSol's (n.d.) focus on laboratory insights for good laboratory practices (GLP) are all examples of Agile mindset. In fact, I see these agile approaches pave their foundation for the general automation manufacturing protocols (GAMP) as well. 

But such non-IT industry focuses need to be highlighted more! The stigma that Agile and Scrum applies to IT and Software product development is continuously emerging with DevOps and SAFe with too many technical terms proliferating solution-mindset in non-IT industries. So, many practitioners have more work to do! Who is willing to partner with me to write such case studies? 

References

Alchemy: The Dalmia Bharat-KKR Partnership (n.d.). https://www.youtube.com/watch?v=gxXxtMYKprg

CSols (n.d.) Agile development in Laboratory Informatics. https://www.csolsinc.com/blog/agile-development-in-laboratory-informatics/

Deloitte (2020). Validation using Agile in the Life Sciences and Healthcare Industry. https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/LifeSciences_Healthcare/IE_RA_Agile_0320_.pdf

KKR strengthens association with Dalmia (2016, Jan 15). PR Newswire. https://www.prnewswire.com/in/news-releases/kkr-strengthens-association-with-dalmia-565397881.html

Rajagopalan, S. (2013). Agility outside of software world: A case study from a theatrical play. https://agilesriram.blogspot.com/2013/05/agility-outside-of-software-development.html

Rajagopalan, S. (2021, Mar 8). Agility in Healthcare Services: Insights from Clinical and Surgical Settings.

Straçusser, G. (2015). Agile project management concepts applied to construction and other non-IT fields. Paper presented at PMI® Global Congress 2015—North America, Orlando, FL. Newtown Square, PA: Project Management Institute

Tekpak (n.d.). Pharma Competency. https://tekpakautomation.com/pharma-competency/

History is Rich: Synthesize the lessons rather than promote inconsistencies

I participated in the 4-day Scaled Agile Frame Program Consultant (SPC). Jennifer Fawcett and Mark Saymen facilitated this wonderful session. As part of the structured slides while furthering the discussion on the double operating system concept, discussions emerged regarding Deming's PDCA cycle. Later during the discussions, I heard participants discuss the need to give up project management principles towards the product management mindset. As the class continued, I heard root cause analysis discussed more as a technique rather than as tool to further the discussions in SAFe approaches that were introduced by Leffingwell (n.d.) in 2011 almost 10 years after the original Agile Manifesto was published to scale up agile in teams of teams at the business level. I echoed in the class and wrote to the facilitators the importance of how unsafely we are promoting techniques over principles without truly connecting with history. Here is my summary of these thoughts. 

First, Deming did not conceptualize the PDCA cycle (Moen, 2010) and neither claimed ownership nor embraced it. Edward Deming worked under Walter Shewart, who iterated on his model of "specify, produce, inspect" around 1939 coming up with a "Design, Produce, Sell, Redesign" in 1950's as a starting point to initiate conversations around the need to have interactions across the value chain. Shewart drew his inspiration from two different sources (Moen & Norman, 2009). The first was John Dewey's pragmatic principles of product design. These pragmatic principles were called in four stages, "Discover, Invent, Produce, Observe." Separately, Clarence Irving Lewis was promoting a 3-step pragmatic learning concept "Experience, Application, Susceptibility" contributing to Shewart's inspiration of specify, produce, inspect. 

Deming didn't package Shewart's cycle as Plan-Do-Check-Act at all. He called Shewart's cycle only Shewart's cycle in honor of his mentor. However, as the word spread around, the concept of Plan-Do-Check-Act emerged among the Japanese manufacturers crediting Deming with this concept. Contrary to the practitioners' thinking, such as the Agile Manifesto that prescribed "individuals and interactions over processes and tools" and SAFe that continue to build its premise on PDCA, Deming himself did not prescribe to this concept because he felt that this approach didn't promote the much-needed learning required in both the people and processes. 

Separately, several contributors such as Alan Graham and Karou Ishikawa promoted many other concepts laying the foundation for quality to be a movement (Schneier, Russell, Beatty, & Baird, 1994) to promote continuous learning (hence Kaizen was born) but not limiting quality to be only incremental actions but also innovative big picture thinking (hence Kaikaku was born). So, many concepts like the Quality Function Deployment (QFD) and House of Quality (HOQ), Quality Circles, 5S principles, Design Thinking and Systems Thinking emerged (Senge, 1992).  All these authors converge on the learning organization should inculcate building a shared vision, personal mastery, working with mental models, team learning and systems thinking. Empowered by these thoughts, Deming in 1993 conceptualized the need to 'study' creating the Plan-Do-Study-Act (PDSA). 

So, the question is, why do practitioners continue to miss out history and go back to antiquated non-existing theory only to rest their blames on theory? Seems like this is the same thing that happened with Royce (1970) who iterated with dozens of pictures for a system development lifecycle (SDLC) model, but people stopped at the second figure in the first page creating a waterfall theory that never was proposed by Royce (Rajagopalan, 2014) to begin with!

Another thing to keep in mind is the principle of force-field analysis. This notion was promoted by Kurt Lewin (1939) who said a cause could be coming from forces that oppose (resistors) and support (enablers) a cause. We can see that all the time in any change - those that support and those that resist! Ishikawa approached the manufacturing context using his 4M (men, machine, method, materials) introducing the fish-bone diagram (Watson, 2004). Instead of only looking at Fishbone, many practitioners have incorporated the force field analysis over the root cause analysis as a combined approach to allow prioritization rather than just move forward with dot voting as the SAFe classes promote.

Now, let us ask ourselves. Do we work with various stakeholders and team members, sometimes with contracted workers, in product development? Is there some level of known scope of work we are committing to deliver on a specific schedule? Are we all working pro bono and getting materials free, or do we incur direct or indirect costs? Does quality factor into the way we work, delivering value to the customers? Aren't we impacted by assumptions that prove to be wrong or risks that come from known/unknown areas impacting us positively or negatively? Don't we hold ourselves to communicate through various means keeping everyone abreast of what's going on in our product development? When any one of these elements change, aren't we embracing them to evaluate how to pivot? Every one of these highlighted words represent a knowledge area in project management that product management cannot live without! The goal is not to give up these project management principles but adopt them and elevate to higher level systems thinking towards benefit sustenance and value delivery. Product Management mindset builds on Project Management basics!

So, a larger question to practitioners! Please synthesize the history first! If not, we will only promote inconsistencies!

What are your thoughts? Please share.

References

Burnes, B. & Cooke, B. (2012). Kurt Lewin's Field Theory: A Review and Re-evaluation. International Journal of Management Review, 15(4), 359-469. 

Leffingwell, D. (n.d.). https://scaledagileframework.com/about/

Lewin, K. (1939). Field theory and experiment in social psychology: concepts and methods. American Journal of Sociology, 44, pp. 868–896.

Moen, R. & Norman, C. (2009). “The History of the PDCA Cycle.” In Proceedings of the 7th ANQ Congress, Tokyo. https://elfhs.ssru.ac.th/phusit_ph/pluginfile.php/48/block_html/content/Moen-Norman-2009%20PDCA.pdf

Moen, R. (2010). Research Seminar. http://neuplace.net/PDSA_history_ron_moen.pdf 

Royce, W. W. (1970). Managing the development of large software systems. Proceedings, IEEE WESCON, pp 1-9.

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

Schneier, C.E., Russell, C.J., Beatty, R.W., & Baird, L.S. (1994). The Training and Development Sourcebook. 2nd Edition. Amherst, MA: HRD Press.

Senge, P. (1992). Building Learning Organizations. Journal for Quality and Participation, 15(2), 30-38.

Watson, G. (2004). The legacy of Ishikawa. Quality Progress, 37(4), 47-54.

Does EVM apply in Agile

One of the best things that I love is interacting with people. When they ask questions, I always go back to the basic principles! That's what happened to me when a few learners in the corporate training I delivered asked if traditional EVM principles are even required in Agile principles. Here are some thoughts, first explaining the EVM concepts and then extending them to Agile approaches.

Earned Value Management has two parts (Project Management Institute, 2017). The first part is lagging indicators that tell how the project is performing at a snapshot in time. The second part is the leading indicators that forecast how much more time and money will be required to finish the project! 

Lagging Indicators

This involves the Schedule Variance (SV) and Cost Variance (CV) expressed in currency units and Schedule Performance Index (SPI) and Cost Performance Index expressed as ratios. To compute any of these four measures, there are three things that are required. The first is the planned value (PV, sometimes also called budget at completion (BAC) or budgeted cost of work performed (BCWP)) of what we expected to compete, the second is the earned value (EV) of what we have earned at a snapshot in time and the actual costs (AC, sometimes also called the actual cost of work performed) incurred to generate the EV. Then, the lagging indicators can be computed as follows: 

Formula	Explanation
SV = EV - PV	If SV is zero, progress is on schedule If SV is -ve, progress is behind schedule If SV is +ve, progress is ahead of schedule
CV = EV - AC	If CV is zero, progress is on track If CV is -ve, progress is under budget If CV is +ve, progress is over budget
SPI = EV / PV	If SPI = 1, progress is on schedule If SPI < 0, progress is behind schedule If SPI > 1, progress is ahead of schedule
CPI = EV / AC	If CPI = 1, progress is on track If CPI < 1, progress is under budget If CV > 1, progress is over budget

Now, let us think about the applicability of lagging indicators in Agile. While the focus of Agility is on the team to manage itself, we need to ensure that the team can commit reasonably (and no external influence exists on the team to pressed for commitment) and self-organize themselves to deliver on the commitments (of course, there are always deviations). In the daily standup, when the team is marking completion of stories (task) for the user story to be ready for testing and marking validation complete (test cases) and the stories are accepted incrementally through the iteration, they are demonstrating earned value (velocity based on stories completed) towards the planned value (planned velocity).  There is always a cost to the iteration (Rajagopalan, 2019) representing the actual costs. 

So, if we have all the elements of planned velocity, earned value (actual velocity at the end of the iteration), and the actual cost (incurred at the end of the iteration), can EVM benefit from lagging indicators? The answer is Yes. But the goal in Agile should be drive team's health, estimation accuracy, environment, and commitment for them to deliver.

Now, there is a question on the leading indicators. In traditional projects, there is a known scope of work and depending upon the lagging indicators, the estimate to complete (ETC) and the estimate at completion (EAC) can be evaluated. In agile projects, the product backlog is emerging constantly, and the fixed scope of work is not always known. Nevertheless, if one looks at the agreed scope of minimum viable product for the release according to the product roadmap, there is some anchor in the known scope of work within the MVP. If that MVP level stories are reasonably estimated (even if they were in the Affinity Estimation (i.e., T-Shirt or Coffee Cup)), then, it is possible to project the MVP backlog size. Then, for this known scope of MVP size, it is possible to apply the leading indicator concept from EVM.    

First, let us look at the leading indicators. There are four formulas depending upon the level of accuracy and confidence required. 

1.     EAC = AC + ETC

In this approach, accuracy and confidence are low. The project manager often approximates o the additional level of effort and cost. Sometimes, it could involve parametric estimates or expert judgment to come up with an estimate to complete.

2.     EAC = BAC / CPI

This approach is slightly better because the focus is on the cost more than the schedule. The project manager uses the current rate at which costs accrue and uses this rate against the budgeted planned value (BAC) and projects the amount required. Since CPI will be less than 1, the EAC will be more than BAC and the difference is the additional amount required to deliver on the remaining scope. But it doesn't consider work already delivered (EV). It is possible to increase accuracy by using the slight revision existing work delivered must be removed. The revised formula is: EAC = (BAC-EV)/CPI

 

3.     EAC = AC + (BAC - EV) / SPI

Here the focus is on the team's ability to deliver on the remaining scope. Cost is not an issue, perhaps because the team members are salaried employees. In this case, the team's ability to deliver on the remaining scope of work at the rate the team delivers (BAC-EV)/SPI is computed and the actual costs already incurred are included. 

 

4.     EAC = AC + (BAC - EV) / SPI * CPI

Here, the focus involves both the rate at the rate costs have accrued as well as the rate at which the team can deliver on the remaining scope. The only difference from the previous formula you will notice is that the denominator includes a product of both CPI and SPI.

As you can see in the above explanation, forecasting (i.e., leading indicators) is a business need. Regardless of whether a team is focused on a plan-driven or change-driven approach, the business always has the question of how long it will take for you to deliver on the remaining scope or MVP. 

If the lagging indicators (SPI, CPI, EV, AC) exist, and BAC (PV) is focused more on the remaining backlog size for the MVP, is there a reason why EAC calculations do not apply in Agile? The answer is Yes. In fact, Agile uses the burn rate to compute the rate at which the team burns through the backlog. Furthermore, there is one more leading indicator that people compute. That is To-Complete-Performance-Index (TCPI). This is computed as follows. Does the work and cost remain relevant to Agile? Then, why question whether EVM extends to Agile approaches or not? 

• TCPI = Work Remaining / Cost Remaining
• TCPI = BAC - EV / BAC - AC

The following diagram further illustrates graphically the thoughts. If you look at the abscissa (X-Axis), I have put both the timeline (T5, T10, T15, etc.) for a phased traditional approach and R1, R2, and R3 indicate the releases that may be comprised of individual iterations (single cadence where increments must be consolidated and delivered). So, Agile or Traditional, don't get mixed up on terms! Focus on the principles of delivering customer and business value. Use EVM as it applies in your own context. 

Dr. Sriram Rajagopalan's approach to EVM in Agile

It should, however, be pointed out very clearly that in Agile, we should measure a few more things. These include cycle time, lead time, WIP, and Backlog Size (Remaining work). This is because, as mentioned before, the scope of work is constantly changing in Agile because of the constant feedback mechanism and the notion of embracing change.

References

Project Management Institute. (2017). A Guide to the project management body of knowledge. Newtown Square, PA: Project Management Institute. 

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

Essential Games for Agile Ceremonies

As I was teaching about the principles of Agile, a question came up from one of my participants about the compelling reason to play games in Agile and what are the essential games. The foundational element of Agility is self-organization in the teams. The expectation is that the team is empowered to ask powerful questions and enabled to act in a way conducive to deliver on product strategy. To emulate this self-organization, games are generally recommended as people's creative juices come in when you infuse fun ways of working. 

I reasoned that among the many games (Tasty Cups, n.d.) to play based on the specific challenge to be addressed, every game is analogous to medicine! Not all medicines treat the symptoms well; based on specific patient chemistry, what works for one (ibuprofen for headache) may not work for another! So, diligence is required to select the right game based on the level of team maturity, self-organization, and cross-functional expertise. Just like any game, the more you practice, the more you get better at the play.

In general, there are four ceremonies. These are Iteration Planning, Daily Standup, Review and Retrospective. There is also a backlog refinement (that some call backlog grooming) which is required to refine and prioritize stories in preparation for the iteration planning. So, here are some games that can apply to one or more of these ceremonies.

Given below is a quick summary of what games apply to what scenarios followed by detailed explanation. I am sure there are many others that can be played. But these games are more than enough, in my humble opinion, to get Agility working in the teams.

Game Name	Backlog Refinement	Iteration Planning	Daily Standup	Review	Retrospective
Product Box	Yes	Yes	No	No	No
Buy a Feature	Yes	Yes	No	No	No
Prune the Tree	Maybe	Yes	No	No	No
Paper Airplanes	No	No	Yes	No	No
Daily Scrum Game	No	No	Yes	No	No
Matchup Canvas	No	No	Yes	No	No
Speed Boat	No	No	No	Yes	Yes
Mad, Sad, Glad	No	No	No	Yes	Yes
Pass on Perfection	No	No	No	Yes	Yes
Feedback Game	No	No	No	Yes	Yes

Product Box: The goal of this game is to simulate the functionality that is minimally required to be released. It appears a long time back that people used to buy software that came in a CD wrapped within a box. It would give details about the minimum system requirements, major features, details around customer support, and helpful documentation using up all the six sides of the box! The product box comes with the same notion of asking the stakeholders and team to prioritize minimally required features for a release by allowing people to place these features on a blank product box canvas. It can be used in backlog refinement and on the release (MVP) /iteration planning (MMF/MBI). 

Buy a Feature: The goal of this game is also to help stakeholders align on priority. Every stakeholder will be given a certain amount of virtual currency (or virtual points). Each feature (not one story but a feature) will be given a price (or point) depending upon the complexity and/or size based on the team's input. The stakeholders can then use their money to buy the most important feature they need (just like how we don't waste money on every frivolous thing but on the necessary things alone). People change the rules of the game sometimes where stakeholders can pool their money to buy a feature when they don't have enough left to buy a feature or restrain such money-pool recommending 'use it or lose it but not combine it!'. This is also a good game for backlog refinement, release, and iteration planning. 

Prune the Tree: This game lets team members position various features and other experiments based on priority or value to the customers/business. This game can be used by the team to engage in more powerful questions on the customer's actual needs based on the priorities and unearth the actual needs and differentiate the nice to have from the must to have just like a tree is pruned. The goal is to validate the minimum needs, prioritize accordingly, and come up with the other use cases (technical value, process value) to ensure that these customer value stories can be delivered. This game is primarily beneficial in iteration planning. 

Paper Airplanes: This game is more about how people practice agility! The goal is not what anyone can do (regardless of the role like the product owner, coach, developer, tester, etc.) but what everyone collectively can deliver. That's the idea behind how everyone can support creating how many flying paper planes that fly past a certain boundary can be created. The game brings that together everyone achieves more (TEAM) mentality. It is ideal for daily standup.

Daily Scrum Game: This game helps the team member to understand certain behavioral patterns people may have and how they will identify and collaborate in such a place. The goal is furthermore to understand the failsafe environment. In this game, the agile coach asks some team members to assume certain behavioral patterns (monopolizing conversations, refusing to give feedback, etc.) and asks the team to practice playing the daily stand up that must be finished in the time allocated. Then, they discuss if they were able to identify the persona people took and how they should work with such disruptive patterns if displayed. 

Matchup Canvas: This game is frequently a good one when the team is in the early stages of Agile team (Like Forming, Norming). The goal is to conceptually think of ourselves having a "business card" that displays who we are and what we bring to the table in the team. For example, the card canvas can have our name, goals, what you offer (skills, knowledge, help) or can't offer but willing to learn, who can benefit from your skills and competencies, what you need from others and where you will go for help. If such a card is placed on your cube (or part of your signature for virtual teams), it would help people when they need support or guidance. 

Speed Boat: This game focuses on learning! The analogy here is that a speed boat can accelerate going forward, stall not making progress, or decelerate going slow or receding backwards. The logic here is to extend this to say what are we doing that helps us progress faster and deliver on commitments, what we should stop that does not add value, and what we should do that will helps us pick up pace! Sometimes, we also call this 'keep doing,' 'start doing,' and 'stop doing.' Another variation of this game is also called "mad, sad, glad" which associates with being mad about what happened (stop doing this), being somewhat sad about what happened (start doing something to avoid this), and glad about what happened (keep doing what we are doing). This game is applicable in both the review and retrospective ceremonies. 

Pass on Perfection: This game is about giving feedback. The game emerges from the coaching principles of using "Yes, And" rather than "No But". So, when someone says something and you have an alternative view, instead of saying "No this will not work but if you do this it might work," you change your approach. "Yes, I can see how this will work and if you consider this it might work better!" 

Feedback Game: This game is also about giving feedback. In fact, it is about practicing to give/receive feedback. The goal is not to be always clever and all-knowing but also to be modest and be on the receiving end of feedback. The game is played with a pile of cards (carefully chosen with questions or scenarios). Each person takes a card, chooses to keep the card and answer the question or the scenario with opportunities to hear what they could have done differently. If the person chooses not to keep the card, the person can pass it to others who can then choose to keep it. The game ends when all the pile of cards are answered.  

References

Tasty Cup Cakes (n.d). https://tastycupcakes.org/)

Rethinking Risk Management: Combination of Strategies

I often wonder if people really understand the basic tenets of risk management. The reason for my wonder came when I was having discussions with a professional preparing for Agile Certification that they don't do risk management in their organizations because the product management only does SWOT analysis and that they participate in blue ocean thinking. Only after some of my explanations was the learner able to see the tenets of risk management in SWOT and Blue Ocean Leadership. In my book on Organized Common Sense, I mention that if we don't take care of risks, risks will take care of us! All strategies and every execution are loaded with risk! In my humble opinion, quality is a function of risk! 

Let me elaborate on my discussion with this learner for the benefit of many! When we discuss SWOT, we have to understand that it is a summary framework to capture our research and findings by applying other frameworks. For instance, the internal strengths and weaknesses can be evaluated by VRIO framework (Valuable, Rare, Imitable, Organized) and external opportunities and threats can be assessed by PESTLE* (Political, Economic, Societal, Technical, Legal, Environmental) framework. 

When you look at the summary captured in SWOT, risk management concepts are spread all over it! In Risk Management, positive risks are called opportunities and negative risks are called threats. Companies often have their own strengths based on years of experience in that field or the accumulated knowhow, intellectual property, and access to human capital, subject matter expertise, and domain knowledge. This is why we say, lead with your strengths to maximize opportunities (SO) or minimize threats (ST). While one may want to address their weaknesses with complementary opportunities (WO), no one wants to venture out into an area of expertise where not only they have weaknesses (example: not organized to deliver value or their product/services is not rare and imitable) but also other competitors have a winning edge (WT). This combination of creating strategic areas based on internal and external factors is called the TOWS approach (Weihrich, 1982). 

So, how does this connect with Blue Ocean? According to Kim & Mauborgne (2005), the overarching concept of Blue Ocean strategy is that companies are seeing an uncontested market where they can gain significant first-movers advantage. But, to create opportunities in this market, they will have to consciously decide to eliminate working in some areas, raise their strengths (ways of working) to leverage internal strengths to tap into new customer base and reduce some ways of working that add more to waste than value. Hence, Blue Ocean frames these four approaches as ERRC (or CRRE). You can see how the "create" corresponds to SO, "raise" aligns with ST, "reduce" maps to WO and "eliminate" associates with "WT". 

Now, what does risk management framework (Project Management Institute, 2017) suggest as risk treatment options? For negative risks, the expectation is that one first avoids risks. If the risk cannot be avoided, one transfers to someone more qualified to manage the risks. Despite transferring some risks, there may be risks that one may have to absorb. The guideline is that one takes proactive measures to mitigate the risks before accepting the remaining part of the risk. For positive risks, the reverse is true. One exploits where one has both the strengths and opportunities, shares or enhances strengths to address threats. 

Given below is the synthesis. Now, the risk treatment options identified here may swap places depending upon the degree to which one has internal strengths and weaknesses and the extent to which they want to address external factors to maintain a competitive edge.    

Dr. Sriram Rajagopalan's synthesis of SWOT, TOWS, Blue Ocean and Risk Response Frameworks

What are your thoughts on my synthesis? Agree/Disagree? 

*Based on discussions with one of my friends, Kalash Upadhyay (personal communication, April 17, 2017) from Addon Skills, we have extended this to include ethical and demographic considerations calling it PESTLEED. 

References

Kim, W. C. & Mauborgne, R. (2005). Blue Ocean Strategy: From Theory to Practice. California Management Review, 47(3), 105–121. https://doi.org/10.1177/000812560504700301

Project Management Institute. (2017). A Guide to the project management body of knowledge. Newtown Square, PA: Project Management Institute. 

Weihrich, H. (1982). The TOWS matrix - A tool for situational analysis. Long Range Planning, 15(2):54-66.

Incoterms: Know the Risks in Supply Chain Industry

I was discussing risk management in one of my management training courses. The generic risk breakdown structure (RBS) discussion became really engaging when a few members said when procurement is involved, risks are low. I reasoned that the opposite is true, and we discussed about the contractor's extent of liabilities when I mentioned about Incoterms discussing who is responsible for what in the supply chain industry bringing up the major blockade that happened around March 2021 when a freight liner blocked Suez Canal. No one had heard about Incoterms (International Trade Administration, n.d.) and the 11 modes of transportation considerations when manufactured or other types of goods are transported from the factory to the buyer's warehouse.

Incoterms is a set of internationally recognized terms indicating the responsibilities of buyers and sellers in transactions involved in the supply chain. Usually, these types of transactions involve exporting physical products. These Incoterms are published once in 10 years and the last 9th edition updates were published in the year 2020. While I am not an expert in these Incoterms, I have spent time understanding them as part of my never-ending interest in the field of risk management. The following is my interpretation of the Incoterms 2020 depicted to demonstrate the transfer of risk and the obligations of seller and buyer.

Disclaimer: The above diagram is Dr. Rajagopalan's interpretation.

Given below are some brief descriptions of these terms and interpretation of liabilities.

Mode	Code	Description	Explanation
Any	EXW	Ex Works	Risk passes on taking in charge by buyer. The seller not obliged to load goods onto the vehicle. Buyer must clear for export.
Any	FCA	Free Carrier	Risk passes on taking charge by carrier. If at seller's premises, seller must load onto vehicle. If other place, seller delivers on vehicle and seller must clear for export.
Marine	FAS	Free Along Ship	Seller delivers alongside ship, where risk passes.
Marine	FOB	Free On Board	Seller must load on board ship, where risk passes.
Any	CPT	Carriage Paid To	Risk passes on taking in charge by carrier; buyer should enquire about terminal handling charges and arrange for insurance from the point the career takes on.
Any	CIP	Carriage and Insured Paid To	Risk passes on taking in charge by carrier. Seller must insure goods.
Marine	CFR	Cost and Freight	Seller must load on board ship, where risk passes.
Marine	CIF	Cost Insured and Freight	Seller must load on board ship, where risk passes. Seller must insure goods.
Any	DAP	Delivered At Place	Delivered loaded from arriving conveyance.
Any	DAT	Delivered At Terminal	Delivered unloaded from arriving conveyance.
Any	DDP	Delivered Duty Paid	Delivered still loaded on arriving conveyance, cleared for import, duty paid.

References

International Trade Administration (n.d.) Know Your Incoterms.

Strategy Focus: Develop Market Persona

One of  my very good friends was in the healthcare field and I was coaching this person on leading professional career growth.  The friend asked about potential job growth and building up the profile for career improvement. As a very accomplished individual, with several years of professional experience and even a doctoral degree, the person asked how to move ahead in advancing the career, particularly even starting a business. I asked more about the type of market that this person wanted to work in and identified the next steps. I saw that the focus was a little narrow without a clear persona of the market within the industry this person wanted to spend time and money. I suggested this person develop a market persona (Kotler & Keller, 2012) to drive the discussion further into the specific focus area. 

The discussions emerged about user persona that is often done at the product level for product development. So, I developed a market persona for a financial field as an example for her to elaborate. I incorporated some of the basic SWOT (Strengths, Weaknesses, Opportunities, & Threats) principles in this discussion.  Here is the synthesis of this "Market Persona" generalized for the finance industry. 

The Market Persona helps to evaluate the representative group of industries (sectors, as people call them). For instance, the Finance industry is made up of banking, investment, and insurance sectors. Typically, these are mid-to-large organizations with 500+ employees and often they have some common goals or objectives to lower the cost of ownership of tools and processes, improve the overall visibility of work across the enterprise and the compelling adherence to audit and compliance with regulations, standards, and laws. These are captured on the left column. 

Then, the SWOT comes along. Since strengths and weaknesses are internal to an organization but we are doing this assessment for the industry, one must see common patterns across the sectors for competitive collection of strengths and weaknesses. Most of the companies in these sectors benefit from the long tenure in the industry. Many of them have jumped on the digital transformation journey with responsive websites and mobile apps for tracking online banking, digital deposits, online investment tracking, etc. There are many conferences and networking events, to begin with, where there are many professional connections with other companies, standards organizations, and government entities. Their weaknesses are their constraints on budgets and risks are too many people movements (because the overall skills and competencies are the same allowing jumping the ships). Constrained by budget and challenged by people movement, their major dilemma is being able to continue coverage for their clients. These are captured at the top row in the middle and right columns. 

Extending the same analogy, the next row captures the opportunities in the middle column and the threats in the right column. The "people risk" mentioned earlier also translates into opportunity because of the talent pool available. Besides, several competitive vendors and partners exist to get talents for contract-to-hire and many contracting types. Many 3rd party tools also exist (PMIS, ALM, SCM, CICD, Code Coverage, UX frameworks, Automation frameworks, etc.) that can get companies accelerate the tool adoption relatively faster compared to organic development (build vs buy, rent vs lease type of concepts). The challenges are adherence to legal and regulatory environment like Sarbanes-Oxley controls, Graham-Leach-Biley-Act Compliance, General Data Protection Regulation, Privacy Challenges, Cloud adoption and related Data security, etc. 

Will the SWOT alone help you help you? No. We also need to know the type of decision makers and other policy stakeholders and lobbyists that we need to pick up. Remember that these are stakeholder groups rather than named stakeholders. So, understanding the typical titles that these stakeholders hold or the groups that they belong to help us narrow down the type of "buyer persona" that we should try to please and win support to land on a deal! These are captured in the two columns in the third row. 

Using market research techniques, such as focus group interviewing, individual interviews, expert panels, pomodoro type of speaking engagements, webinars, surveys, and cross-marketing initiatives, we can narrow down further specific needs that these customer groups may need. For example, single-source-of-truth focused ALM (application lifecycle management) is often the preferred way rather than having multiple siloed tools (which often does not reduce the total cost of ownership). As companies jump on the digital transformation, they may require support with automation or agile transformation. Some may even require contracts such as the BOOT (Build-Operate-Own-Transfer) that is predominantly practiced in construction or petroleum industries (like new oil rig development). Furthermore, some of these immediate needs may not be immediately absorbed by the companies as the required capability instead of capacity becomes the sticky point requiring people to seek bench strength. 

Based on all these SWOT, stakeholders, and immediate needs, the market persona helps us evaluate the area that one can play. These involve the engagement ideas based on our strengths, such as partnership ideas, reseller models, and staff augmentation models. These are captured in the final row. It is this engagement model that we can further evaluate (iterate on our SWOT) to come up with how we can play!

Dr. Sriram Rajagopalan's Market Persona Grid

  How do you relate to this market persona? 

References

Kotler, P. and Keller, K.L. (2012). Marketing Management. 14th Edition. Upper Saddle River, NJ: Pearson Education.

Failure is my Friend and Success is a Byproduct

Several years back when I was in middle school, I participated in a speech competition. It was around India's Independence Day,  and I had chosen to talk about India's freedom struggle. I prepared for the speech with my mother's help and was ready to deliver! When the time came, I got up, went to the podium, looked at the people and froze! I managed to talk but continued to freeze! I even had the handout with me, and no one would have known if I viewed my notes and there was not any rule that I should not look at handouts. Still, the written notes appeared completely blank for me, and I didn't finish my speech. There was a good amount of preparation, but I did not plan enough for the delivery. I failed miserably! My mother said, "You will not fail if you have learned from this failure!" 

This message resonated with me so much that I always made it a habit to engage in an appreciative enquiry anytime I failed. I didn't want to waste the failure as I have spent time and efforts in avoiding it and yet have faced it. If I don't want to fail, I need to learn the lessons it taught and incorporate these lessons to avoid failing again. In my humble opinion, this is "Fail Forward!" and I had collected a list of famous failures to remind me how these people turned failure into success by believing in themselves and applying lessons learned!

When I heard about a few friends in my training and mentoring engagements mentioned fearing failure, I mentioned that fear is a normal response. But yielding to fear is giving up growth! Fear of failure should not take over our responsibility to be successful.   

1. Beethoven's music teacher said that he is hopeless as a composer.
2. Edison's teacher told him he was unable to learn.
3. Einstein couldn't speak until the age of 4 and he couldn't read until age 7.
4. Isaac Newton's work in elementary school was rather poor. 
5. Martin Luther King received a "C" in his public speaking class.
6. Louisa May Alcott was told by an editor that her writing would never appeal to the public.
7. Louis Pasteur received a "mediocre" rating in chemistry.
8. Admiral Byrd was deemed 'unfit for service' before he flew over both poles.
9. Caruso's music teacher told him that he had no "voice at all."
10. Henry Ford was evaluated as "showing no promise."
11. Walt Disney was fired by a newspaper because he lacked imagination and had "no good ideas."
12. Abraham Lincoln failed campaigning seven times before becoming the President of the United States.
13. Bill Gates' first business, "Traf-O-Data" was a failure.
14. Michael Jordan was removed from his high school basketball team for "lack of skills."
15. Steve Jobs was removed from the company he started.
16. David Sanders failed selling his chickens to more than 1,000 restaurants before he started KFC.
17. J.K. Rowling's Harry Potter novel was rejected by 12 publishing houses.
18. Oprah Winfrey was fired from her news anchor job & failed in her first attempts at OWN magazine.
19. Sylvester Stallone was rejected acting jobs as he talked and walked funny and couldn't act.
20. Charlie Chaplin was rejected by Hollywood for film acting.

When we see these people, we only see their success wrapped in bowties! Not their struggles, challenges, and failures! They never let their failure replace their responsibility for success! I am sure this list is endless with thousands of people from various countries and professions missing. Success is made up of very little perspiration but a lot of inspiration! As the old saying, "If the map and terrain do not match, trust the terrain" goes, if the world does not believe in you but you believe in a cause, then, every failure is an increment towards your future! Your discipline in continuously learning and growing is the connecting bridge between success and failure. As Maxwell (2012) says, "Habit is the daily battleground for character" and we need to make a habit of learning from failure instead of fearing failure. 

I feel failure is my friend. If that is not the case, I would not have landed in the United States with $16 in my hand and still no place to go to and no one to talk to! I may not be as famous as one of the 20 people I listed above but it is my failures that shaped me to get the most prestigious PMI Eric Jenett Project Management award of excellence in 2017. I am one more testimonial to the long list of so many unknows doing whatever it takes to show the world, "If I can do it, anybody can do it!" As Yoda says in Star Wars, "The greatest teacher, failure is!" It gives me numerous advice. If I listen and learn, success is the byproduct of that fun learning experience. The more we spread that fun experience, the more the fun (success) grows! So, don't fear failure! Embrace it! Failure is final only when you stop!

Thoughts?  

Contract Management Essentials and Best Practices

In one of the project management training courses I was delivering, I found that most of the candidates were not knowledgeable about the contract management essentials. While the Project Management Book of Knowledge gives some basic types of contracts (T&M, Fixed Fee (FF), Cost Reimbursable (CR) and the variations for incentive fee, award fee, and economic price adjustments), I found that the essential six building block of a contract were not known to many. Furthermore, about one year back, I delivered corporate training on contracting and procurement management for an organization. The training was for both members of the project management group and procurement management group.

Six Elements of a Contract

Contract, by definition, is a legally binding agreement between two or more parties that is enforceable by law. Like the Project Management Book of Knowledge issued by the Project Management Institute (2017), there is also a Contract Management Book of Knowledge (n.d.) abbreviated as the CMBOK issued by the National Contract Management Association (NCMA). According to CMBOK, Contract Management is a specialized competency within the procurement profession with a broad perspective in terms of the responsibilities assigned to contract managers.  For contracts to be enforceable by law, there are six elements that need to be in place. These include the following.

1. Mutual Agreement: This means there is an offer that is clear and unambiguous and there is acceptance.
2. Considerations: For the contract to be fair and equitable, both parties agree to a fair exchange of value in terms of the price paid and the work to be delivered. 
3. Legal Capacity for the Parties to Act: The parties represented in the contract should be legally able to represent and act in their capacity on behalf of the company. So, anyone who doesn't have the right to execute a contract (role, age) or frame of mind (not under the influence of drug, alcohol, or emotionally unstable state) to represent themselves in a contract can't execute a contract. 
4. Intention to Create Legal Relations: The parties to the contract must have an honest, serious, and real intent to engage themselves through the contract. This means no other untoward, immoral, unethical, and illegal side motives can apply.
5. Communication: All the parties represented in the companies from all the companies should follow their own company policies honoring and be consistent with the pricing and delivery (SOP, for instance). Acceptance of appropriate contracting parties also extends to agencies and other suppliers mentioned in the contract. 
6. Legality of the Contract: Under no circumstances, the intention behind the contract should be to make the contract illegal so that it cannot be enforced by law. 

Based on my experience working with contracts, I also came up with my own recommended practices to enforce to ensure people protect themselves and the performing organization. If in doubt, don't sign the contract!

My Recommended Guidelines

1. Know who you are doing business with — Their power, influence, and interests in the contracting process so that you can limit liability and avoid any litigation.
2. Contracts must be plain English ensuring that they are concise, clear, and comprehensive. When using boilerplates, ensure you understand the terms used so that each party’s rights, responsibilities, and obligations are unambiguously understood from the view of the court of law.
3. Define important terms relevant to conducting the business without assuming everyone working on the contractual deliverables understands these terms.
4. Incorporate the party’s obligations and the impact of non-delivery and non-conformance when including all agreed-upon schedules, pricing, and delivery requirements.
5. When conflicts arise, put a process in place to require either party to provide written notice of breach with the expectations of resolving the problem and considerations for alternative remedial actions before escalating to legal counsel.
6. Incorporate risk into the contracts by including provisions for liability, indemnity, and hold harmless provisions to shift certain identified risks to the appropriate party.
7. When insurance is required by either party as risk mitigation, discuss the required amount of insurance and confirm who should be named as the additional insured.
8. Ensure pages in the contract and even numbering schemes for the paragraphs.
9. Agree upon the applicable law governing the contract and the location where disputes will be resolved.
10. Specify that the contract represents the entire agreement to prevent any claims against oral agreements.
11. Incorporate regular audits of the standard agreements to ensure lessons learned are reflected and the agreements are amended to reflect any recent changes.
12. Before signing any written contract, read and understand the contract not only individually but also in a group. Seek help if needed.

References

Contract Management Book of Knowledge (n.d.) National Contract Management Association. https://ncmahq.org/

Conversation Starters: Lessons Learned from a Kindergartener

Many of us, regarding our professional roles, struggle with starting conversations with others. We evaluate the importance of forming stage in team formation, kickoff meetings, and brainstorming sessions, where must consider icebreakers! As a speaker, one thing that I always think of in public speaking engagements is the icebreaker questions outside of weather or sports! As a conference organizer at least with PMI MassBay when I was the Vice President of Marketing and Communication, I had to think of icebreaker activities for team members to collaborate! 

As a friendly neighbor, I had the opportunity to babysit one kindergartener after school. While helping him assemble his bag, I noticed a check sheet, "Conversation Starters for Parents and Children!" It had the following items on the left. 

Conversation Starters for Parents and Children

1. Tell me about the best part of your day.
2. What was the hardest thing you had to do today?
3. Did any of your classmates do anything funny? What was funny about it? 
4. Tell me about what you read in class.
5. Who did you play with today? What did you play?
6. Do you think [subject] is too easy or too hard? Why do you think so?
7. What's the biggest difference between this year and last year?
8. What rules are different at school than our rules at home? Do you think they are fair?
9. Who did you sit with at lunch?
10. Can you show me something you learned or did today?

Wow! What a great list! When I started asking a few questions, the child started answering! No longer it was, "I don't know!" or shrugging of shoulders! Feeling happy seeing that in action, I thought how cool it would be to have such an open-ended conversation starter for team building, lessons learned sessions, or retrospectives.

Conversation Starters for Teams

1. Tell me about the best part of your work today. 
2. What was the most difficult thing you had to deal with today? 
3. Did any of your team members do anything that made you happy or sad? What was happy or sad about it?
4. Tell me about what you learned from your work today.
5. What stakeholders did you interact with today? What was the focus of your interactions? 
6. Do you think [Customer Service/IT Role/QA Role/PM Role, etc.] is too easy or too hard? Why do you think so? 
1. If you were to have someone switch their role with yours, what do you think they would so about your role and responsibilities?
2. How much are you willing to do a role swap and see how their role is for a day or two? If not, why?
7. What's the biggest difference between the last iteration and this iteration? (last project and this project, last year's customer interactions and this year's). 
1. What do you think contributed to it? 
2. What can we do differently to make it better?
3. What do you think would be a better outcome if you disagree or feel it can be better?
4.  What else?
8. What rules are different between your last role (or company) and this role (company)? Do you think our rules are fair? 
1. If you changed something, what would you change and why?
2. If you added something, what would you add and why?
3. If you deleted something, what would you delete and why?
9. Who else did you interact with outside of your core work responsibilities?
1. Who are they? 
2. What are they doing?
3. How is their work connected with ours?
4. How do these interactions demonstrate belonginess? 
10. Can you show me something you learned or did today (this week)? 

The most important thing for me is that I was able to learn at a time and place where I thought I knew. At least, I never thought I would learn something from a kindergartener babysitting event! Every interaction is a learning opportunity. 

What do you think we can add as open-ended questions to promote continuous team camaraderie and organizational belonginess?