Distinguishing Operations from Program Related Activities

As part of supporting some PMP candidates who had the titles of program manager in their organization, there were some confusions 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 is a core element of a program and benefit transition involve 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 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 differ across programs, companies, and industries but the following is a good start.

1. Initiation and Prioritization of projects 

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.

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 value be 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 also 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 resources (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 can not be missed. 

Thoughts? Please share. 

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 a number of 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 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 myself difficult to motivate the neighbor. I wanted to appreciate my neighbor not to get frustrated at failure as failure is not final but was also finding difficulty in 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 compliment the contributions at a significant event in 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 also 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 Thyagaraja 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 subgoal 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 change 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 hat was applied in simulated anti-lock breaking (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 have to think through the unknowns and put process controls in place proactively to avoid any potential use of the product in an unintended way. Similar to 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 the digital ethics principle (Nebeker, Torous, Bartlett Ellis, 2019) of nonmaleficence. 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 decision 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 differ 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 definitely enhances the ability to accelerate decision-making, making AI based solutions need to 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, Sep). 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 have to 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 have to 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 concept. 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 with 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 where you go or not. So when one changes direction as any project may experience, stakeholders and team members need adequate advance warning.  This 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 our external signals (red light, no free turn). Have we communicated our intent adequately in advance (activating 3-5 seconds before turning and stopping it after turning)? 

Even if we have signaled, have we watched the 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 the shoulders rather than just rely on the mirrors or the blindspot signals in today’s cars. So, even when governance has approved, we communicate out 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. Same logic applies in project deployments with contingency and fall back 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 the 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 a 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 receive from them, 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 are 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. 
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, 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 on things 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 similar to 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

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 requirements 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 the data, memory, etc. 

For every type of asset identified, there may be additional processes. For instance, when someone has to 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 code development guidelines. So, each policy may be governed by one or more processes giving a one-to-many 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 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.   

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 about 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 managers 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? 

Interestingly enough, 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 evidences, explanation, and conclusion. I began connecting with the way some of the movie trailers were made. I didn't realize this technique to story telling 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 cadence 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 a 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 a 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 of all, curiosity is the 'solution' mindset. It is not feeling the comfort of a current situation but question how could it be better! Every potential comfort that we currently relish were 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 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 just 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 take 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 number of 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 a 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 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 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 come 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?