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.  

Agile needs to understand and focus on agility more

Over the last few weeks, I overhead a few practices such as the following while claiming to practice agile.

a)       Not finding the tasks in the sprint backlog for sizing the user story

b)      Evaluating the definition of done during almost every sprint

c)       Focus on the sprints and lose the value not delivering on committed time

d)      Not factoring capacity into account in a velocity driven planning

The major focus of agile is on maximizing value to the customer. This is stated as, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” To accomplish that goal, it is imperative to ensure that we exhibit agility rather than claim to practice the so-called Agile paradigm. When the focus is on this value maximization to the customer, how could the above practices that fail to add value to the customer be considered agile practice?

Maximization of value means within the agreed timebox, the team self-organizes to add the appropriate tasks. The scrum master acting on the team’s behalf needs to hold the definition of done articulated ambiguously by the product owner. Similarly, the product owner needs to be held accountable to the larger committed timeline to the customer not losing focus on the slips in the timeline due to losing velocity in every sprint.  The scrum master needs to hold the product owner responsible for capacity planning in a velocity driven team rather than a commitment driven team.

If the principles recommended above are not upheld, then claiming to be agile is an understatement. This is because the maximization of value delivery with a focus on customer is falling apart. Some of the root causes are the following:

a)       Thinking that a team is agile just because of the use of a specific tool or adoption of a specific recommended ceremony.

b)      Merging the crucial roles of scrum master and product owner in one person who keeps neither role in check.

c)       Addition of new team members not sharing the same norms disrupting operating rhythm.

d)      Allowing the flexibility to let the team not meet the required commitment because it can always be picked up in the next sprint.

Going to the basics, if the focus is on value delivery to the customer, then, it is important to not lose the focus of time, scope, quality, and cost and the risk of non-delivery on these elements. Increasingly, as agile gains mainstream focus, it is indispensable for the agile team to understand these considerations and not just adhere to agile terminologies. Only when one understands these principles can one appreciate when to stay agile, when to adapt practices, and when to recommend going with traditional approaches.