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

Artificial Intelligence Solutions: Four Considerations extended from Digital Bioethics

The COVID-19 pandemic was tightening its grip globally! It was scarry! A few friends from India met on Zoom to check in each other. Many of us were discussing about how healthcare could be improved and delivered faster now that the Artificial Intelligence is here! As I have done some webinars on healthcare and had some exposure to medical fields, I shared some of my thoughts too! 

Unlike many who think Artificial Intelligence is relatively new that happened in the early 2000, the concept of generating insights from data and patterns are not new. During my senior year at the University of Madras, I studied Prolog on my own with an additional certificate program at Thyagarajar College of Engineering, Madurai. I learned how this Prolog language differed from logic driven and forward directional procedural languages with backward tracking of logic to look for patterns until a solution to a sub-goal was met! There were references to green cut that altered the procedural behavior of the program but not the logical behavior and the red cut that also changed the logical behavior. This was the precursor to Expert Systems (using software to learn itself).

Subsequently, when I was studying about information technology course certificate as part of Biomedical Engineering in University of Aberdeen during early 1990s, I had the opportunity to build a small clinical program using Prolog (which, sadly, I have now forgotten) on how to differentiate standard respiratory, cold, cough and fever related symptoms to either act as an automatic computerized first-responder or recommend an intervention from a healthcare practitioner.

Furthermore, when I did my graduate program in Detroit, I experimented with logical gates (AND, OR, NAND, NOR, XOR, NOT all of which facilitate algorithmic constructs like sequencing, branching, and looping in procedural languages) and neural networks in allowing hardware/firmware level learning that was applied in simulated anti-lock braking (ABS) in automotive space. 

Based on all these experiences, when it comes to using learned intelligent behavior, we need to ask ourselves a few important questions. These questions are almost analogous to the article "Managing Others: Four Simple Powerful Questions." (Rajagopalan, 2016). 

1. Does our knowledge extend to the new situation? We can't assume that our new knowledge applies without any reservations. To ensure that our knowledge can work in a new situation, we need to be consciously aware of the boundary conditions of our knowledge. Only when do this, we can eliminate blind spots in our thinking that can endanger the "beneficence" principle of digital ethics (Beauchamp & Childress, 1979; Nebeker, Torous, Bartlett Ellis, 2019). 

2. Who would be accountable for abuse or misuse? Even if we have addressed the first question very effectively, we must think through the unknowns and put process controls in place proactively to avoid any potential use of the product in an unintended way. Just like the discussion on abuser persona (Rajagopalan, 2015), it is important for us to look at what should our AI based solutions not do. I believe this question facilitates one to think about the digital ethics principle (Nebeker, Torous, Bartlett Ellis, 2019) of non-maleficence. In simple words, AI solution designers and developers should answer the question about the accountability of something wrong.

3. AI is meant to relieve us from mundane decisions so that people can solve more important problems. So, one of the questions we should ask ourselves is more of the "So what" type of question. In other words, how will the AI solution improve our productivity by augmenting efficiency, promoting effectiveness, and enhancing efficacy (I call them the 3E's of better product development (regardless of the type of solution like software or healthcare). For instance, I believe questions of consciously eliminating all bias and stereotyping so that the solutions are impartial promoting equality. Furthermore, how much do we give options for the users of these AI solutions when they are generating false positive (or false negative). The digital bioethics principles (Nebeker, Torous, Bartlett Ellis, 2019) continue to come to rescue with their principles of justice and autonomy.  

4. Lastly, the AI solutions should also look at whether these solutions are commercially and operationally simple, secure, stable, scalable, and sustainable (I call them the 5S of any solution). The scope of these AI solutions differs based on the intended target market it serves. As a result, various considerations such as economic affordability for the people, provider reimbursement and insurance payment considerations, etc. 

So, understanding these four elements of extensibility of solution to the targeted audience, accountability for unintended use, productivity enhancements of current situation, and commercial and operational considerations are pivotal in any AI based solution to accelerate itself to the market. So, while AI enhances the ability to accelerate decision-making, making AI based solutions needs to be  carefully orchestrated. After all, abuses and adverse effects should not be the experiments to new product development for mission critical applications or new product developments that can impact people. 

What do you think?    

References

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

Nebeker, C., Torous, J. & Bartlett Ellis, R.J. Building the case for actionable ethics in digital health research supported by artificial intelligence. BMC Med 17, 137 (2019). https://doi.org/10.1186/s12916-019-1377-7

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

Rajagopalan, S. (2016). Managing Others: Four Simple Powerful Questions Questions. https://agilesriram.blogspot.com/2016/09/managing-others-four-simple-powerful.html

Lessons learned on Strategic Project Management from a Dental Visit

Having trained individuals and companies on strategic project management as well as certification prep for PMP exams, one question that I always repeatedly emphasize is the differences between benefit and value. Even experienced professionals don't articulate these things clearly differentiating how a business case differs from project charter and why it is the foundation for any project or program. I normally try to give examples from the various industries connecting these thoughts. Interestingly, I found a simple and more effective example when I took my son for the orthodontic dental exam. 

As most orthodontic exams do, these exams focused on oral health focusing on teeth alignment using dental braces and retainers. Having gone through a few sessions, the dental assistant asked if my son was using retainers and brushing after heavy meals. My son was responding that he was occasionally doing them and not always using the retainers. The dental assistant replied, "You can only get the value of the retainer if you use it for its intended benefit!" Wow, two words, "Value" and "Benefit" used in the same sentence and made me connect how simple these concepts are. The dental office is providing the benefit by giving the retainers. Only when the retainer is used as required, the benefit is realized! That extent of timely benefit realization is the value for the customer! 

• So, in projects or programs, the deliverables (requirements, design, user stories, etc.) as part of the release, phase, iteration or sprint is just giving the output. 
• But, when these outputs are integrated towards a minimum viable product (MVP) or minimum business increment (MBI), then, these are providing capabilities. That means functionally they are available but operationally they are not ready.  
• When all these capabilities are integrated and transitioned, the combined capabilities become the outcome. Note that transitioned means, the outcome is in an operational state. If the project is not dependent on other project capabilities, then, these capabilities become the outcome. If there are multiple projects working coherently, then, all these capabilities from multiple projects must be integrated further to generate the outcome. 
• When these outcomes are utilized, then they serve as the benefit. Nevertheless, the benefit is what the performing organization is delivering to the customers. 
• Only when the customers use the benefit appropriately or realize an improvement over time, the value is recognized. 

Sometimes, the simpler examples bubble up to the top to illustrate these concepts. Different projects may have been involved in creating the various retainers based on various conditions. These projects may have to be working with other suppliers and vendors, who may have their own projects, to integrate these products, manufacture, and ship them to the dental offices. The manufacture may have realized some benefit because the dental offices paid for the retainers. But, has the dental office realized the benefit? Not until the patients come for regular orthodontic exams and use them. As the people play different persona in the value chain, the concepts of output, capability, outcome, benefit, and value also change. Nevertheless, value is realization of benefit delivered, benefit is the integration of multiple outcomes from one or more projects, and outcomes are the systemic integration of various outputs identified to be delivered at different points in time!

I guess, when we are ready, we see the explanations in daily life! 

What do you think? Thoughts? Please share.  

SMOG the way to managing change

I had an opportunity to visit the department of motor vehicles. As I was waiting for my turn, I began browsing some handouts and saw a reference to SMOG approach to switching lanes. When I took driving lessons several years back, I had heard this reference. Perhaps because it has become habitual after several years of driving, I did not think much about it. As I saw this reference, I thought about how this connected stakeholders and risk with change management. 

SMOG stands for signal, mirror, over-the-shoulder, go safely. People in the car are team members and people outside the car are the various stakeholders who may be interested in where you go or not. So, when one changes direction as any project may experience, stakeholders and team members need adequate advance warning.  These alerts and warnings are part of managing change. So, our communication through status reports should tell the story of where we are going to address risks as we take calculated planned turns or abrupt turns. We do not want anyone honking at us and SMOG helps.

With every meeting (regardless of the project delivery framework), how are we signaling or watching out for external signals (red light, no free turn) from other stakeholders and team members? Have we communicated our intent adequately in advance (activating 3-5 seconds before turning and stopping it after turning)? Have we set expectations of where we are going as well as watching for risks around us that could impede us?

Even if we have signaled, have we watched the dashboard, rear-view mirror, and both side mirrors for known paths we have traveled (in case someone is accelerating behind us risking our planned paths) and the side lanes (in case our actions may impede someone inadvertently).  These thoughts connect with how we manage risks (known unknowns) proactively and engage with stakeholders who may be positively or adversely impacted by our actions. In project reporting, we bring references to our proposed changes through change requests and get approval through former governance  

What if there are some unknown (to us) knowns (they do exist) like vehicles or pedestrians on our blind spots.  Our actions will impact these stakeholders’ unknown to us as well as others known to us. Since prevention is better than cure, we look over our shoulders rather than just rely on the mirrors or the blind spot signals in today’s cars. So, even when governance has approved, we communicate our intentions in advance with planned “go live” type of readiness assessment communication. 

When all these things are done, we make the turns safely at the optimum speed. The same logic applies in project deployments with contingency and fallback plans. So, you can see that basic driving skills are applicable in project change management. Can you now drive your project changes safely?

What do you think of my approach here? Share your thoughts.

Interview Questions to prepare for and ask the Employer

Many times, I support students who are seeking internship or employment opportunities. I have seen them do some research on the job, the company, and even look up potential interviewers. Over the period, I have mentioned that employers will ask questions outside of your domain specific questions for being a good team player demonstrating alignment with company values. Based on my experience having hired people in the PMO and supported hiring individuals in other business units, I have prepared students and even professionals asking them to prepare concise and clear responses to the following questions. 

1. Tell me about yourself
2. What strengths do you bring to this job?
3. How are you different from other candidates that may have applied for this job?
4. What are your weaknesses?
5. What market changes are you anticipating in the responsibilities associated with this role and how are you preparing for it?
6. Why do you want to work here?
7. Why do you want to leave your current role?
8. Tell me about a time when you had to deal with a difficult person or situation.
9. Tell me about a situation that you handled when things didn't go as you wanted or planned.
10. Tell me about a time when you had to solve a problem.
11. Tell me about a situation or time where you demonstrated leadership. 
12. Where do you see yourself in 3-5 years?

When the opportunity came for the candidates to ask questions to the employer, I found that most of the people that I have talked to have not done enough research on this area. So, I have documented a few questions that candidates can ask the employers. These are not about when you will hear from them or about compensation, etc. None of these questions have a specific order and people should pick and choose the right questions based on the interview. 

1. Describe the ideal candidate for this position. 
2. How do you think I performed in this interview?
3. What are the key challenges of this person?
4. Why is this position open?
5. If this position existed, what would be the great things that the previous person did in this role? What else could have this person done?
6. How do you measure my success?
7. Describe the process in place to evaluate me when I am working for (with) you.
8. Describe the culture here and 
9. How are decisions made in this team?
10. What types of training are given in this company?
11. What are the things that I can do to better prepare myself between now and your offer to hire me?
12. When will you be making the hiring decisions?  

What are your thoughts? If you were to add, remove, or refine the above questions, what are your suggestions for a future employee to prepare themselves?

Guidelines for Giving and Receiving Feedback

By definition, a project is a temporary endeavor to deliver a unique product, service, or result. Having trained many batches of PMP aspiring students as well as facilitated graduate level classes on project management and leadership, I always feel that every class or training is unique. Every interaction always brings something interesting meeting the 'unique' definition. The batch that I was wrapping was also similar in that there was specific guidelines. It extended some of my earlier discussions on feedback being FACT driven (Rajagopalan, 2019).

Guidelines for Giving Effective Feedback

1. Give feedback as soon as the behavior or event occurred so that the details are not lost in time
2. Factor the person's openness in listening to the feedback
3. Focus the discussion on what happened outlining the impact on the individual credibility, team cohesiveness, and project outcomes 
4. Lead the discussion towards the desired behavioral change 
5. Ask the person to rephrase the behavior change desired and check for understanding
6. Confirm the agreement gaining commitment on measurable actions supporting the behavioral change
7. Beware of non-verbal communication and renegotiate commitment 
8. Beware of your own cognitive and motivational biases 
9. Let the recipient own the action (as ultimately everyone has their right to deal with the feedback)
10. Ask for how you can support the receiver to own the action (as everyone may have different levels of maturity and guidance on support needed)

As part of these guidelines, our discussion continued about what one should note when giving feedback or after giving feedback.

1. Feedback should be given for both positive behaviors noted (appreciation) and negative behaviors observed (change). Let others do not feel that feedback session means constructive feedback only.
2. Feedback should be given when one's lack of action or behavior can be impeding other's progress. 
3. Feedback should be given when one's action or inaction has impacted you personally or professionally.
4. One should not give feedback while feeling emotional (angry, disappointed, upset, frustrated, etc.)
5. One should not give feedback when the recipients are not emotionally ready to receive it.
6. Feedback should not be given when there is not enough information or based on someone's feelings.
7. One should not use feedback as a mechanism to vent themselves.
8. Feedback should not be given when the time and place are not appropriate for the feedback to be received correctly.
9. Ask for feedback on how you provided the feedback
10. Ensure you are consistent in giving feedback and following up on your actions

Subsequently, I took it on myself to come up with a template for giving feedback. This is something like writing a user story or acceptance story. 

• When you <describe the behavior>, 
• I feel <how it made you feel>.
• Because I <share connections with the behavior as a team member>,
• I would like <state the behavioral change desired>.
• This would make <how the situation would be better>.

What do you think? 

References

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

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

OPA: Differences among Policy, Processes, and Procedures

More frequently that one realizes in my project management training as well the conceptual understanding of the organizational process assets, there is always disconnects among the three assets, namely policy, processes, and procedures. Contrary to many that think they are the same or almost similar, they are different. A specific organization may mix up the meaning within their firm. However, based on my limited exposure in working with these OPA elements, I feel that there is a clear conceptual hierarchy among policy, processes, and procedures. Sometimes, even the PMI materials do not differentiate them in the training materials causing confusion and chaos.  Let me elaborate first with an example.

Let us think of a simple security requirement in a company. Often, a company will have an IT security policy. They will differentiate physical resources such as the servers and access to these rooms from the non-physical security considerations like protecting intangible resources like data, memory, etc. 

For every type of asset identified, there may be additional processes. For instance, when someone must access the building to ensure that the temperature and humidity are within the tolerances, there would be a process. For people that develop software applications, there will be security processes like secured development guidelines. So, each policy may be governed by one or more processes (1:N) relationship between policy and processes. 

What if a named resource is sick or inaccessible but an entry to the physical building is required to ensure that the HVAC is working as expected! What if the person is available but must bring his children inside the building on a weekend? On the software development side, what if there is a contractor who can't access certain documents in a shared folder? How to remotely wipe out data on a phone that has sensitive company information including but not limited to software development details? 

As you can see, each process is not always a happy path scenario but considers multiple what-if scenarios. Each such scenario presents a risk when not protected appropriately. So, many procedures are written down in granular detail with the approvals that are required so that the company's assets are protected. So, each process is associated with one or more procedures (1:N relationship) supported by additional guidelines.

Each policy, process, and procedure may be supported by additional policies, processes, and procedures as necessary.   I see this analogous to portfolios, programs, and projects. Just like a portfolio can contain programs and projects, a policy contains processes and procedures. Just like a program has projects, the processes have detailed procedures.  Hope this hierarchical structure helps in understanding the differences. 

Leaders are Good Story Tellers

I attended a small personal party with a few friends and family. With children of mixed age groups, they were all discussing a range of movie superheroes. I saw some children narrate their versions of the story on why the hero succeeded or the villain failed! I saw another group of young children who had their own thoughts that they could never articulate or complete. Finally, although everyone had their own story to tell, the one that had the strongest appeal among the children was the one that delivered a compelling story. The End! 

Yes, Leaders are Good Story Tellers. Every iteration, release, or phase in a project and every major milestone or minor milestone in a project or program has a story! Every technical design, prototype, or experiment also has a story. The product owners and the project managers are the leaders that tell the story of the benefits delivered and value realized in each such timed event! The project manager's ability to build the story highlights the team's accomplishment in delivery as well as the impact on the customer. So, how can we tell a better compelling story? 

I had organized and attended many PMI Professional Development Days as the Vice President and Board Member of PMI Mass Bay, Marketing and Communication. Two different speakers that I had the opportunity to engage with were Dr. Barbara Trautlein and Mr. Joseph Raynus. Dr. Trautlein (2016) started the story telling approach from the powerful questions to ask focusing on why, what, and how. This approach is analogous to the Golden Circle Snek (2009). She continued to see have the responses to these questions would correlate with everyone in the team and how each member should work on supporting the team so that collectively all the members in the team worked towards the final story delivered!

Raynus approached the story emphasizing that it is not just the topic of the story as BLUF (bottom line up front) that interests the stakeholders but relating emotionally to the benefits in a way it connects with the customers! Every artifact we create should support that story and help people realize the efforts. If managers are not structured focusing on what the story is in a dashboard, EVM report, burndown or burnup charts, or governance meeting, then, they not only risk playing the role of a spokesperson for the team but also losing their own credibility in front of the leadership team. 

Both approached are correct and appropriate. But the best approach leveraging the same thoughts came from my son in his middle school working on an essay he needed to write. While asking what he learned in school, he said he learned about 'Hero's Journey' technique to write his essay. He showed his handouts from Elementary and Secondary education that mentioned that a story should have a setting, characters, central idea or statement of the problem, primary evidence, secondary or supporting evidence, explanation, and conclusion. I began connecting with the way some of the movie trailers were made. I didn't realize this technique to storytelling which is what the others are telling appealing to logic more than emotion!

"In a world where dinosaurs roamed the earth and monstrous kings slayed their subjects for personal glory, where food was reserved for the rich and everyone suffered, one man raised from nowhere going to places no man has visited and rescue the people."  

Now, can we tell such a story in the prototype we designed? can we tell a compelling narrative of our story at the end of a phase, release, iteration or sprint? Not just cost-performance index, schedule performance index, estimate to complete, burn rate or a velocity chart but the story from these metrics compiled? Can we associate the emotions connected with the work effort that went to build the story? As I reasoned with this Hero's journey technique, I came up with four E's that can be woven into our product management (development and marketing) and project management delivery frameworks. 

So, don't just use prototype or experiments in single/multiple cadences focusing on testing and acceptance but relate to how these experiments deepened the understanding (empathy) of users and the subsequent technical design, how more than one solution were piloted, evaluated, and presented (exploration), what level of details were gathered (evidence) to accept alternatives, and how these were reasoned in the end (explanation).

References

Elementary and Secondary Education (Handout) (n.d). (Treasures of Parenting Exercise)   

Raynus, J. (2016). How to present a business case in five slides (Handout). Distributed in PMI MassBay Professional Development day 2016. 

Snek, S. (2009). Golden Circle. https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action?language=en

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

Curiosity is having a beginner's mindset: It is being childlike but not childish

I was having some initial discussions in delivering corporate training on contract management within a large-scale industry building various types of hardware equipment used as sensors in mission critical environments. I was naturally curious in trying to understand more about the specific industry related terms and conditions within the contract management discipline. I dug deeper learning about the unique challenges the team faced so that I can not only just deliver training but also exceed the expectations. In describing this training preparation and delivery to a leadership class, I mentioned curiosity is like having a beginner's mindset. I reasoned that it is like being childlike but not childish. The leadership students asked to elaborate my thoughts and I have captured our discussions here. 

First, curiosity is the 'solution' mindset. It is not feeling the comfort of a current situation but question how it could be better! Every potential comfort that we currently relish was nothing more than an idea, that was ridiculed, experimented with failure many times, and sometimes even prohibited from trying. We all know how the right-to-free speech was dealt with death penalties as history elaborates. Edison's own quote when experimenting with the light bulb is not that he failed but he has succeeded in many ways of not making the light bulb work. That curiosity is the foundation for everything!

So, what do most of these people developing drugs, designing bridges, innovating processes, creating architectures, and authoring arts and music have in common? The beginner's mindset. They ask themselves the "Why?" or "Why Not?" repeatedly like a child. I always admire the questions from the children that ask why the sky is blue, how much paint did they use, how did it become black overnight? One needs to continue to feed these questions. In my mind, that beginner's mindset of being childlike is questioning everything without any judgment, bias, labeling, or stereotyping.  In the explanations that we seek in subsequent experimentation or appreciative inquiry or research, we look for patterns that bring us new information, question our assumptions, or lead to serendipitous "Aha" moments!

However, in such a quest, we should not let go of the ethical obligations of doing the right thing even when it is hard. We should not fail fast but fail forward continuously learning from every experiment so that we don't risk the same failure again! Yes, not trying any risk itself is a risk but not learning from our failure and taking corrective actions for future is a major hazard. So, one shouldn't be childish asking the same question repeatedly, losing focus with other distracting attractions, or avoiding something because of fear.

What do you think of my explanation? Would you add, refine, or remove something?  

Alternative Idea Generation: The 6-3-5 Technique

In the Northeastern University Design Thinking workshop that I attended, I heard of a technique used to generate a few alternative ideas from the team during the ideate stage. It is called 6-3-5 technique, and I was quite impressed with that technique myself. I have heard of brainstorming, brainwriting, nominal group techniques, and Delphi techniques. This 6-3-5 technique is an extension of brainwriting technique extending further the collaborative power of the team. 

How does it work? 

Preparation

1. Assemble a group of 6 people sitting in a circle
2. Have a paper with 3 rows and 6 people grid pre-printed. 
3. Each person has a paper now. 
4. Agree on one common problem to solve in table
5. Ensure that all people write the common problem exactly as agreed upon
6. A moderator (optional) may be required to ensure that people adhere to timeboxing and avoid discussions

Execution

1. A clock is started for 5 minutes
2. Each person writes the name on the column 1 (this row serves as a header)
3. Each person writes three unique ideas on rows 1, 2, and 3 (unique to mean there should not be any dependency on the three ideas). It is important that no discussions take place and that this entire round is carried out in silence (no influence or monopoly from anyone)
4. At the end of 5-minutes, they rotate their paper to the next person on the right. 
5. The clock is restarted for another 5 minutes
6. They now write their name on the next adjacent column
7. Each person now has a new set of 3 ideas that others are potentially thinking. They can now write another set of 3 ideas or expand on one or more of the other's ideas. 
8. These rounds are repeated 6 times until all the 6 sheets are complete.
9. Effectively, this brainwriting technique gives 6x6x3 = 108 ideas in 30 min. 

Evaluation

Then, the unique and extended ideas can be evaluated for desirability, feasibility, and viability. What I found unique about this method is simplicity. It also avoids unnecessary prework while bringing enough awareness to the forefront in coming up with sustainable, stable, safe, and secure ideas while still avoiding who controls idea generation.

Here is a template to demonstrate this graphically.

Recommendations

A few ideas that I would like to extend here are that people can feel the fear of having their name identified and not coming up with big, innovative, and audacious goals. So, I recommend the following changes:

1. People use a pseudonym instead of their name
2. Everyone has the same set of writing instruments (same color markers)
3. Instead of passing it to the right, people can also think of different ordering as seem fit
4. Use arrows or something to indicate if one is extending on someone's ideas so that we can see what ideas are related
5. Establish a working agreement that no idea will be crossed out or put down in any manner

  Have you heard of this technique before? What suggestions do you have for recommendations?

5 Elements of Empathy: Lessons from Design Thinking

Earlier this Fall, I attended the Faculty Workshop at Northeastern University. I participated in the Design Thinking workshop. The facilitator was discussing utilizing the design thinking concepts to frame the problems correctly to extract assumptions and identify solutions. In general, design thinking is composed of the stages, empathize, define, ideate, prototype, and test focusing primarily on why the problem is important, who we are designing the solution for, what are we planning to do, and how is the resulting new experience for the person. As part of the small activities among the participants in the table during the session, we discussed ideas on understanding the user rushing to who are we designing the solution for.

During this session, I started writing some thoughts based on the ideas I gathered from the facilitators and the table activities focusing on what empathize meant. I believe I accidentally landed on five vowel elements of "Empathize" meant. I am sharing my thoughts here.

The first step is acknowledging (A) the user's problem. Nothing better comes unless one acknowledges that something is not working as intended or something is missed in the way the solution was developed. One way for us to demonstrate is scheduling a walk-through session or a hearing session with them and opening our meeting acknowledging the problem. 

The second step is engaging (E) directly with the users. Instead of assuming what we thought the problem was, it is better to interview them and ask powerful questions. Some questions that I can think of are the following:

• How do you really want it to be?
• What is the impact of what you are unable to accomplish now?
• What is important about that approach?
• What is already working that you can build on?
• What would a simple solution look like?

The third step is to immerse (I) oneself in the user's experience. Instead of just listening to them, we can ask them to interact with the product and partake in that experience ourselves. This experience is an expression to them that they matter. In lean thinking, we talk about the 3G principles (Gemba - visiting the actual place, Gembutsu - experiencing the actual product, Genjitsu - Gathering the real facts) and this immerse experience is application of the 3G principles. Some questions that I can think of are extending the questions from the engaging step as follows:

• What else could we do?
• What do you think we should stop doing?
• What is stopping you from doing them now?
• What do you think is possible?
• What does success look like for you?

The fourth step is to observe (O) for things not said or articulated. I feel like this is looking for non-verbal communication. These are the spaces between the words and sentences in non-verbal communication. I often call this approach "Listening with Eyes" (Rajagopalan, 2017), where we fill the gap between what they want versus what they need! It truly helps in not only reframing the problem for the persona but also architect the solution with the DfX principles (Paul, Beitz, Feldhusen, Grote, 2007) prioritizing based on the multidimensional risks associated with 'what matters the most.' As a result, X in DfX can stand for manufacturability, production capacity, testability, cost, reliability, etc. These optimization concepts resonate with Taguchi's system, parameters, and tolerance considerations for design (Gopalakrishnan, Jaraiedi, Iskander, and Ahmad, 2007).

The final step is unifying (U) all these first-hand experiences from user interviews, personal experiences interacting with the product in the environment the user interfaces with, synthesizing both the articulated wants and unarticulated observations and framing the problem. This reframed problem statement lays the foundation for the definition stage focusing not only on who we are designing what but also draws the factual insights and feelings to help with risk driven design and development.

What are your thoughts on my approach? Share your observations!  

References

Gopalakrishnan, B., Jaraiedi, M, Iskander, W.H, and Ahmad, A. (2007). Tolerance synthesis based on Taguchi philosophy. International Journal of Industrial and Systems Engineering, 2(3), 311-326.

Paul, G., Beitz, W. Feldhusen, J., Grote, K.H. (2007). Engineering Design: A Systematic Approach. Germany: Springer.

Rajagopalan, S. (2017). Listening with Eyes. https://agilesriram.blogspot.com/2017/04/listening-with-eyes.html

What color is our communication?

Sometime in summer of this year, I was finishing up a project management training session and was wrapping up the importance of project status report as a catalyst for engaging stakeholders as needed. One of my learners talked about using the red, yellow, and green status indicators in project status reports for various project elements like schedule, cost, scope, risk, and quality. Such practices are very standard in project management. Yet, how much do we think about the color of our own communication? 

Until a person that I was mentoring approached me while preparing for the career promotions, I didn’t think about discussing it. After discussions with this learner, a thought came to my mind. As leaders of change through our projects, one of which is owing our personal growth and professional career, how much do we identify color in our own communication to bring awareness of potential inherent bias, labeling, and stereotyping or promote diversity, equity, and inclusivity practices to promote belonginess? This blog is a brief synthesis of my research. 

Historically, literature is full of using color to communicate differentiating the good from the bad, truth from lie, grace from greed, etc. I saw in movies where people used white cloth to indicate piece agreements during negotiation, an inflammation on the head with a red color, villainous characters are wearing dark red or black costume while heroes wear blue and red capes or dresses. If this is not sufficient, take a look at some of the concepts behind deBono's (1999) dysfunctional hats where white hat is associated with facts, black hat is associated with devil's advocate thinking, green hat focuses on creative possibilities, red hat focuses on emotions and feelings, yellow hat focuses on optimistic outcomes and blue hat focuses on systemic managerial thinking.

Therefore, the concepts of communication have been present and widely used. For example, yellow journalism seems to be referring to those writing practices where newspapers published sensational news as though they were facts (Campbell, 2001).  I wonder if the book, "What color is your parachute?" had a reason for choosing color as the differentiator for skills required in networking and gainful employment guidance? Consequently, here are some thoughts to understand how our communication may be perceived by others, because as I always say, "Communication is not about what you said but what others understood." Now, I am not advocating them to be correct or not but only stating them. Just to add a little color, let me illustrate these thoughts with characters from Ninjago!

Black color has been used to indicate bad or evil things. For instance, Lord Garmadon in Ninjago is characterized with Black costume! Even in the computing world, we say "we blacklist the IP addresses" to say certain address schemes exercise adverse reactions. As the concepts of diversity, equity, and inclusivity comes into play, how much does it feel someone of an African American origin to read such a thought? Alternatively, if you used bold black color for emphasis, are you drawing inference in a bad way? 

White color is used to indicate good, peace, and intelligence. Zane, one of the four Ninjas with peace and robotic intelligence, is in white! While practice may suggest that we frequently use white background in most user interfaces and black foreground (like font), white shouldn't be used too often to indicate the absence bad or evil things epitomized in the black color. Therefore, associating white as virtuous and referring to "whitelisting keywords" is against the inclusive mindset. 

Brown color is often a neutral color with areas like dependability, predictability, and comfort with themselves. Sometimes, it is also used to indicate dullness or depressed behaviors. You can see Master Wu wearing brown robe around his waist often with white dress. But, the Dareth, the Brown Ninja, also is in brown indicating a dullness and depression requiring the other Ninjas to save his Dojo! Personally, while I was in Scotland, I was often called in the streets as a "brownie" and I never associated myself with eating the baked good, "brownie". I can't say I am the only one who experienced such issues. So, when bringing brownies or using brown color to indicate time logged by someone in a report with brown bar, are you indicating anything more than that meets the eye?   

The blue color represents both the positive and negative aspects of human emotions and powers. Therefore, blue can be associated with heroic powers, such as Jay in blue costume, or something that may have bad intentions but feel isolated without leadership like the snake, Skales. So, when we use expressions such as, "... bringing blue-collar (manual worker) thinking", "... surprised me out of the blue," or "... required me to explain until I was blue in the face," what are you telling about yourself to others? If other team members are in the same room, how would they feel about your thoughts of them in their absence?" Even the "Blue Ocean" leadership is a reference frame to say how one operates from a tranquil and calm perspective in a strategic decision-making scenario!

The red color indicates an elevated form of human emotions and powers. It is a stronger form of blue. Kai in Ninjago supports the others with both patient pauses required before unleashing powers. Often, red in management context draws attention to the extreme impact in a bad way (one of the reasons why risk is always thought of as a bad word). Variations of red like amber is also frequently used to indicate the same message. So, when we underline something with a red color, or single out a word or resource name in red color, what hidden message are we communicating? Think about red ocean leadership that focuses on strategies with multiple competitors. Is that by itself bad? No, only our interpretation is!

The green color signifies success, rejuvenation, and growth! It also indicates sometimes impatience and reasoning. Can you not see why Green Ninja is the greatest Ninja and why Lloyd wears green? Yes, no wonder we use green to indicate successful sales, successful milestone, successful bid, and renewal of a contract in management meetings. But watch out! I am feeling so green indicates envy and jealousy whereas giving a green light means you are indicating approval!

The orange color is a variation of red. Perhaps reduced intensity but not with any tint of blue positivity. Perhaps, this is the reason why the orange snake in Ninjago was characterized that way. All the energy and enthusiasm relishing small victories but not always working on the correct side all the time. Now, the color itself is not good or bad if the message supports the concept! But please note that if you put orange along the indications of red charts, you are communicating a bad message on a smaller scale!

The yellow color is a neutral color as well but indicates some degree of caution. No wonder, caution is often yellow on streetlights (for the most countries) and is used as 'proceed with caution' messages on project status reports. I am not yet aware of any Ninjago characters in yellow (not caught up on all). While this color may be used for caution in graphical illustrations in status reports and dashboards, in some context, yellow may also indicate limited approval (like a yellow light), uncourageous (yellow-bellied), etc. 

The literature is full of many other colors link pink and purple, and yellow. Frequently, I find these colors not clearly defined. Although in the United States, telling someone that they got the pink slip means they were involuntarily eliminated from the workforce. 

So, thinking from all these aspects, do we even think about the role color plays in our communication? 

References

Campbell, W. J. (2001). Yellow journalism: Puncturing the myths, defining the legacies. Westport, CT: Praeger.

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

Self-Promotion: How to blow your horn correctly?

I was following up with a few people that I had attended my 2-day corporate training workshop on Agile Project Management with Scrum. A discussion came up regarding writing personal self-reflection for annual performance and how that is aligned with Scrum. I view Scrum as an opportunity for the team to ask powerful questions. So, I felt like the team resonated reasonably in asking whether the performance review process fitted within a Scrum process.

However, Scrum is also a collection of cross-functional teams with a working agreement experimenting with value creation and delivery. Such a focused value creation also means there are other organizational commitments like capacity planning, transition planning, and succession planning based on sensing the external and market conditions, legal and regulatory compliance, etc. Within the Human Resources and Employment considerations, several confidentiality requirements exist that are not part of the transparency consideration of Scrum. So, performance assessment for individuals' career growth based on the personal development plan is required and doesn't fit within the Scrum (or Agile, Project Management) considerations. 

The discussion followed further into guidelines on self-promotion in the performance review. Now, based on my experience managing the PMO, I gave some suggestions as follows. 

Any self-promotion should be objective and not be blowing the horn so much that it emphasizes no opportunity for continuous improvement. In fact, the more modest one is in stating the facts, the better the others will blow your horn! I feel that self-promotion should focus on perspective thoughts, purposeful actions, projection of behaviors that can be emulated, and the poise one takes on maintaining emotional connections. 

1. For instance, the thoughts should not only focus on short term deliverable orientation but also long-term scalability. So, talking about how the definition of done was adhered to alone is not sufficient. Instead, the types of documentation created, training promoted, operational excellence addressed, risks treated, and technical debt minimized are all examples of bringing industry practices. Everyone can start thinking in terms of the functions adjacent to their roles and responsibilities and see how they are better off because of their work. 
2. Now, this perspective can also focus on motives that connect with the larger organizational goals. For instance, connecting with upstream value stream activities and evaluate how multiple departments outside of our core work could be benefitting or what organizational processes can be better modified and incorporated are creative and systemic activities. Inviting other business unit leaders to talk about their daily challenges and what we can do to address these challenges builds bridges. 
3. Combined with perspectives and purpose is the behaviors that we would like others to follow. Here is where 'influence' comes in as we model leadership behaviors (Northouse, 2007). Engaging in powerful questions, becoming a mentor, advisor, or coach, and taking on stretch goals beyond what our job responsibilities call for making us allies for other business and trustworthy comrades for others. As you can see, we are projecting our leadership image. 
4. Losing connection to the people's emotion is a downward spiraling path even if we do all the above correctly. Here is where we go back to applying the emotional intelligence, multiple intelligence, and cultural intelligence that differentiate us further. 

How can we practice frequently all the above perspectives, purpose, projection, and poise? The best way to address them is, as I always say, "Don't count the days but make the days count." Consistency is the key to continuously grooming oneself in all these areas so that when it comes to writing this annual reflection, it is a simple consolidation activity. My approaches to doing this consistency are as follows:

1. Use a calendar system effectively to manage yourself. It may be challenging with our multiple roles (worker, parent, student, social commitments) that one calendar can't avoid schedule conflicts. So, use a consolidated calendar to manage "all" your commitments. Let the system be your reminder!
2. In today’s world, there are several tools available. One can use your project management tools to manage your own career promotion as a project as a product tracking your 1:1 meeting, learning, work objectives, and stretch goals. I used SpiraTeam (Inflectra, n.d.) that I had access to in my company to manage my individual self-agility (Rajagopalan, 2012) and my PMO performance objectives based on balance score card using the system to track my commitments.
3. I start every day with "What is a successful today?" Be relentlessly positive and committed to delivering on each day! I am sure a thing or two will slip but recognize it so that you can become better if that is in your control. 
4. Focus on one or two important things. a) Avoid multitasking please, and create routines that work for you. b) Create value, eliminate non-value activities, reduce stress, raise your awareness. These ideas emerge from Blue Ocean Leadership (Kim & Mauborgne, 2017) where you can think of each day as a fresh start to make a difference.
5. Remember to be modest every day! This ensures that others write your performance review each day, week, month to tell the story for your annual performance. If you are not tracking your performance more frequently against the value drivers such as measuring against your commitments or tracked in the balance score card tracking tools, then, your annual performance review should not be a monumental activity! 
6. Celebrate the wins frequently. In managing the teams, the leadership principles advocate "recognize more". The leadership practices approach even value "recognition" (Kouzes and Posner, 1987) through encouraging the heart more than "reward" (Herzberg, Mausner, Snydermann, 1959) as part of the motivation much needed. So, share the team's wins. Spread your love in the status meetings. Don't wait for the lessons learned to recognize others. Recognizing people for their contribution is a boomerang. It comes back to you with sincere appreciation.

References

Herzberg, F., Mausner, B., & Snydermann, B. (1959). The motivation to work. New York: Wiley

Inflectra (n.d.). SpiraTeam. Retrieved from https://www.inflectra.com/Products/SpiraTeam/

Kim, W.C. & Mauborgne, R.A. (2017). Blue Ocean Leadership. Boston, MA: Harvard Business School Publishing.

Kouses, J.M. & Posner, B.Z. (1987). The Leadership Challenge. San Francisco, CA: Josey-Boss.

Northouse, G. (2007). Leadership theory and practice. 3rd Edition. Thousand Oak, Londan: Sage Publications.

Rajagopalan, S. (2012). Leading Change: Remote Teams can collocate on the right ALM tools. Retrieved from https://agilesriram.blogspot.com/2012/04/leading-change-remote-teams-can.html