Good project managers define and clarify the idea, break the idea into features and then deploy the features into production. But quite often, people just don’t make use of the shiny new features they have been given.

Which is another way of saying that the great idea fell on deaf ears. So some organisations bring in change managers (and trainers and technical writers) to make sure people understand the new idea.

Good change managers make sure that the project is visible to stakeholders, supported by the important stakeholders and that the features being deployed are explained properly to the users. But quite often, the users go back to their old ways after a week, or they complain about the new features and the “stupid” projects that created them.

Which is another way of saying that the great idea fell on deaf ears.  So what goes wrong? Why do so many good ideas fail to get adopted?

The first problem is probably that good project managers focus on delivering what they have been told to deliver – So they focus on efficient delivery.

But planting a seed doesn’t mean that a healthy plant will grow from it. And expecting a project to lead to real change and then asking people to focus on the efficient delivery of its features into production is like exactly like wanting a plant to grow, and then optimising the process of putting the seed in the ground.

It may be necessary to plant the seed, but it is not sufficient.  Imagine if your gardener reported that seeds were:

“planted really well, imbedded precisely 1.7234cm under the soil, meeting the budget of 20c per seed and with a turn around time of under 2 seconds per seed”.

Would you really feel confident that your garden would flourish? To get a plant to grow, we need to at least prepare the soil so that it accepts the seed. And this is why some organisations bring in a specialist change manager.

Unfortunately, I think second mistake we make. We often see change management as a process of preparing the organisation for us to deploy a new set of features on a project.

Ask a gardener how to grow, for example, a tomato plant. They know it is necessary to prepare the soil and plant a seed. But their explanation will not focus on these aspects.

A helpful gardener will talk about the need for sunshine (but not too much), or how much water the plants will need. They might talk about different types of tomatoes that grow in different climates or the need to protect the plant from aphids.

In fact very little of what the gardener talks about involves “implementing” the plant (ie putting the seed in the soil). Most of the advice will be about sustaining the plant after it is “implemented”.

OK, I will admit that gardeners have the advantage of being around to monitor and assist the plant as it grows. But most project managers move on when the project ends.

So, can we expect projects to make change when the project team moves onto planting the next idea, just when the current idea is starting to bud in the soil?

Some project managers get around this problem by deciding that “I am responsible for implementing the project plan, but the sponsor is responsible for realising the benefits”. Some project managers even grow cynical after watching their good work go to waste and blame the “stupid users”.  Comfortable conclusions for the PM I guess.  It means the PM can plant the seed in rocky soil and walk away while the seed inevitably dies.

Unfortunately though, in modern organisations even the sponsor of the project often moves on. With so many restructures and shifting organisational needs, there is no guarantee that any of the executives or project team will be in the same role for long after the project is completed.

And since most projects cost more than the price of a tomato plant, it seems strange to me that people are happy to spend all that money without knowing how the benefits will be realised.

Again, we can blame the organisation, or the senior managers. And maybe they should do more in the area of benefit realisation.

But there are concrete things the project team can do to ensure that those seeds that are planted are going to grow.

My last few articles have been about assessing the environment before “planting any seeds”.  So rather than “preparing the soil” we can make a realistic assessment about what elements in the environment will help or hinder the implementation of our projects (by “implementation” I mean real implementation – adoption by the users, not just deployment into production).

This allows us to modify the seed we are planting (say by planting a sapling, or planting the seed in early spring etc) and it also helps us to understand the real factors that will help or hinder the ongoing adoption and growth of the idea over time, even as the seasons change with restructures and new project.

But the final reason why I think great ideas fall on deaf ears is the sheer complexity of the environment into which the idea germinates. As a result, project teams are overwhelmed by the sheer number of possible factors that they might take into account in the short time they have to plant their seeds.

So we must now tackle ways to sort through the information we gather, to really focus on those key areas that will support the adoption and growth of our ideas after we deploy our project into production.

But a comment on a recent article reminded me that I can be completely logical, and still not get my message across, if what I am saying is inconsistent with what people already think.

Akarmin (who left the comment) described the principle of consistency really well so I won’t repeat the description here. But I will provide an analogy and then talk about consistency within a document (as opposed to consistency of the document with the existing views of the audience).

Stories and analogies

When you see a friend from work at a venue that has nothing to do with work, you might not actually recognise them, because you are seeing them out of context. And in the same way when you see a comment in a document that does not match what you expect to see, or what you currently believe, then you will often simply skim the comment and interpret in a way that is consistent with what you already think.

So it is often helpful to provide the reader with a story, an example or a comparison to help them make sense of what you are saying. This helps them anticipated the idea that you are presenting and it also uses the principle of consistency to your advantage but making it appear that what you are saying is consistent with the story they just accepted (does this make it another example of a fallacy?).

Good writers of technical documents will use analogies, stories and so forth really well. Bad writers will use them far to often, or use them to distract from, rather than assist with, the understanding of what is being said.

So if you want to use your own “stories” within a technical document or presentation, you can check the story is useful by being clear on the following:

• The story;
• The point of the story (or the moral of the story); and
• The relevance of the point to the story to the argument or information you are presenting.

Similarly if you are trying to understand someone else’s document, you can also just write next to each “story” (Example, comparison, story, metaphor, etc) what the point of the story is and whether/how it relates to what is being put forward in the document.

Paragraphs, headings and document flow

Documents are easier to read if they unfold in a consistent way. 

A single paragraph should cover only one idea and the first sentence in that paragraph should set the scene for the rest of it. Compare these two paragraphs, for example:

My dog Lassiter is very friendly. He is a Labrador and they are particularly friendly, although dogs are generally friendly. The other day Lassiter …

Dogs are generally friendly, but Labradors are particularly so. Take my dog Lassiter, the other day he …

In the second example, I set the scene in general terms and then provide a specific example. I could have provided a specific observation and then connected it to a more general conclusion just as well, but if I jump around like I did in the first example then it is harder for the reader to follow what is going on. So each paragraph should either begin with a sentence that emphasises it most important point, or provides the context for the rest of the paragraph.

You can further improve the structure of paragraphs if I keep the same point of view and that people don’t provide multiple viewpoints in the one paragraph.

Or, more clearly, you can improve the structure if you maintain a consistent point of view throughout the paragraph (ie don’t hop around between, saying “customers can …”, “you can …” and “It is possible to …”).

Similarly, changing tone, terminology, or fonts within a paragraph can distract the reader from what you are saying.

But what about when you are reviewing a document someone else wrote? One thing you can do is turn each paragraph into a single sentence and see if you can make sense of the document.

Another thing you can do is go through the headings and subheadings in the document without reading the text. These will often provide a high level summary of where the document is going and what overall messages it is designed to convey.

In a good document, all the sub-headings under a heading will relate to both the heading and the other sub-headings.  For example, if the heading is “Cheese” the possible sub-headings might be “History, local varieties, qualities to look for”; or they might be “Edam, Cheddar, Blue”.  But it would be more confusing if the headings were “History, Edam, Other, qualities to look for”.

Predictably, this also means that your own documents will make more sense if you review and align the sub-headings so that they flow well.

So, each paragraph captures one idea and each paragraph within a sub-heading should support or expand on that sub-heading. Then each sub-heading within a section should have the same structure and should support or build on the section heading.  And finally every section should break down, build on or support the overall focussing question of the document.

Thus to make sense of a document, it is useful to not only review the content, but to also review the structure of the document and the purpose of the different sections of the document.

We got talking about the retrospective at the end of a project.  So I published a story of sorts on how to run a retro for 70 people at the end of a project.

At the end of the discussion I promissed to publish some of my comments so I put them together in a short story about running a retrospective.  You can read it hear if you are interested:

http://www.theagiletribe.net/2010/11/04/unusual-questions-to-ask-at-a-retrospective/

Apparently the “they” teams are likely to fail and the “we” teams are generally successful.

This made sense to me because when I have always listened when managers use the terms “we”, “you” and “I”. The dodgy managers I have worked for tend to use pronouns like this:

• “They” or “management” want us to … rather than “I would like to … “;
• “You” messed up or “team member x messed up”; and
• “I delivered” something.

I even heard a manager once say “if it was up to me I would do … but you know that management wouldn’t accept that”.  Which was interesting since the person I was talking to was “management”.

On the other hand I have also had good managers and I have noticed that they tend to say:

• “We” messed up or “We” have a problem;
• “You” did a good job; and
• “The team” delivered something.

But I have not previously thought about actually counting the times members of the team say “they” versus “we” so I think I will try that next time I am auditing a project or coaching a team.

A similar thing I have used in the past though was to see if the team (particularly IT teams) refer to their internal customers by name (eg Brian or Mary) or whether they refer to them as “the business”.  It’s interesting how often people refer to “the business” as the customer. 

So my new predictor of success for teams I coach is going to be based on

1. The number of the times they use the term “we or us” versus “them” and the number of times they refer to stakeholders by name versus using the terms “they”, “management” or “the business”.
2. The number of times team members use the term “we delivered something” versus “I delivered something”. 
3. The number of times the team say “we stuffed up” versus “x stuffed up”, “they don’t know what they are doing”, or “that’s not how I think they should have done it”.

What do you think – will there be a strong correlation between the use of different pronouns and team success?

There never seems to be time to do things properly – but don’t worry, there will be time tomorrow to react to the crisis that resulted from  what you didn’t do properly today.

To avoid this crisis management though, here is a simple way to measure the “technical debt” we are creating today.

Put the following table up on a white board and have each team member put their vote into the appropriate box.  For politically charged projects youmay even have a secret ballot.

Rather than voting out of 5 however, they are comparing the system before they touched it to the way it will be after they deploy their changes.  Specifically their votes will be as follows

• 0 means that there is no real change in the measure;
• + 1 means things are better than before and +2 means a lot better; and
• - 1 means things are worse or more complicated than before and -2 means even more so.

Now simply average the answers to give a score for each question. 

Hold regular retrospectives or reflection sessions should highlight the ongoing impact of building (or removing) complexity from your life.  But if you want a solid predictor of the impact is will have over time, try using this creeping doom graph (which can also be a virtuous circle graph if you are actively making things better each week).

Creeping doom or virtuous circle of improvement?

Or better yet - give me a call.  I will come and run a couple of workshops for the team to help them see where they are creating un-needed complexity for themselves.  And more importantly I can help them turn the creeping doom graph into a graph of positive improvement – honestly … it can be done.

One of the things that often interests me is that teams feel like they need to cut corners this week to get their work done even though they know it will make life harder next week.

Everyone in the team would say that what they are doing and yet everyone feels like they have to do it. So why do they keep making life harder for themselves (or for the team inheriting what they do).

One theory is that people are evil and will therefore eagerly and knowlingly make the world a worse place. But I have an alternative theory – I think that people are focusing on the things we measure – the things that are top of mind.

So I think one of the causes of stress in the world is simply that people are measuring and focusing on the time it takes to complete each task in front of them, without having time to meausre (or focus on) taking the time to make things better for the team next week.

As a partial antidote to this problem, I propose that we apply an easy measure of the impact we are having on the future ability of our team (and others) to support the work we are doing this week.

In IT teams there are ways of doing this – using measures such as code complexity and function points for example.  But they can be hard and I am lazy.  They also focus on the code and not the data, the overall design or the process changes we are making.

Another approach is to create and update a system (or process) heat map. But on top of this, we can also predict the impact we are having by simply asking the team what they think will happen with the work they are doing.

I will post a couple of ways of doing this – but more importantly, why not just do it?  Next time your are in a team meeting, implementation planning session or restrospective, just ask the crew

• Whether what they are doing this week is making life easier for themselves and others next week; and
• What they would do about it if it was up to them.

I bet they can answer both questions quite clearly … and I bet life would get better if they (and you) acted on the answers.

When I do, I generally ask them the same questions to get a better feel for what is going on.

I really liked a set of questions I picked up from a book called “The First 90 Days”, so I use a modified set of them:

What is your role?

• What does that mean?
• How would you explain it to my mother?
• How would others explain what you do?

How confident are you the project will meet it’s objectives?

• What are the objectives?  Really?
• How clear are you on the objectives?
• What do management think the project is doing?
• What do others think?
• If it fails, where will it probably have gone wrong?

What is the biggest issue facing the project?

• What would happen if we could get rid of that problem?
• What would need to change to get rid of it?
• How could we deal with that problem?
• How is it impacting us/the project?  How does it impact you?
• How are we currently dealing with it?
• Why is it still there?  What is stopping us deal with it?
• What should we do about it now?

What is the biggest unexploited opportunity in the team?

• What would have to change for us to exploit it?
• What would happen if we did?

What would you do if you were me?

Most projects are really really complicated.  But most people know how well it is going or how scary it is if they have time to think about it.  So I find you get a pretty good overall understanding if you just ask everybody these questions.

My first question is generally “what is the project about?” But that generally leads to a vague answer.  So I use my “question compass”:

My question compass

These are the questions I use to get a basic orientation when analyzing just about anything.  By way of explanation though, I don’t always use the exact wording shown.

When asking “what do you mean” I use a technique that sounds really simple and is surprisingly effective – the “nouns and verbs” technique.

I listen for a noun in a sentence and then ask “what do you mean by ‘noun’?”.  When I get a response I ask about one of the verbs in the response “How do people currently ‘verb’?” or “How do you envision people will ‘verb’”.

I keep doing this for a little while even if I think I know what people mean because it is amazing how often it clarifies my understanding.  Then I pick one of the things the person said and ask “why are we doing this project?”.

I do use the famous 5-whys technique to probe more deeply (ie ask why several times) but I also add the question “why else?”.

I was once told that we do things for two reasons – the right reason (the one we tell people) and the real reason.  I think it is a quote from someone famous.  But it certainly clarifies my thinking when I ask this question.

My next question is “Is that true?” and I ask this one in a number of ways:

• What would the team say the purpose is if I asked them?
• Do all the steering committee share the same understanding?
• How do you know that is true?  How do others know?
• How would you know if that was not the case? (my favourite question).

Almost there – but I still have one last question – “So what?”.  Like asking if something is true, asking so what can seem a bit blunt.  So I ask it in a couple of different ways:

• What impact is that having?
• What would happen if we didn’t do it?
• What would the impact be over the long term if we don’t do it?
• What will happen if we do it?  What else will happen? What won’t happen?
• What are you hoping won’t happen if we do that?
• What will the team/customer say when it happens?

After these questions I generally at least have some idea of what is going on – which is often the best place to start.

Apparently it is more effective to ask yourself “Will I succeed” than to say to yourself “I will succeed”.

Will I apply that lesson next time I want to achieve something important?

While we might be right, we realised that it is a bit wimpy to suggest that someone else has to fix accountability for a project you are on.

So we had a long discussion about what we could do on the project and we concluded we just needed to make sure we were clear on
- what we delegate (including escalate or ask for);
- when we are ambiguous about our own accountability for something and our own authority for getting things done
- when we were assuming someone else was “handling something” and when we thought we were.
- Next project we will go back to basics and insist on a session where we sit down and explain our roles and responsibilities to each other and then debate them.

We have already had improvements in less that a week. It was so simple that I am wondering if it is worth creating a one day course that covers nothing more than delegation, follow up and expectation setting. Would you come to a course like that or is it something you already know and do?