Posts Tagged With: Process compliance stupidity

Control partners should have skin in the game!

I finally completed reading Nassim Taleb‘s book Skin in the Game which I had written about in a recent article.

In that piece I had applied his principles when comparing the benefits of a product-centric orientation to the project-centric model which is still found in many organizations. But after finishing the book, I realized that there is a much more compelling example of the challenges experienced with risk asymmetry in many large organizations, namely with those staff who are responsible for developing the policies, standards and methods used by teams for delivering projects or products.

In small companies, how a product gets developed and delivered is usually defined by a “Big Brain” (e.g. a solution owner or similar role) or developed collaboratively by those actually building the solution. But as the size of the organization increases and stakes get higher, control partners emerge to influence not only what but how production occurs.

Where things get difficult is when these control partners do not experience first-hand the downside of their decisions.

For example, in some companies, project management standards are set by a centralized department such as a PMO. While some delivery roles such as program or project managers might report in to the same PMO, there are staff whose sole focus will be to define and maintain standards. As those staff are not in a project delivery role, even if they possess years of practical experience, as they won’t themselves have to use the templates and tools which they have developed, they don’t have true skin in the game. Delivery staff may complain to control partners about how onerous or non-value add specific practices are, but there is little direct impact to them.

There are a couple of ways to rectify this situation:

  • Serving in such control functions could be a rotational responsibility. After someone has spent a reasonable amount of time in a control role, they should be required to spend an equal amount of time in a delivery role. This will also help them better identify patterns and anti-patterns specific to a given context.
  • Introduce performance measures and incentives for control staff which are tied to the impacts created by their work as opposed to just the completion of this work. For example, quantifying the cost of control or conducting regular satisfaction surveys with delivery staff are two methods in which we could bring back skin in the game.

Method makers and framework formulators – practice what you preach!

 

 

 

Advertisements
Categories: Facilitating Organization Change, Process Peeves, Project Management | Tags: , , | Leave a comment

How effective are your agile ceremonies?

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.

 

 

 

Categories: Agile | Tags: , , | Leave a comment

Project lessons from playing pool

A few months ago, I rekindled my enjoyment of the game of pool after having played it sporadically over the past twenty years.

I find something soothing about the clickety-clack sound of balls ricocheting off one another and relish the challenge of figuring out which shot to play to sink a ball and line up my next shot or if I miss, at least prevent others from making their shots.

Racking my brain (pun intended) for a topic to write about this week I thought why not explore whether there are any lessons we can learn from playing pool which might be applicable to project work?

  1. Standard pool is played with fifteen colored balls (not counting the cue ball). Diversity within teams is a source of strength. Yes, it might make the storming and norming phases of team development more challenging, but higher performance, creativity and resilience can be the rewards for persistence.
  2. No two pool tables play exactly the same. Until we understand the unique attributes of a given table, making assumptions based on previous games played on different tables is likely to get us into trouble. With our projects, while historical data can be relevant, we need to understand the specific context of a project to avoid using the wrong tool or technique.
  3. Define the rules of play with your opponents. There are some generally accepted rules for playing pool, but certain practices might vary by who you play with. There are generally applicable principles for project delivery but work with your teams to develop working agreements and ways of delivery which are best suited to them and the needs of the project.
  4. Balance risk with reward. Yes, that tricky bank shot would look impressive to bystanders if you can make it, but if you miss, you might set your opponent up to run the table. But playing it too safe usually won’t work out well either, especially if your opponent has a greater ability than yours! When working on projects, we need to find the right balance between playing it too safe and living on the edge. The former might result in mediocre business outcomes but the latter could result in project failure. This is why having good judgment is critical for project team members.
  5. It takes self-control to do well. It can be really tempting to apply full force on a shot, but you could end up scratching or sinking one of your opponent’s balls. Being mindful about the amount of force required to make a given shot and leaving your ball well positioned for the next shot is important. Delivering challenging projects takes discipline and sloppy execution will hurt us in the short or long term.

Finally, “Take care of your cue ball, and it will take care of you“. Support and lead your team and they will help your project succeed.

 

 

 

Categories: Project Management | Tags: , , , | 1 Comment

Blog at WordPress.com.

%d bloggers like this: