The Righteous Solutions Practice

Cui Bono and the Generality of Project Management Problems

If you think that Projects are as more about people and how they work together, as opposed to process or technology, then it opens up a whole range of possibilities and opportunities for you.

Instead of being limited to book,s blogs, mentors that come from the Project Management community, and who often adapt or tailor generalist subjects to the Project Management context, you can just go straight to the vast body of knowledge about people.

In some fundamental ways there's nothing really new about how people engage in "the pursuit of happyness" or politics or commerce in the lasts 2000 years or more.  Sure there are many technologies and other societal changes that impact us, but fundamentally we're still people, and still very tribal.

I'm not a classics scholar by any means, but just read a bit of Suetonius (or Robert Graves if you like a bit more of story - which is how I found the 12 Caesars) and you'll see little essential difference between the stories there and what we see in  business and political life today.

So this gives us access to a vast collection of material on how people work - independent of the fact that these people might operate in a Project context or high technology.

And if that's the case, consider this old principle in terms of how people operate in your projects, whether you are a PM, or someone else on the team.

This is the principle of "Cui Bono" or "who benefits".

the principle has been used for thousands of years as a way to interpret the rationale or motivation of some action or proposition.  It is still used today by police as a primary tool in crime investigation.  For those of you of my vintage, "Cui Bono" and the corollary principle of "Follow the Money" were the means by which Woodward and Bernstein cracked the Watergate scandal, to name just one historical example.

It is so powerful because it transcends any explanation, dissembling, obfuscation or BS that people put out to cover their real intentions: conscious or otherwise.

This simple question is a great lens with which to view any action or proposal from anyone in a Project Team to probe whether it's in alignment with the Project Team's objectives, or someone elses.

At the end of the day Project Teams are people, and general people-based principles will most often provide you with the solution to Project Team problems.

You also might want to look at my "No Asshole Rule" Project Team Charter

The “No Asshole Rule” Project Team Charter – Principle #3

The "No Asshole Rule" Project Team Charter

I am publishing a series of Principles under the title of 'the "No Asshole Rule" Project Team Charter', and this is the third of those to be published.

The Introduction, Context and Summary of all the Principles is in a master blog post: "the No Asshole Rule Project Team Charter"

The context to this series is a book called "The No Asshole Rule" by Robert Sutton, a Professor at Stanford University and the author of other books and papers.

(Look at the end of this post for the complete list of Principles, and links to the other published articles)

Context of Principle #3

This next principle addresses the "Where are we going?" question that is sadly all to frequently asked and answered superficially, and then all to often ignored.

In the 2^nd Principle we addressed the focus on producing something of value. In this 3^rd Principle we address how we are able to recognise this value as a Team when we see it.

We have to have the same vision across all of the team, in such a way that we are assured that the next team mate's vision is also our own.

Creating a shared and actionable vision across multiple people is not automatic or easy. It does not just arrive based on reading of the same content, or a workshop.

And once created, the shared vision is easy to lose: it has a short half-life if not maintained and reinforced.

As the project unfolds, each individual, and combinations of individuals in sub-groups across the team, will evolve their understanding of the project's contexts.

This evolving understanding is almost always along different tracks: it depends on so many factors, including the specific skills and experience of the team members and the events and shared experiences that they go through as part of the project.

A compelling and vibrant vision captures the attention and engages the team in a persistent and strong way, and provides clear handles for reinforcement and for detecting when there is drift.

Anyone who has seen or heard Martin Luther King's "I have a dream" speech knows exactly what his vision was, and what that society would have looked like once it was achieved.

Anyone who was working towards that end goal would have been in absolutely no doubt about their ability to recognise when one or more of their mates had perhaps started to drift onto a different track.

And the dream had another fundamental characteristic (which was proven in tragic circumstances): it was bigger than any one person and survived after MLK was gunned down.

So a project team that is going to function efficiently, harmoniously and effectively needs to have a Common Mental Model of Success (which I'll abbreviate to "CMMoS").

The term "Shared Vision" is more commonly used (and is more natural from a language perspective), but suffers from the generically used terms for mission statements and the like which tend to be too generic and not actionable at a team level.

The concept of a "mental model" is that it is quite detailed and evidenced in day to day artefacts such as diagrams, charts, tables, and lists.

Behaviour that creates, shares, validates and nurtures the Shared Vision is helpful. Behaviour to the contrary is the Asshole behaviour that we are seeking to avoid.

Principle #3: "I have a dream"

I understand that the team has been created and funded to achieve a defined goal or purpose;

And I understand from Principle #2 that this goal or purpose is defined alone as something that has value to my customer(s).

For us to achieve this goal, we must have a mutally compatible and shared idea of what that end goal looks like.

I will subscribe to the idea of a Project Team's "Common Mental Model of Success" or "Shared Vision of Success".

I commit to establishing, protecting and nurturing a shared vision that is an actionable and tangible Common Mental Model of Success in the minds my team-mates.

I understand that developing, validating and maintaining a Shared Vision is not a trivial exercise but that it is a critical enabler to the Team's effective and successful operation.

I will help my team-mates to establish and develop this Shared Vision and to validate that their understanding and mine are the same.

I will look for evidence each and every day that the Shared Vision is in use and that it drives all our activities on the project.

I will seek out and surface dissonance in this Shared Vision and work to resolve that dissonance as rapidly as possible.

I will use this dissonance as a way to improve and shape the Shared Vision as it grows from our shared and growing knowledge and experience.

If I do not create, promote and allow our Shared Vision to be the basis of our team's activities, or if I do not detect and resolve gaps or drift in our Shared Vision, then I am acting as a Project Asshole.

Application

All too frequently Shared Visions are either avoided or worse, defined as generic "mission statements" that sound inspiring but are not actionable.

You've all read Mission Statements that could apply to any context or project without much change.

In any process that mandates such a thing, it's all to easy to "game" the process by putting something together that seems useful, but is actually just a process placeholder.

If I come into a project that is already established, the first thing I look for is evidence of a Shared Vision and tangible artefacts that instantiate a Common Mental Model of success.

This includes such things as:

• whether the team is using the same language to describe what they are doing
• if I ask the individuals to describe the project and its goals, do they easily articulate this or are they grasping for words
• are there common documents (such as project diagrams, schemas) that are in evidence and use
• what project-related material is on the walls of the cubicles or common work areas of the team and its members

In the days when printed specifications were the norm, my greatest warm and fuzzy feeling of project well-being was to see the same document in use by all team-members, well-thumbed and dog-eared and marked up with post-it notes or notations.

In the current trend to Agile, the project "Vision Tree" is a good example, but if and only if the language resonates with the team members own words.

Familiarity with these documents is easily tested.

Whatever the visible or other artefacts, a team that is in alignment will be able to demonstrate that alignment readily and easily; without preparation and without artifice.

Anything less means that the team has not achieved that state.

Most frequently Project Teams see this Shared Vision development as a one-off thing: something to be rushed into at the beginning of the project and never touched again.

Somehow the team leadership needs to build Shared Vision activities into the daily/weekly/monthly cycles of the project.

If there is "vision fatigue" its best to stop and come back to it again: building it iteratively in small chunks is achievable if it's not seen as a "one-off" activity.

In agile for example, perhaps its worth reviewing in every sprint retrospective.

It's important to build some ceremony into this process: the shared vision will be a hard-won thing and should be celebrated: a little formal signing ceremony might be appropriate.

Behavioural Anti-Patterns

Good examples of behaviour that is not supporting a Shared Vision (and is therefore the behaviour of a Project Asshole) include:

• not attending vision workshops or whatever activities you facilitate to build the vision
• attending but not participating: it's ok to be quiet (there are many ways of contributing) but it's not ok to do your email
• being critical or cynical about the concept of having a shared vision, or about activities that center on its development or use
• objecting to refinement discussions as "nitpicking about words"
• insisting on articulating the project goals differently to other team members
• refusing or being uncomfortable with any signoff or investment ceremonies

And so on. Creating and maintaining a Shared Vision is hard, and just about any Asshole behaviour can undermine it.

The Charter – 9 Principles to Work By

Principle #1: "There's no 'I' in Team, but there is a 'me' in Awesome"

Principle #2: Delivering Fast and Furious Value

Principle #3: "I have a dream"

Principle #4: I am not a Job Title, a Deliverable or a Process

Principle #5: Cult of Accountability

Principle #6: Leaving Footprints

Principle #7: Respectful Disruption

Principle #8: Bureacracy is Shit

Principle #9: Practising Awesomization

The “No Asshole Rule” Project Team Charter – Principle #2

Background

I am publishing a series of Principles under the title of 'the "No Asshole Rule" Project Team Charter', and this is the second of those to be published.

The Introduction, Context and Summary of all the Principles is in a master blog post: "the No Asshole Rule Project Team Charter"

The context to this series is a book called "The No Asshole Rule" by Robert Sutton, a Professor at Stanford University and the author of other books and papers.

This next principle addresses the "why are we here?" question that is sadly all to frequently not asked. It also addresses time and cost.

I thought about splitting them into 2 but to my mind its all part of the same cognitive process, so I left it as one.

Principle #2: We are Delivering Fast and Furious Value

I understand that this Project Team has been formed for a specific purpose: to deliver value to some person, group or organisation outside the team, who I will think of as my customer(s).

That value is defined as the solution to a problem that our customer(s) have; Or perhaps an opportunity that cannot be addressed.

I will keep uppermost in my thinking that our value is not defined by ourselves: our customer(s) define the value.

Therefore I must create situations and scenarios where that value definition is brought into the team and incorporated into the day-to-day activities and communications of our team.

This is not just the responsibility of the Project Manager or Business Lead: all team members must understand this and take responsibility for understanding what we are trying to achieve.

I acknowledge that the team I'm signing up to is *not* here to operate a Project Management Process, or build technical solutions, or define new processes in and of themselves.

These are the necessary means to achieving our purpose. The solution itself, and the processes by which the solution is delivered, have no meaning without this value being delivered.

I will work to encourage and support a a continual focus on end-delivered value. I will make it a personal responsibility to understand and empathise with that value in the way that our customer(s) see it.

I will assess critically the work that is being done and ask myself: "how is this helping us deliver value to our customer(s)?" and work to adjust what we are doing: to prune unnecessary or misguided activities in order to refocus on value delivery.

Further, I understand that my time and that of the other teammates, is valuable: it costs money. The tools and resources that we use to execute our project also cost money: big money.

And I recognise that there is an "opportunity cost" to the company in forming and supporting our team: when we are working on our project, we're not working on other things.

So I understand that I have an obligation to get our project done fast. The phrase "time is of the essence" is part of the daily catechism of my team.

And that we have an obligation to get it done as cheaply as possible in terms of the resource consumption required to deliver the target outcome.

Not dumb cheap, but the most inexpensive that we can come up with the meet the optimal combination of capabiliies.

We do not have a right to extend the project arbitrarily: to opportunistically expand work to spend an approved budget, or to consume an agreed amount of time.

I will constructively and respectfully disrupt the processes, activities, concepts and targets of my team where appropriate, in order to focus on fast and furious value delivery

If I don't prosecute my team's accountabilities as quickly and economically as possible, if I don't focus on end customer value, then I'm a Project Team Asshole.

Anti-Patterns

Unfortunately, the exceptions to this Principle are legion.

Firstly, with respect to value delivery, ask yourself the purpose of your current project. Or ask your team mates.

The most likely answers you'll get will be framed in terms of the project: "we're building an online application using Java and HTML 5 to enable customers to enter their orders via the public internet" or something similar.

Very few project teams (and almost universally if you exclude the business leads) will describe their project objectives in terms of the problem that they are trying to solve.

Perhaps, now that Agile is starting to become more widespread, you will get some essence of a customer related problem, but all too often it is seen through the lens of the project and its solution technology.

Partly, that's because by the time the project gets anywhere near a delivery team, it's already been framed in terms of the solution: these are the cards that the project team is dealt.

But that would change if the project teams themselves worked to understand what it was that the organisation was trying to achieve; better still: demanded it.

Secondly, with respect to time and cost, typical scenarios revolve around two clusters:

1. A emphasis on internal values, metrics and processes: "this is how we do stuff around here"
2. A lack of urgency, and a lack of a feeling that "time is of the essence" – "what's the point in busting a gut: the executives are only gonna change their mind in a few weeks"

These problems manifest themselves in many ways but most often within corporate environments with matrix managed operational principles. Smaller organisations typically have a different problem, which I'll address in another principle.

Both for reasons of Risk Management and operational efficiency, larger organisations have a standard way of delivering projects. And they invest in training people to follow those processes with the objective of standardising how deliver occurs.

This method of delivery becomes an end in itself; the checkpoints, controls, reviews and signoffs that are required become established and ingrained.

Anyone new to the organisation will spend more time thinking about "how do I fill in the WD-40 form to get my funding drawdown approved" than they will on "what is it that I'm trying to achieve".

And these behaviours trickle down into the sub-components of project delivery: how many "boilerplate" estimates or "impact assessments" have you seen that are modelled more on past behaviour and/or some standard process than on the specific problem that we are trying to solve.

There are a whole bunch of reasons that may drive this behaviour: being overworked, seeking to build secret contingency, boredom one's job, frankly laziness and lack of familiarity with the process can all be some of the reasons that people "just turn the handle" rather than treat each problem individually.

Due to the overheads in obtaining project funding there is a perceived need to make the most of everything that is approved: to use funds rather than give them up.