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? 

The Multiple hats of a Strategic Account Manager

In one of the discussions on career coaching with a candidate looking forward to moving up to the position of account manager, I had the opportunity to reconnect with one of the trainings that I did with the Rain Group's Strategic Account Manager group. In the PMO I managed at my previous company, I had Strategic Project Managers who were also responsible for their client accounts owning the responsibility to grow their accounts. Similarly, I had some product owners and business analysts that were responsible for improving the product and/or the platform with features competitive in the market! 

As part of the strategy, anyone associated closely with strategy is supposed to be results driven but also have a relationship focus. They need to be not just strategists but also strategic executioners managing the project initiatives innovating with solutions, collaborating with various stakeholders including technical and analytical experts. The Rain Group also recognized that the strategic roles, particularly strategic account manager role, should incorporate the six roles, results driver, relationship lead, innovator, collaborator, technical expert, and project manager (Schultz, n.d.). 

I have always connected these roles not as separate individuals but the same individual being able to think from the responsibilities of all these six roles. So, when I had this candidate asking about the multiple hats one should wear, I immediately connected with deBono's (1999) six thinking hats from my scholar-practitioner experience. So, are there any reasonable insights we can draw between the scholarly suggestion and practitioner's recommendation? 

Briefly summarizing deBono's (1999) six hats, there are six hats. These hats are not meant to be associated with a specific role but with the responsibilities that one should connect with. The intent is that a person can wear more than one and either many or any hat as the situation/personality warrants. 

1. The white hat is associated with facts and so focuses on numbers closer to reality. 
2. The red hat is associated with feelings and so focuses only on emotional thinking! 
3. The green hat is more about creativity, innovation, and optimism thinking outside the box.
4. The blue hat considers processes and highlights organizational efficiency. 
5. The black hat is generally skeptical weighing conservativeness than considering risk orientation. 
6. The yellow hat is positive or optimistic and doesn't see failures as bad.

In my mind, the white, red, and green hats are focused on facts, data, insights, and patterns. I call these persona "high tech." On the other hand, blue, black, and yellow balance it with people, feelings, emotions, and ideas. I call this persona "high touch." So, it is important to balance both the high-tech and high-touch and so I also have associated the practitioner roles with suggested pairings to keep the decision-making and problem-solving in balance.

Rain Group Practitioner Role	deBono Scholarly Hat
Results Driver (Decisive)	White Hat (Pair it with Consensus Yellow Hat)
Relationship Lead (Relationship)	Red Hat (Pair it up with Skeptical Black Hat)
Innovator (Innovative)	Green Hat (Pair it up with Analytical Blue Hat)
Project Manager (Analytical)	Blue Hat  (Pair it up with Innovative Green Hat)
Technical Expert (Skeptical)	Black Hat (Pair it up with Relationship Red)
Collaborator (Consensus)	Yellow Hat (Pair it up with Decisive White)

What are your thoughts? Would you see them differently? If so, how?

References

De Bono, E. (1999) Six Thinking Hats, Back Bay Books, New York 

Schultz, M. (n.d.). 6 Strategic  Account Management Roles every company needs to know about.  https://www.rainsalestraining.com/blog/6-account-management-roles 

How different is Strategic Project Management?

One of the repeated questions from people attending my training on project management is that their roles within their companies have reinforced that project management is all about delivering an agreed scope of work on budget and on scope. But project management has been focused for several years on delivering a unique product, service, or result. While timely delivery of agreed scope within budget is the focus of the minimally marketable feature (phase/minor release) aspects, the focus of the project manager is strategic on the product with a long-term orientation using the notions of rolling wave planning and progressive (increment) elaboration (iteration). This is the reason why even the Project Management Institute has professional developmental units based on the PDU talent triangle incorporating the strategic and leadership components.

So, how different is strategic project management?  In simple words, I view that strategic project management is all about making project management indispensable for business. This involves a laser focus on the following requiring a project manager to look holistically at the bigger picture while executing the assigned projects. As you can see, only #4 in the list below is about traditional project management focus - Focusing on outputs and capabilities!

1. Developing initiatives to deliver benefits 
2. Supporting projects with programs and portfolios 
3. Aligning value with the strategic business case
4. Designing and implementing projects
5. Measuring results against the benefit realization 

The initiative development to deliver benefits requires one to think big wearing multiple hats to analyze business drivers to maximize solution benefits. The strategic project manager must be able to develop clear strategies along with a roadmap at a level that can be audited for delivery! When producing capabilities from the projects, the strategic project manager may also have to think of the talent (skills and competencies) required for future valuable work. 

The program and portfolio support requires the strategic project manager not only to execute their projects but be a voice for program and portfolio to develop and execute program roadmap and select the right projects and program inside the portfolio. This project selection may require support to balance resources within the portfolio using risks as a pivotal catalyst to manage overall portfolio performance or program benefit delivery. 

Since value is a measure of the degree of benefit realized by the users, the strategic project manager will be skilled at facilitating larger meetings directly or remotely addressing many types of stakeholders, understand and support creation of the strategic business case for capital budgeting as well as financial controls and continue to identify, analyze, evaluate and treat positive and negative risks through their projects and the other projects, subprograms, and program related activities. 

The strategic project manager's role in designing and implementing projects is the basic competency. In this capacity, the strategic project manager focuses on setting major release (phase) and minor release (iteration) goals, aligning these goals to the strategic goals and roadmap, linking deliverables to outcomes and benefits, and monitoring the progress of the project through a combination of lagging and leading indicators as appropriate.  

Finally, in the benefit realization, the strategic project manager supports contribution of project performance to objectives and key results (which are beyond KPIs), evaluates benefit realization through ROI indicators and recommends what new initiatives need to be brought or what existing initiatives should be terminated, parked, or modified!

As we look at people talking about project manager role is missing in Agile or Scrum frameworks or that we need to move from 'project' mindset to 'product' mindset, we are looking for strategic project managers that have long-term orientation for value delivery. These claims do not mean project management skills are not required but the project manager competencies need to be upgraded. 

What do you think? Thoughts? Please share. 

Awesome project management is the heart of a successful product management

It is undoubtedly apparent that the agile approaches to software product development is on the rise and is also finding its ways to other industries. On many of my training sessions on the traditional and agile project management and in certification preparation classes, one question always comes up on the scope of career growth for project management as a profession with the increased focus on agile principles. It seems like most of the Scrum focus on product owner and scrum master without calling for a project manager role appears to have stirred up a concern on product management. Worse yet, the Scaled Agile Framework (SAFe) tries to mimic Kerstein (2018) thoughts of moving from project to product thinking without truly understanding the author's emphasis on elevating project level thinking to product level thinking instead of telling project management principles are no longer relevant. So, is product management going to kill project management? What will become the role of a project manager in an agile setting?

If we review the basic definition of the project, the experts in the field agree that the project is a temporary endeavor to create a unique product, service, or result. The PMBOK guide (2017) further notes that although projects may be temporary, their deliverables may exist beyond the life of the product.  Inherent in this definition lies an inexorable relationship between these two disciplines. The premise of the strategy is long-term and if the product has a long-term focus, so should the project management focus also be in sustaining the product over a long-time horizon.

Nevertheless, this distinction of project management doesn’t come through because the project managers fail to view themselves as the change agent responsible for a set of processes, tools, and techniques indispensable to bring a product, service or result to the market. Therefore, a product cannot be delivered without a strategic focus on execution that only the discipline of the project management can provide through the phases of initiation, planning, execution, control, and closure. Even strategic project managers are required to have the project management skills, says Mike Schultz (2018), president of Rain Group.

Does that mean product management is a subset of project management? Definitely not! As noted, product management has a longer time horizon compared to project management. So, everything a project manager must do gets magnified in product management as they need to truly understand the complexities of the behavioral changes in the consumers using the product as well as the continuous and competitive forces changing the market demands. It is no wonder therefore even the product management toolkit (Gorchels, 2012) identifies project management competencies as a core foundational skill of product manager (p. 9).

Image Credit: Created by Author for illustration

As a result, there is a healthy symbiotic relationship between product management and project management as they don’t compete but complement each other.

For one to consider the relationship between product management and project management, let us look at their life cycle. As a new product idea or significant feature for an existing product is conceived, the product management may focus on generating the ideas, evaluating the alternatives, assessing the viability, evaluating the technical, operational and environmental feasibility, and creating a business case at the beginning (The Standard for Program Management, 2013).

Hence, the product manager will have to think strategically about scouting the external and internal environments by applying Porter's 5-force model. This 5-force model involves the availability of substitute products, bargaining power of the buyers (price consciousness of (buyers), bargaining power of suppliers (understanding the vendor environment supplying goods), rivalry among the established firms (fierceness of the competition), and the threat of new entrants (innovative opportunities that can stifle the market). 

Finally, the business case from product management becomes the starting point establishing the authority, intent, and philosophy behind the business need, for the portfolio governance to issue a program mandate following a program manager assignment (The Standard for Program Management, 2013). While some projects are often beginning from a statement of work (SOW) with contractual requirements of using the product’s inherent capabilities to customize or support the customer’s needs, more substantial projects and vital programs may be started from the program mandate.

These programs, made up of many other interdependent projects and operations, deliver incremental and unified benefits by creating the entire architecture enabled by the technological platform and the required infrastructure to sustain and support the product, service, or result that these larger projects and programs create. Therefore, the lifeblood of product management is the project and program management.

It is, therefore, evident that the product management defines what we should be doing and where we should be going while the project management tells when and how we could be getting there. The product roadmap becomes the essential milestone that the project manager should schedule to reach. As various milestones are achieved in the product roadmap, benefits may have to be realized and validated before continuing to invest in the next phase of the product journey initiating the project charter for the next milestone.

Phoenix Image Credit: Downloaded from Pixabay.

Consequently, the field of project management is like the Phoenix bird that ceases to exist as soon as that milestone in the product roadmap required by product management has been served. However, as the product management continues its journey through its lifecycle of development, growth, maturity, and retirement, there will be additional needs that will come up, and the Phoenix bird revives itself again. The Phoenix bird never dies!

Therefore, excellent product managers will know that they need strategic project managers as their brainstorming partners and similarly, successful project managers will have more strategic thinking beyond the organizational context to support the product managers.

Each profession, as a result, has a symbiotic relationship. The more project managers learn about product management philosophies, and the more product managers get grounded on essential project management foundations, the more they both support each other in the success of the performing organization through innovative products and excellent customer service.

References

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

Gorchels, L. (2012). The Product Manager’s toolkit. 4th Edition. New York, NY: McGraw Hill.

Kerstein, M. (2018). Project to Product. Portland, OR: IT Revolution.

Schults, M. (2018, February 7). 4 Skills your technical sales experts need to have. Retrieved February 26, 2018, from https://www.rainsalestraining.com/blog

The Standard for Program Management (2013). 3rd Edition; Newtown Square, PA.: Project Management Institute.

Do not let the need for "greater" impede the progress of "good"

As I was wrapping a project management training session, I heard a comment during the closing from one of the learners. This learner said they understand the concepts of project management principles much better now and can contribute to their organization more effectively but can never excel as me. It is great to feel that people can take the learning and apply it in their personal and professional lives. The time people spend going through training and certifying themselves for professional certification tells me that there is a compelling underlying desire for people to be better. The question is if this 'better' version is against themselves or in comparison with others! The learner's comment about never excelling as another person (that is, me) made me bring one of the things that I always mentioned to the people that reported in my PMO organization. That is "Don't let the need for 'greater' impede the progress of 'good!'"

"Why try to be me? Why try to be anyone for that matter?" are some of the questions that I started asking this learner as that means the personal identity is taking a backstage. The only focus of continuous improvement (Kaizen) is to become a better version of themselves. As part of my training for younger high-school students in my PLOT (Projecting Leaders of Tomorrow) training, I emphasize, "If yesterday was your baseline for potential or performance, what are you doing today to improve for a better tomorrow?" Should that not be the focus for professional adults rather than benchmarking against someone else! If any training or certification does not fuel the fire for continuous improvement, then, they have not succeeded!

I recall thoughts in the research driven book, Build to Last (Collins & Porras, 1994), on how leaders should instill the message of comfort not being the objective and should not replace 'doing well as an end objective" over "endless pursuit of doing better for future." It is understandable that people want to strategically (competitive advantage) improve but is the goal of every company to kill the competition? We will be creating a monopoly in that case and that is not good for the overall society! The pursuit should be to learn from the competition and position themselves better to serve our customers in the targeted market. If companies as corporate citizens are to be a better version of themselves (McLeod, 2014), then, why are we trying to be competing with others instead of complementing each other through strategic partnerships?

As my son was expressing discontent about the assignments in online learning management system showing too many future assignments (The online environment for high school in the pandemic was not an easy transition, but that is another topic), I mentioned to him to "take good care of today and the tomorrows will care of itself!"   I believe this logic of focusing on becoming good for today should not stop us from becoming greater in comparison to someone else. That is the focus of Kaizen (continuous improvement). There are several authors that also talk about focusing on the moment (Maxwell, 2012) and the power of now (Tolle, 1999) about improving oneself to grow. 

I recall the star fish story I heard from one of the leadership classes from Academy Leadership that I attended a long time back (Jim Nalepa, personal communication, February, 2020). As a man was strolling the beach, he saw a boy dancing on the shore. As the man approached the boy, he saw the boy gently picking up throwing star fishes washed ashore. When the man responded to the boy that the boy can't make a difference as there were so many star fishes on the shore, the boy continued throwing one more star fish to the ocean and said, "Well, Sir, it made a difference to that one Star fish!"   

So, focus on yourself every day. Instead of counting the days, make the days count! The more one can manage themselves, the more one can inspire others to manage themselves. This is why we say, "rising wave raises all ships." So, let us focus on self-growth for today and not let the comparison with others to be better demotivate from doing anything good. 

Don't let the need for "greater" impede the progress of "good". Everybody can make a difference every day! In living their life as best as they can, they are impacting others!

References

Collins, J. & Porras, J.I. (1994). Built to Last. New York: Harper Collins Publications.

McLeod, L.E. (2014). Why killing the competition is not a noble purpose. Retrieved April 13, 2021, from https://www.forbes.com/sites/lisaearlemcleod/2014/06/18/why-killing-the-competition-is-not-a-noble-purpose/?sh=39a5469a4498

Maxwell, J. (2012). The 15 invaluable laws of growth. New York: Hachette Group.

Tolle, E. (1999). The Power of Now: A guide to spiritual enlightenment. Novato, CA: New World Library.

 

Attendance in a Meeting is a Contract

As we are constantly acclimatizing with the pandemic enforced virtual remote teams, I have been to numerous personal and professional meetings on many virtual collaboration platforms. I am sure we have all heard, "You are muted," "I am muting you!" "We can't hear you!" And, we have also had too many people in a meeting where we have the same people logged in on phone and on the collaboration platform, participants that we don't know who they are because they have not named themselves and people technically (on the platform) present but absent in the meeting to contribute (physically in the kitchen brewing coffee). Moreover, we have seen people speaking over each other or distracting others answering personal calls with everyone listening! 

Yes, I used to say 'meeting etiquette' to address these issues but considering some of these continued observations, I feel that attendance in a meeting itself is a contract. It is an agreement that we owe to professionally hold ourselves accountable to others. So, what could these working agreements look like? Here are my thoughts on such a contract holding professionally beneficial and productive meetings.

1. Avoid meetings with too many people
• Large meetings waste valuable time and energy. Discussions may involve more time which many don't have to contribute effectively. Recall there is a cost to meeting (Rajagopalan, 2014).  When controversial topics or alternatives require provocative thinking, people become defensive than open when communicating online with many watching. So, do not schedule large meetings unless we are certain that it provides value to everyone in attendance.
2. Do not invite people to meetings or decline meetings if there is no contribution required
• When inviting people to a meeting (whether one directly invites or whether the meeting is forwarded to others), we should ask if that participant will have any input to the agenda (or action items that may emanate from the discussions) and add more value based on subject matter expertise or decision-making authority. If neither input, value, or decision-authority are part of their responsibility in a meeting, we should neither invite, nor forward or accept meetings. Instead, it is better to decline such meetings when one is not contributing. 
• It is better to mention why one will not attend the meeting rather than attend the meeting and waste their own and others' time without any contribution.
3. Revisit other channels of communication 
• Collaborate with colleagues directly rather than schedule meetings with the supervisors or managers. Such collaborations build the team camaraderie and the much-required relationship for team cohesion enabling faster team member level decisions.
• Use emails or chats to follow through on meeting action items. 
• Be respectful of manager's time. It is better not to (blind) copy them on all communications flooding their inbox rather than consolidate your updates in one email to the manager.
• I use subject line prefixes like the following in my communications with the Chief Operations Officer (COO) when I had to be very careful with how much and what I communicate. I set these expectations with my manager, and it was very helpful.
• NNTO - No Need To Open (Subject line itself has the message)
• FYI Only - For Your Information only
• RR - Response Required (Not urgent but need some response by the end of the week)
• AR - Action Required (Urgent response required before end of the day)  
4. Communicate expectations before the next meeting
• It is important to have people own their action items. Have members summarize what they will do before we plan to meet next or before they may be impeding others work.
• It is important to be clear rather than always be clever.
5. Avoid frequent and recurring meetings
• If subsequent meetings are not required, cancel them. 
• Don't schedule meetings to follow through on action items (everyone is a professional for us to micromanage).
• Hold 'office hours' type of meeting where people can drop in and have their questions answered. 
• Do not interrupt people's workflow by requiring them to attend unnecessary recurrent meetings unless they add value (like a 30-60-90-day meeting, etc.)

What are your thoughts? Would you add, modify, or delete something in my list? Look forward to your insights.

References

Rajagopalan, S. (2014). Effective virtual meetings. https://agilesriram.blogspot.com/2014/05/effective-virtual-meetings.html

INVEST: Deeper Look into Iteration Planning

One of the things that I love is mentoring and coaching some of my past students as part of a lifetime commitment to grow people and grow myself.  I engaged with a group of such students from my training batches who were talking about iteration planning.  As part of the conversations, I felt that the primary reason for doing iteration planning in two parts was becoming more of a transactional "this is how we do it here" mindset rather than practicing the transformational "let us rethink why we do what we do and how to sow the seeds of success" mindset.  

In Agile framework, we promote the approach of INVEST property for a user story. It stands for independent, negotiable, valuable, estimable, small and testable. Now, is there any connection of this approach to the 2-part iteration planning! In the first part, the expectation is that the product owner identifies the prioritized stories based on the iteration goals and objective (which should be aligned to the product strategy and organizational strategy). This first part ends when team members have agreed to work on a story. In the second part, the team members estimate the work required, divvy up the story into its constituent tasks and agree on the criteria used to validate the completion of work. The second part ends when the entire team has committed the specific stories for the iteration starting the sprint! 

So, how does INVEST apply to these two parts?  I suggest we break up the INVEST itself into two parts. Every component of INVEST drives the concept of risk in development so that the team makes the logical decision during iteration planning and yet take calculated risks for experimentation. To me, this approach extends what I call risk driven development (RDD).

1. The first part of INV is associated with part 1 of the iteration planning. The focus of this part is answering the question, "Does the selected stories add value to the user, customer, stakeholder?" 
• While the product owner is accountable for the stories to be selected, the team is equally responsible to consult with the entire team and inform how stories may have to be split to avoid dependency (one user story waiting for another user story to be complete), which is against the lean principle of flow. When this is done, the stories agreed or independent! 
• The product owner may only look at commercial or user perspective. It is the team's responsibility to negotiate with the product owner on how some other priority order of user stories may have to be done to set the architecture for features coming up in the future. Furthermore, the team is also given the space to experiment with some "should" or "could" type of stories rather than commit to all the "must" stories with no opportunities to fail forward! (Rajagopalan, 2018)
• As part of these negotiations, the entire team is focusing not only customer and business value but also on the technical and process value (Rajagopalan, 2019). That means the combination of stories are valuable.
2. The second part EST is associated with part 2 of the iteration planning. The focus of this part is answering the question, "Does the selected stories fit into the iteration?"
1. The focus of timeboxing is to facilitate sustainable pace (which is one of the 12 agile principles). So, the team pointing exercise is for the team to collectively estimate the individual stories and evaluate if the set of stories can be done (Rajagopalan, 2016).
2. While each team member can contribute to the collective story estimation (e.g.: Planning Poker), the stories should be small enough for the team to decompose the stories into the tasks (for completion). The team should not commit to five 13-point stories as the risk of delivering them may be higher. The more they fail on finishing the story in the iteration, the more they will be demotivated seeing the charts on planned versus actual velocity! There is a reason why we use a geometric sequence for points to facilitate this complexity in stories.
3. Finally, stories should be with the intent that once it is approved, it can be deployed! Granted there are other considerations like single cadence, multiple cadences, and release on demand for ensuring value delivery. Nevertheless, what are the things to validate as part of the verification and validation? That is part of the acceptance criteria (called confirmation as part of the 3C's of a user story). So, in addition to tasks for completion, testability of the user stories should be factored with multiple test cases (involving a combination of manual, automated, scripted, exploratory) for every user story aligned with the product owner acceptance criteria. Such a notion is a prerequisite to test driven development (TDD), behavior driven development (BDD), acceptance test driven development (ATDD) and hypothesis driven development (HDD). 

I hope this approach helps people understand the rationale behind INVEST. Tools and techniques are important but are useless when the principles are not understood! Wouldn't you agree?

References

Rajagopalan, S. (2016). Agile or Traditional: Productivity Management still has basic roots. 

https://agilesriram.blogspot.com/2016/06/agile-or-traditional-productivity.html

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

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

Redefining Value in Artificial Intelligence Solutions

Recently, I worked with a student group for their interview preparation. These students were from Informatics major. In some mockup preparations, I engaged in asking questions about the value of their contributions to the business. All their questions focused on technology and nothing about cross-functional implications of technology enabled solutions. About six months back, I had the opportunity to develop the curriculum for Northeastern University for the Informatics Capstone class (Rajagopalan, 2020b) where I continued to emphasize on the use of technology in business decisions. I was heartbroken to see that the student's interview preparation focused on technology aspects alone. 

I discussed four questions people should ask themselves in developing AI based solutions (Rajagopalan, 2020a). These questions were primarily based on Digital Ethics proposed by Beauchamp & Childress (1979), such as the beneficence (do good), non-maleficence (don't do bad), autonomy (giving options), and justice (be fair). I have added in parenthesis some simple definitions of these principles. As you can see, anyone in the practice of creating an AI enabled solutions that uses data and patterns for insightful problem solving or faster decision-making must hold themselves accountable for the impact they have on the people through their solutions.  

As I thought about the gaps that these students had in using technology to solve a problem, they mostly focused on capabilities, sometimes on outcomes, rarely on benefits and value. Readers should read my blog (Rajagopalan, 2020c) on strategic project management from a dental visit on how the terms capabilities, outcomes, benefits, and value mean. It dawned on me then that the term, "Value" itself needs to be redefined from its "Business" focus to "Ethical" focus. 

In business, value is defined as the degree of benefit someone derives from the solutions that we have provided. The value in a business context is frequently evaluated in terms of strategic outcomes and compliance with procedural practices. These procedural practices are often codified in organizational policies and processes, adopted from company specific methodologies used, and guidelines embedded in cultural norms. 

However, when we factor ethics into account, we dig deeper into the rationale and reason! It is no longer about the profits and markets but people and the planet. The "greater good" discussions require everyone to demonstrate leadership (regardless of one's role) where value stands for doing the right thing by questioning the impact of our solutions on people and planet. That is the foundation of ethics where we focus on fairness, responsibility, honesty, and respect. Now, the digital bioethics principle extended from care for the people, despite their simplicity may be difficult for many to implement any of them correctly. So, I thought about what guidelines and guardrails to provide? 

After much deliberation, I came up with the notion that everyone in designing or developing any AI enabled or embedded solution must consciously evaluate four considerations. These are fairness, alternatives, risk management, and efficacy. I feel that any product developed based on AI enabled services or embedding AI services should evaluate against these areas to support the digital bioethics. Let me elaborate. 

Fairness: In this area, I think we can question the inherent assumptions we make on the persona represented in the target market for the product! Asking the following sample list of questions may help us check against beneficence and non-maleficence.

1. How are any assumptions we make demonstrating our bias?
2. To what extent are we documenting our assumptions transparently so that the solutions distinguish what demographics of the population will not be served by our solutions? Or worse, not served correctly!

Alternatives: In this area, I incorporate the considerations for experimental and explorative concepts but still provide choices or options for the people to work around the "edge cases" our solutions will not support the targeted market. So, despite our intentions to avoid false positives or false negatives, we leave options on the table. Asking ourselves to come up with the following scenarios may help us elevate ourselves to autonomy and justice. 

1. What measure do we put in place for users to reject our recommendations (and allow us to learn)?
2. What options do we allow for people to reject using our solutions or recommendations?  

Risk Management: I feel both the fairness and alternatives thinking are rooted in our risk management discipline. I feel that anyone who does not have a basic understanding of risk management framework should not be allowed to design or develop any AI enabled or AI embedded solution. 

1. Familiarizing ourselves against risk management lifecycle (identification, assessment, evaluation, treatment) ensures that we can understand the categories of risk (safety, security, data privacy, informed consent procedures, etc.) and document the risk breakdown structure. 
2. Consequently, we can understand the likelihood (probability), impact (severity), and detectability (either in a qualitative, semi-quantitative, or quantitative scale) so that we can contribute to assess the risks and their impact on the solutions we conceive, design and develop. 

Efficacy: This last element is what evaluates the value of our solution because it evaluates the degree to which our solutions can influence the desired behavior by producing the intended results correctly and consistently. 

1. Such thoughts should be factored in applying risk management concepts on exception scenarios, such as thinking as an abuser (Rajagopalan, 2015) so that we protect the user and their data. 
2. In technical solutions, we can think through all code paths (not just happy path testing) but think through scripted and unscripted ways to use testing to augment quality.

What are your thoughts?

References

Beauchamp, T.L. & Childress, J.F. (1979). Principles of Biomedical Ethics. New York: Oxford University Press.

Rajagopalan, S. (2015). Abuser stories: What shouldn't the software do? https://agilesriram.blogspot.com/2015/09/abuser-storieswhat-shouldn-software-do.html

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

Rajagopalan, S. (2020b). Sriram's Approach to Course Design. https://youtu.be/DAVuICDWBpo

Rajagopalan, S. (2020c). Lessons Learned on Strategic Management from a Dental Visit. https://agilesriram.blogspot.com/2020/08/lessons-learned-on-strategic-project.html

Distinguishing Operations from Program Related Activities

As part of supporting some PMP candidates who had the titles of program manager in their organization, there was some confusion between operations and program related activities. In general, according to the Project Management Institute (PMI), a project is temporary endeavor to deliver unique product service or result. It does not include operations. However, PMI defines a program as a group of related projects managed in a coordinated manner to obtain benefits not available from managing them individually. Since benefits are a core element of a program, benefit transition involves operations, and benefits are realized through and sustained in operations, many confuse operations to mean the program related activities. This interpretation is incorrect.

If the keywords that distinguish a project or "temporary" (timebound) and "unique" (new functionalities, improvements to existing functionality, etc.), then a program is distinguished by "related" and "benefits" with a focus on "coordinated". Since a program is composed of program components (such as sub programs and projects) that are timebound, a program is also temporary in nature. So, a program does not involve operation. However, a program focuses more on transitioning the benefits to the operations team through many methods including training and documentation. Please note that outcome is an operational state and so benefits must be transitioned to operations team. As a result, although the program itself does not manage the operations, program management focuses on the transition of benefits to the operations so that the benefits can be sustained in production by the operation team. 

So, what are program related activities? Now that we understand operations, we can appreciate why we need program related activities. As programs focus on benefits integrated from multiple outcomes from related projects, there needs to be a focus on "coordinating" the activities within the program. Hence, many activities that are not operations but are required to ensure that the benefit can be transitioned to operations come into picture. The extent of all these program related activities differs across programs, companies, and industries but the following is a good start.

1. Initiation and Prioritization of Program Components

2. Handing Escalations (Risks)

3. Handling project level interdependencies

4. Allocation of resources to Program Components

5. Program related lessons learned

6. Transition activities like Training

7. Reward and Recognition

8. Procurement at the Program Level 

What are your thoughts? Would love to hear your insights.

References

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

The Standard for Program Management (2013). 3rd Edition; Newtown Square, PA.: Project Management Institute.

Five Essential Documents in Project and Program Management

One of my former students in a leadership class in Boston approached me regarding an initiative the student was spearheading in Bangalore, India to work with several local healthcare professionals to convert a local unused building to a healthcare facility to extend care for the many COVID-19 patients. As I extended some level of project level support to this student so that this initiative turned successful, I felt like some essential documents were not in place to guide people in their work. Some of these documents can be very detailed and extensive but each serve a unique purpose without which value can't be realized. 

Justification Document: The business case is the justification document. It justifies the need that is required in the targeted market and further justifies the business value by completing an initiative along with the costs of working on this project over any other initiative. It goes into the details of strategic considerations (application of systems thinking), financial modeling (debt, equity, retained earnings), solution alternatives (application of design thinking), resource organization (internal resources, procurement, application outsourcing, business process organization, disaster recovery/business continuity), and the management (who, what extent, span of control, governance thoughts) considerations. Every one of these considerations is loaded with uncertainty (hence, risk management plan at the portfolio, program, and project levels). Consequently, this business case gives a measure by which value is evaluated over a time horizon. It is also a sensitive document that justifies details on the timeline, resources, funding, and even what other initiatives may be compromised, etc. There may be even models created to support the details. As a result, it is a lengthy document (>100 pages) and can't be shared with everyone (and shared on a need-to-know basis).

Authorization Document: The charter authorizes the project formally and identifies the project or program manager. It will be a very high level requiring the project/program manager to develop it further to understand the expectations on high level scope, high-level timeline, and a high-level resource (it may include cost) so that the stakeholders make the commitment on resources and demonstrate the engagement needed from everyone to demonstrate success. As a result, the project/program manager is given the "authority" to problem-solve and decision-make for tactical changes. Please note that the charter is not a legally binding document and hence is not considered a contract and that a business case is always more detailed than the charter.  The charter is visible to everyone and hence should be 1-2 pages so that the stakeholders ACE (on alignment, commitment, and engagement) for success (of program or project). 

Baseline Document: The integrated management plan is the baseline document. Any management plan is a tactical document! In this document, the high level scope has been decomposed into deliverables (or into component management plan in programs), initial or primary risks have been identified, assessed, and evaluated, the timeline has been drawn with phased milestones for funding and invoice schedules, cost baseline and contingency reserves have been established, quality management plans have been documented, stakeholder engagement and communication plan has been drafted and agreed upon, and resources and procurement management plans have been approved. This document serves as the baseline of how progress is made, and changes may be required during the project/program delivery lifecycle. 

Approach Document: As you can see from the baseline document, there are many things that a project or program needs. From a higher-level stakeholder perspective, the roadmap serves as the approach document focusing on the timeline of when the project or program will be delivering the promised benefits. Roadmap focuses on chronological (timeline) order (prioritization) advocating (communication) the intended direction (benefit delivery to stakeholders) major milestones (decision points) graphically (shows dependency). It doesn't go into the details of the deliverables in the minor milestones but builds a visual chart with high level releases or iterations in a phased release (rolling wave planning). It is mostly modeled after a Gantt Chart (without delineating individual deliverables, tasks, dependencies, or milestones). Occasionally, the roadmap could be a tabular list of milestones, the delivery due date, and the list of benefits (and hence the reason why benefits register come in). 

Value Document: The benefits realization document (or benefit register) comes under the larger benefit management plan and captures the steps and owners necessary to realize the unified (consolidated) or incremental (recurrent) benefits from the roadmap into value. This value document, therefore, identifies benefit details, stakeholder responsible, measurement considerations, and tracking of value delivery. 

While many other documents, like the RACI, risk log, issues log, status documents, backlog, qualified seller list and many others are relevant in project and program management, these five documents above (justification, authorization, baseline, approach, and value) are the most critical documents that are non-negotiable and cannot be missed. 

Thoughts? Please share. 

References

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

The Standard for Program Management (2013). 3rd Edition; Newtown Square, PA.: Project Management Institute.

Difficult Conversations through Effective Feedback

One of my neighbors was a virologist and was working through a difficult time! While most people were home due to the COVID-19 restrictions, this neighbor was working at the lab for almost 7 days a week and more than 12-15 hours a day! She was supporting the COVID-19 team in looking at several ways to come up with a cure!  Occasionally, I even drove this person to the workplace and supported in other capacities like buying groceries, etc. With time, however, the exertion and fatigue rubbed on the neighbor and the neighbor was finding work-life balance difficult. There was even frustration of not being able to find the cure as fast as possible! 

Now, I have written articles on feedback that it should be FACT driven (Rajagopalan, 2019) and the guidelines for giving and receiving feedback (Rajagopalan, 2020). When emotions were high and people were tirelessly working towards something as important and impactful as this COVID-19 cure, I found it difficult to motivate the neighbor. I wanted to appreciate my neighbor for the commitment to the profession and not get frustrated at failure. Although I feel that failure is not final, I found it challenging to find the right word choices. 

The following captures some of my thoughts for anyone who may be in the same predicament. Please keep in mind that these are just guidelines. However, we must remember to discuss the impact of the things we notice and the focus on behaviors we would like the individual or team to emulate. Subsequently, we should summarize the discussion to converge on working agreements for continuous improvement. I used this approach with my neighbor complimenting the contributions at a significant event in human history and that connecting with the emotions expressing frustration is fine. I found that it gave me a framework for giving feedback (of course after patiently engaging in active listening). 

Phrase	Individual	Team
I liked	List 1-2 the positive result of the behavior	List 1-2 impacts on the overarching team objectives
I didn't like	List what was unacceptable and discuss on the impact and lack of personal influence	Discuss the impact of how the behavior contributes to an adverse team environment
Do more of	Appreciate the behavior and discuss its positive contribution	Discuss the impact of positive leadership and how we could promote such behaviors with all team members
Do less of	Discuss how the behavior is not productive and contributes to waste (muda), unevenness (mura) and overburden (muri)	Discuss unproductive contribution and how we can brainstorm ideas for addressing waste, unevenness, and overburden

Do you think this framework is good? Would you see something added, removed, or modified? Please share your thoughts.

References

Rajagopalan, S. (2019). Feedback should be FACT driven. https://agilesriram.blogspot.com/2019/03/feedback-should-be-fact-driven.html

Rajagopalan, S. (2020, May). Giving and Receiving Feedback. https://agilesriram.blogspot.com/2020/05/giving-and-receiving-feedback.html