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

The Four D's of Conflict Management

I was engaged in a corporate training pre-discussions for an organization. They were involved in producing small to large scale physical marketing materials like producing custom designed glass shaped in a particular design with text and graphics imprinted on them. In my discussions, I found that one of the major challenges in their organization was timely resolution of conflicts. Since raw materials were acquired and inefficient design or experiments wasted the materials, there were a lot of challenges where ideas were quickly dismissed, or resistance followed. As I structured my training within this organization, I thought about the standard approaches to conflict management approaches. Expanding on these training courses as well as several conflict situations I had personally handled, I approached this training with a 4-D approach to how conflicts progress. 

 

1. Difference

When teams are in the norming stage, they have adjusted their behaviors and have committed themselves to the project objectives. If at this stage, team members have a difference of opinion or an approach to ways of working, that is nothing more than "Difference." This difference is the first D. I view this stage as a precursor to Speed B. Leas’ model (Leas, 1997).

It is essential to understand the reason behind this difference as it is not at all unhealthy. On the contrary, it is very healthy to have "Devil's advocate" thinking and ask questions. Frequently, these conversations could be informal discussions that could often be easily resolved. Such a resolution involves listening to people and explaining the logical reasoning connected with business objectives. The project manager may not be always the decision-maker but a facilitator.

2. Debate

When such differences are quickly dismissed for any reason, team members with strong opinions will frequently engage in a debate. Now, this debate is the second D and is also not unhealthy as it formally brings discussions forward. This stage is analogous to the first level of problem to solve stage. A healthy debate brings alternative views and is only healthy if the arguments are constructive and aimed at maximizing value while minimizing risks.

In project management, we have several techniques like brainstorming, brainwriting, Delphi Techniques, Nominal Group Techniques, and the deBono's dysfunctional hats approach. For instance, when one engages in Joint Application Design (JAD) or Joint Application Requirements (JAR) sessions, all these approaches are effectively used. Due to the formal nature of debate, the project manager may be involved in expert facilitation and mediating solutions frequently in the form of preventive actions. One approach to prioritizing is approaching from the risk management perspective, such as asking what the impact of non-delivery or non-compliance to the business and customer will be.

3. Disagreement

When differences and debates are not addressed, then disagreement emerges. People at this point have subscribed to the notion of "Prove me I am wrong." This is an unhealthy stage as time has elapsed in the management's timely intervention of resolution. This disagreement is the third D and is all about damage control. This stage is equivalent to the second level in Leas’ conflict levels.

Depending upon the time lost or the conviction people have with the disagreement, the level of resistance may also be strong. Often, this is an indication of the project manager losing their grip on the situation requiring escalation to management. It may involve as simple as sponsor involvement, or engagement of Human Resources Personnel, or a more formal governance control documenting the impact and taking both corrective actions and preventive actions (CAPA). Honestly, since prevention is better than cure, we should have called this PACA as having proper norms and plans prevents such unnecessary escalation.

4. Dispute

When this disagreement is spread across the entire organization or impacting multiple business units, then, these differences have now become a dispute. This dispute is the fourth D and indicates an unhealthy stage. It is in this stage, multiple variations may exist depending on the size of the organization, nature of conflict, and the type of thin/thick cultural politics at play. According to Leas’ model, this stage can therefore be the third level (Contest), fourth level (Crusade), and fifth level (War).

Multiple business units, sometimes including legal teams and senior organizational teams, will be consulted at this stage. Emotions run high with the escalations. Most likely, even the original problem to solve is no longer the focus as people have become polarized with their opinions. The projects may be terminated, customers may be lost, and the company's image may be questioned. 

My 4D approach was well received in this corporate training as people were able to relate to the patterns that were emerging. As we brainstormed ideas on how people within the organization could recognize these stages and put checks-and-balances, the participants felt they walked away with a practical guide to conflict management. 

What do you think? Do you relate to them? Have any stories yourself to tell? 

References

Leas, S.B (1997). Discover your conflict management style. Lanham, MD: Rowman & Littlefield

Relationship Management as a Chief Experience Officer

I was fortunate enough to receive the PMI Eric Jenett Project Management Excellence Award in 2017 (PMI, 2017). One of the project management students that I was coaching approached me mentioning about having seen the video (Rajagopalan, 2017) and was curious about what the Chief Experience Officer meant in connection with the relationship management in project management. I am capturing briefly my responses to this person. 

When people think of managing relationships with project teams, customers, partners, and other stakeholders, l feel that they focus mainly on the soft skills. I don't feel soft skills is an appropriate term at all as it makes technical skills or analytical skills to be a hard skill. Technical solutions solve a business problem, and analytical skills unearth patterns in both technical and business arena. Such division of domain specific skills is against cross-functional skills. We all understand that technology is critical to business and business supports technology. If such symbiotic relationship is understood, then these skills should be called interpersonal skills. Once we recognize that, we focus our relationship on how we sail ("Solution Agents of Implementing Change") through enterprise environmental factors and organizations process assets. This is when we are becoming the "Chief Experience Officer (CEO).

So, what are the things a CEO (regardless of who you are in the organizational hierarchy) must think through when they suggest any change, implement any work, or experience something outside of the organization (like bringing new knowledge back to the team or organization, lowering total cost of ownership, experimenting a new way of working)? 

1. Understand why this change or task is important. Connect with the business strategy and customer impact. I am sure everyone can understand Stephen Covey's principle of "Start with the why".
2. Evaluate the impact of the pain points we solve (or not solve) for the organization or client. This area is where the concept of "risk management" is non-negotiable. Just like the message "If you see it, say it" in many public places promote everyone to be the 'eyes and ears' of managing order, everyone should be able to understand the main tenets of risk management. The more one can assess the impact, the more it helps with prioritization of efforts. 
3. Ask ourselves how we make clients feel valued. Customers and clients are as smart as we are. Instead of thinking that our clients can't articulate requirements or customers change scope, understand why they did that and pivot accordingly. Always know that "No is not Never" and "Yes is not Now". Be able to rationalize both emotionally and logically with clients. 
4. Every one of us should understand what our unique value proposition is. Just like the candidates are expected to differentiate themselves in the interview where one is different from the other candidates (like "Why should I hire you?"), we should always think of answering the unasked customer's question, "How are you different from the competition?" This question is not for sales but for everyone in the organization as value flows in all directions within the organization to the client. 
5. Frequently, many think they are not salespeople. Yes, sales require a unique set of skills (one of which is handling objections). Nevertheless, everyone contributing to value creation should think of how we market our brand. Now, this marketing is not just about product marketing but how we worked together in value creation. Looking from this angle, we can see that different persona exists in the clients and so adjusting the message according to the person is important. 
6. Trust is a like bank account. It pays interest when we continuously invest in it. It assesses penalty when we don't follow through. Clients trust us because of what we invest in the relationship account. Like reaching out to tell our clients what they can do differently to accelerate time to market or how the competition is performing. They look up to us because we bring 'market intelligence' to them. Recall that "we are the face of the product and process" to them! And that is gold! They appreciate us by coming to us in providing testimonials, acting as references, and supporting with up-and-cross-sales. 
7. It is also important to know that we may develop deeper roots within a client organization as we build on this "CEO mindset". While we may think we have superpowers to connect with different members of the client organization, it is important to understand our 'audience language'. Sometimes, we may be cross-functional with enough knowledge to talk with a technical member of the team as well as the management member of the team. That is great but challenges arise when we don't know what we don't know. So, understanding the audience language also means where we may need to augment our limitations with extended knowledge from other team members. So, relationship management also means we connect other members of the team with appropriate members of the client organization. This approach mitigates risks and builds the 'opportunity' surround sound system.
8. Finally comes the intense focus on the story we want to tell! In each of these above interactions, we should focus on this story of how we started, how we progressed, and where we have landed. Furthermore, where we are going! Feedback is one part of this story telling process but there should be tangibles (like whitepaper, presentation in symposiums, testimonials, case study) should all emerge along with intangibles (working relationships, cross-partnership opportunities, references, etc.) 

To me, this is what is the 2-step plan-do-study-act like cycle like how design-thinking works (double diamond) or the infinity loop is practiced in DevOps lifecycle. 

The student I talked to walked with enough satisfaction! What about you? What do you think of my response? Anything you want to add, refine, or remove?

References

PMI (2017). PMI Eric Jenett Award Person of the Year. https://www.pmi.org/about/awards/winners/past-year/2017

Rajagopalan, S. (2017). PMI Eric Jenett Award Recipient video. https://www.youtube.com/watch?v=kESHH2mVkdk

Influence of Linguistics on Project Leadership

There is a common saying that 80% of the project manager's job is communication. Frequently, many think that this communication is about working with a team and writing status reports. On the contrary, most of this communication is working with both project management stakeholders and project team members. I always say that people's non-verbal communication carries more meaning. With various remote ways of working, it is important how the verbal and non-verbal communication play together in the leading people as the concept of communication is centered on five critical elements - clarity, correctness, completeness, cohesiveness, and conciseness. 

Fortunately, I had my son who was studying linguistics in his college and sharing his thoughts on what he was learning. He mentioned to me that linguistics in a nutshell has five major elements which include phonology, morphology, syntax, semantics, and pragmatics. It was shocking to me how much language plays a pivotal role in leadership level communication and here are my connections on the influence of linguistics on project leadership. 

Phonology: This area focuses on the study of sounds implemented within a language. It differs from phonetics where abstract sounds that may or may not have any meaning associated. For instance, the letter "s" takes the sound of "z" while saying "cars". Particularly in verbal communication, this is very critical for people to understand each other as it lays the foundation for clarity. Especially when team members are from different culture or a technical communication channel is used with remote team members, clarity may be compromised, and it is important for one to actively listen to avoid the risk of assumptions of what one thought they heard. In project meetings, I often ask people to summarize what their actions items are before meeting again, and this helps me ensure that they heard me right.  

I normally say, "writing is for the eyes and speaking is for the ears." However, even with written reports, if project managers do not think through how the report will sound to others, then, they may risk misinterpretation. Therefore, taking the time to read out the reports aloud eliminates how the report may sound to someone. 

Morphology: This area focuses on the study of words within a sentence. The history of culture itself may influence how words are formed differentiating agglutinative, fusional, and polysynthetic structure. Now, just like morphology builds on phonology, I see correctness in project communication builds on clarity. When relying on bad news such as schedules delays, cost overruns, or resource challenges, the appropriate placement of words in the sentence may assuage fears. In other words, I feel that morphology addresses the "What's in it for me?" types of questions in both ,verbal and non-verbal communication.   

Syntax: This area focuses on the study of sentence formation with words and punctuation. Using an example of a syntax tree, the different parts of the sentence are constructed. I recalled how lexical analysis was integral in computer science in assemblers, interpreters, and finally compiler design in computer science. To me, this syntax builds on morphology for larger level decision-making. For instance, the connections of various elements in project charter, the strategic connections between project charter and the business case, and the connections between business requirements document and functional specifications document are all examples of syntax analysis required for "completeness" in communication through the multiple artifacts. 

Semantics: This area focuses on the study of meaning. Since meaning is interpreted by people, culture comes into play. This culture may not necessarily be limited to geographical cultures (e.g.: Hofstede Dimensions) but also role specific communication. For instance, the type of meaning people associated with words among various people. A business analyst sees "value" to be with customer whereas the same "value" relates to technical stability by a systems engineer. We can see how project delivery members mix up words such as "iteration" from Agile and "sprint" from Scrum. The semantics elements therefore play a critical role in push, pull, and interactive communications because of their use either for dissemination of information (broadcasting) or for alternative generation (brainstorming) for problem solving or decision-making, the concept of semantics brings "cohesiveness" in communication. So, semantics must be considered excessively by project managers to lead others.

Pragmatics: This area is the study of the social aspects of language semantics. All the essential above elements are codified in informal or formal language registers and take on additional focus especially with many areas such as the dialect, age groups, respect, etc. For instance, generational considerations may have to be incorporated in both verbal and non-verbal communication differentiated in informal and formal communication. When conflict resolutions come up, groupthink behaviors may have to be addressed in favor of smoothing and collaboration approaches. During all these interactions, pragmatics avoids unnecessary confusions by focusing on "conciseness."

Interesting to see how much the discipline of leadership is critical for project leadership! What do you see? 

Five critical roles for Career Management

Frequently, people ask about how to manage their career brand and what to do. I can't remember a single professional training that I have already trained in project management, agile, scrum, contract management, risk management, product development, and leadership where one or more members ask this question. Based on some of my experience managing ~50 people in my PMO with numerous products and programs that I have managed or supported through the portfolio function, I have come up with five critical roles. Ask yourself the quality of people you have in your individual career development plan. That will tell how serious you are about your career development.

1. Sponsor(s) – is usually a senior person within the organization who is your supporter.    Ensure that your sponsor is kept updated on your accomplishments and successes – tell your sponsor the GOOD, the GOOD and the GOOD.  Frequently, this person could be your manager or in a projectized organization both the functional and other stakeholders. Do you know who your sponsor is within this organization?

Almost always, people stop right here. Their manager is their world for career development. If one is serious about career development, then, more support is required.

2. Advisor(s) – play an important role in providing advice and guidance.  Note that an advisor can be a peer, a junior person or a senior leader within the organization.  It is normal to have many advisors as it depends on what type of advice you are seeking.  The Advisor role is separate from Mentor and Sponsor roles, however there may be times when your mentor or sponsor end up giving you valuable advice. Frequently, advisor focuses on the performance more than the potential.

I often even recommend that people should develop their personal RACI. In other words, if career development is your project (part of individual development plan), then, having the RACI is non-negotiable. Who are your advisors in your career plan today?

3. Mentor(s) – are a trusted person with whom you can share the GOOD, the BAD and the UGLY. A mentor shares experience (I have been there, done that) and knowledge (Let me show you what worked for me). A mentor focuses both on performance and potential offering guidance and advice, but the perspective is more to develop others compared to advisors within a company. Therefore, while it is perfectly fine to have mentors within an organization, it is also recommended to select mentors who are outside the organization where you work.

A good mentor will have the following attributes:

1. Willingness to share skills, knowledge, and expertise
2. Demonstrates a positive attitude and acts as a positive role model
3. Takes a personal interest in the mentoring relationship
4. Exhibits enthusiasm in the field
5. Values ongoing learning and growth in the field
6. Provides guidance and constructive feedback
7. Respected by colleagues and employees in all levels of the organization
8. Sets and meets ongoing personal and professional goals
9. Values the opinions and initiatives of others
10. Motivates others by setting a good example

Often, it is recommended to have 5-10 mentors both internal and external to the organization. Seek out mentors in fields where you want to grow and not limit yourself to where you are currently.

4. Power Brokers:  are typically very senior, well connected / networked people who can help you in many ways.  People in this category are extremely busy and so it is difficult to get airtime with them.  Power Brokers can provide you with great introductions and other new and powerful connections that can be instrumental in your professional development and success. 

These are not people who are in your social media network! These are people that know you for your career brand and can speak for you in your absence! They open opportunity doors. Do you have power brokers in your network?  

5. Coaches: are instrumental in unearthing things that one may not be thinking of to maximize both personal and professional potential. They help you see much beyond your current 'status-quo' limitations (so limited time spent on past) and support you in coming up with solutions for future.  Whether it is managing personal challenges, life challenges, health challenges, financial challenges, strategic growth challenges, business challenges, coaches are the sounding-board to make you wear multiple dysfunctional hats (hope you are thinking deBono's six hats now). Coaching engagements need to be specific with clear objectives and can come and go as needed so that the engagement is fruitful. Depending upon what areas one wants to focus on, it is not uncommon to have multiple coaches simultaneously. A typical recommendation is to have at least one coach for one main area of growth objective.

How many such people do you have in your network? If you are not having 1-2 sponsors, 3-5 advisors, 5-10 mentors (most of them should be outside your role/department/company), 15 to 20 power brokers (all of them outside your company), and at least one coach, then, you can see how you are managing your career. 

Start that list if you don't have them. Everyday counts!

References

Rajagopalan, S. (2019). What color is our communication? https://agilesriram.blogspot.com/2019/11/what-color-is-our-communication.html<

Risk Management in Agile

Extending observations from one of the classes I facilitated on digital project management, I was wondering how to address the impact of risk management in agile initiatives. Earlier this month, I had a family emergency and I traveled to India to meet a family member who was critically admitted to the hospital. As I discussed the medical condition of my family member with the physician, I remembered one of my earlier speeches where I had discussed the notion of ECG waveform as the warning trigger of risk in monitoring one's health daily.

I resonated with the ECG waveform and its principles to agile approaches to project management or product development. The ECG waveform represents the heart pumping a certain volume of blood every fraction of a second (varies from person to person due to many reasons). From a physiological standpoint, the P wave represents the atrial contraction pumping oxygenated blood into the ventricular chambers. The QRS wave represents the ventricular contraction denoting the rate of  blood distribution. Finally, the T wave represents the ventricular relaxation before the heart is ready for another cycle. It is, therefore, no wonder, that one can think of every PQRST cycle as an iteration. The amount of blood consistently bumped represents the velocity.

Now, if this analogy is true, then, we can relate to risk also in an agile iteration. When we contract work to other teams or depend on others to complete the work, the functionality of the other organs (e.g.: respiratory systems) to deliver oxygenated blood without any challenges arising from circulation is critical. It is not surprising, therefore, why project managers always relate to the risk domain when procurement domain is involved because non-delivery per contract or non-performance of contracted work leads to the risk of resource overloading.

When one doesn't take care of their personal health properly by following quality policies (such as dieting or exercise), challenges arise such as a heart attack. The same concepts apply when the team compromises on technical excellence in design or addressing quality by design principles in their workflow. The escaped defect therefore represents the heart attack or an emergency trip to the hospital.

When the team members in the team fail to work together, that leads to failure. For instance, the block within heart system causes to resistance to smooth flow. Similarly, resistance to agile practices and lack of the team's self-organization introduces the risk of failure.

When the team is not self-organized or demonstrating high levels of team maturity, the scope compromises in velocity demotivates the team. Although the heart is much more resilient, overwork or imbalance introduces anxiety and stress, and people react differently. Similarly, lack of product vision or constant changes to iteration backlog compromises the team's ability to deliver. Many business challenges can impede the team's ability to deliver as well and become a high-performing team.

Such challenges, when go unchecked, impact the team's ability to deliver over a longer timeframe. The emergency visits to hospital leads to a loss of trust for caretakers requiring external intervention in the form of medicines or medically recommended rest. Stakeholders can lose confidence in the team's ability to consistently deliver on the strategic product roadmap when costs increase more than the benefits realized. Customer satisfaction fatigue can be seen in the voice of customer feedback and lack of adequate referrals.

In summary, I can see how this simple ECG waveform that we can all relate to proves to be emphasizing how risk is pertinent to everyone's health in daily life. If every day is a project, then, every heartbeat is an iteration which has the seeds of risks. The warning triggers must be understood and appropriately managed even in an agile project.

Thoughts? Please share with me.