Easy in theory, difficult in practice

I'm midway through Nassim Taleb's latest book, Skin in the Game: Hidden Asymmetries in Daily Life. As is usual with Taleb's writing, he provides thorough but humorous coverage of a concept which can be applied to many contexts. The premise of this book is that without skin in the game, asymmetries emerge which encourage unfairness, poor decision making and can contribute to a lack of understanding of realities.

One of the key principles discussed in the book is that there should be a negative incentive or cost to decision makers when things go wrong. Without this, we have an asymmetry since risks get transferred away from those who should have been held responsible. A common example of this is seen in companies where sales teams are compensated for initial sales but are not held accountable to some degree for customer satisfaction beyond the point of purchase. This can encourage salespeople to over-promise with inevitable expectation shortfalls. Another highly publicized example is that of the financial company executives who were never jailed for poor decision making which led to the 2008 financial crisis.

This principle can also be applied to some project teams.

There are industries such as large scale construction where the cost of poor quality in extreme cases (e.g. a bridge collapse) will result in punitive consequences to the engineers who were involved. However, in other domains such as software development for internal use where deadlines may be emphasized higher than product quality, there is no such downside. The teams who delivered the buggy release will have likely disbanded and the team members will have moved on to different departments or projects before the real cost of ownership is understood by the business owners.

On the other hand, when there is a product-centric model delivered by long-lived teams, there's greater skin in the game. Escaped defects are no longer the responsibility of an operational group or some future project team. Quality issues will come home to roost in the delivery team's backlog and the Product Owner has an incentive to focus on improved quality if he or she doesn't want to have ongoing uncomfortable stakeholder interactions.

Taleb also states that skin in the game supports the principle of survival of the fittest. Product Owners or teams which consistently miss the mark with their releases are unlikely to be around for long in product-centric contexts whereas in project-centric organizations, it may be easier for individual mediocrity to fester if there isn't ongoing vigilance.

"Skin in the game prevents systems from rotting" - Nassim Taleb

Holding a kickoff meeting as the first “real” event on a project should be a fait accompli, but you’d be surprised as to how many projects launch without one.  This mistake is growing in frequency as the proportion of projects with virtual and/or global stakeholders & team members increases.

The causes for skipping kickoff meetings could include:

• The project has been “on hold” or pending resource availability for so long, that there is no patience to do a true kickoff as everyone just wants to “do it”.
• Everyone is so busy that it is impossible to schedule everyone’s time (especially across international time zones) to hold it.
• So much effort has gone into the pre-project justification or sales work of developing a business case or negotiating the Statement of Work or contract that the kickoff is perceived as an academic activity.

To counter these excuses (because that is really what they all are!), here are some legitimate benefits of holding a proper kickoff meeting (preferably in-person):

1. First and foremost, it’s the best opportunity for the project sponsor to present the vision and purpose for the project to the overall team (many of whom might not have been assigned during the pre-project phase) and to sell them on the benefits the project will bring to the organization and themselves.
2. It’s a chance for the project manager to review project rules of engagement with all stakeholders and team members, and to be able to get the project sponsor to back him/her up visibly!
3. It’s an opportunity to have a very quick, informal “fear, uncertainty & doubt” – the formal risk identification session will likely come later, but this meeting does give the PM the chance to start to understand the risk biases of project participants.
4. While not a formal planning session, it can be used to voice and discuss assumptions and constraints to ensure they are in fact, valid.
5. It presents the PM with the first real chance to see the body language and interpersonal behaviors of the team members and stakeholders.  If the PM has not worked with this group before, long running department or individual conflicts might start to become apparent.
6. It starts the team development process in (what should be) a non-threatening and neutral environment.

Skip your kickoff meeting, and your project could end up as flat on its back like Charlie Brown!

(Note: I originally punted this article downfield in February 2011 on kbondale.wordpress.com)

A project manager asked me this week whether I was aware of any studies which could be used to justify the assignment of a "real" project manager to manage a project as opposed to having this function performed by someone else within a team. While I'm sure PMI and other project management associations have researched this thoroughly, I felt this would be a good topic for an article.

In some companies, such justification is not needed on a project by project basis. Organization policies or standards might require that projects exceeding a given estimated total cost or those that are over a certain level of complexity must have a project manager assigned. However even in these companies if perceptions fester that the role isn't adding value, standards owners may be pressured to raise the thresholds at which project managers are required.

But in those companies where such standards do not exist, the battle might need to be fought at an individual project level. Convincing the funding authorities for these projects that a project manager is needed could be done in a couple of ways.

A fear-based approach might be used. This requires creating a sense of urgency by highlighting data from project failures or by communicating the personal risks to the stakeholder if something were to go wrong as a result of not having a project manager assigned. A decision tree could be used to compare the expected cost outcomes of both sides of the decision. While this might seem to be a reasonable approach, unless you are dealing with a particularly risk averse stakeholder, optimism bias is likely to cause the sponsor to ignore your arguments.

A different approach might focus on promoting the upsides of using a project manager. While this approach will be much harder to justify using financial projections, it doesn't put the sponsor in the uncomfortable position of having to imagine their pet project failing and the emphasis is on showing the incremental benefits which they might achieve by having a project manager. Increased outcome predictability, improved communications, better focus by other team members on delivery, higher levels of stakeholder and team member engagement are just some examples of the advantages which could be communicated.

Regardless of a company's level of organizational project management maturity, ensuring that the costs incurred by a project manager are providing some value in return is important otherwise it shouldn't be a surprise if sponsors push back on the need to assign one.

Some of our greatest achievements are realized through the willingness of people to strive for what seems to be impossible. Without this will, we likely would not have reached the moon or split the atom.  But constraints are one of the most important elements of a project. They are the gatekeepers on what is and is not possible.

So what happens when decision makers insist on trying to deliver fixed scope with unrealistically low timelines and resources?  A common outcome is that something gives. Scope is only partially delivered, quality suffers or schedule and cost baselines are exceeded.  What’s interesting is that when such project overruns are analyzed, many times we see that the final actuals are in fact fairly close to what the initial estimates were.

Is this a self-fulfilling prophecy on the part of team members? 

Sometimes it can be!

If the team is not convinced that their objective is achievable, there’s a good chance that they will fail.

But in many instances, it is caused by the analogy I’ve used in this article’s title – like a spring, a project can be compressed.  But after a certain point, sufficient linear restoring force has built up that the spring will return (usually violently!) to its original size.

But let’s not ignore the reality that a project needs constraints.  Without these, it consumes resources indefinitely without delivering proportional value.  Like a spring, you can stretch a project to a defined extent, but once elastic potential energy has exceeded the spring’s design, it will either snap or be permanently deformed.

As project managers, one of our responsibilities is to facilitate appropriate decision making.  If your attempts to convey the impossibility of a requested project scenario are falling on deaf ears, leverage the power of analogy, and illustrate your concerns by using a toy spring.

(Note: I stretched this metaphoric spring in January 2012 on kbondale.wordpress.com)

We hope that by conducting effective ceremonies we will achieve the agile trinity of improved value delivery, better quality and more fun.

But these objectives might be reached via multiple paths so we might not be able to prove causality between our ceremonies and those objectives.

We could ask our team members to tell us whether they see the value in the ceremonies and their perceptions are certainly important but is that enough? Can we identify measures which we could directly attribute to specific ceremonies so that we know if they are generating sufficient value?

Each agile framework provides its own ceremonies but given that Scrum is still the most commonly referenced one, let's focus on that framework's events.

The Scrum Guide calls sprints the heart of Scrum as these time boxes set the cadence for all other events. But to know if the Scrum heart is healthy we could track achievement of goals and value delivered sprint-over-sprint.

Sprint planning should answer the "what" and "how" of delivery for an upcoming sprint. Measuring its duration, quantifying the variation between what was expected to be delivered and what was actually delivered, and confirming whether the team is working at a sustainable pace might help assess the ceremony's effectiveness.

The daily scrum helps the team align themselves towards the accomplishment of sprint goals and to collaborate better. It should also reduce bad surprises and the need for traditional status meetings. To see if it is adding value, we could check how many work items are completed and measure how many unanticipated impediments are encountered each day.

The sprint review provides an opportunity to inspect what was accomplished and adapt the backlog accordingly. We can measure how many new requirements and course corrections emerged from the discussions. We could also conduct regular surveys with key participating stakeholders to gauge their satisfaction with the product and with the team.

Finally we come to the sprint retrospective. To gauge whether this ceremony is more than just a frequent "lessons learned" session, we could track the ratio of improvement ideas generated compared with how many were actually executed and provided expected benefits.

Agile ceremonies should add value. If not, we are just adopting the form of agility with none of its substance.