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