Sentences

In my coaching practice, during the years, I've collected a lot of sentences, some of them 'magic sentences', which help us to remember things which often are contra-intuitive:

In any meeting with more than one person, we use a projector.
There are many good reasons for using a projector, especially while nowadays the cost of a projector is so low, that it's easily regained within a very short time.
Have you ever compared the notes people make when they are in a meeting? If you/they can read the notes at all, you will see that they all contain different observations. When people are scribbling, they focus on their writing and not on what is said at the same time. So, in the end people have missed a lot of what is being said.
Some benefits of using a projector (it's all psychology!):

• The 'owner' of the text is typing.
• All other people can observe, digest what is being written, and ask questions, helping the owner of the text to write the right things.
• If people write down what they are going to do and it's projected on a large screen and others also see it, there is much more commitment that what they are going to do is the right thing and that it will be done.

What we deliver, simply works.
"Does that mean without any defects?" asked the project manager and the architect.
"It simply works. Do I speak in a foreign language?" is the answer.

Who's waiting for it?
If it's not clear who is waiting for a certain piece of work:

• Who will pay for it?
• How do we know we are doing the right things?
• How do we know when we're ready?

If nobody is waiting for it, why are we doing it? Our boss doesn't get paid for it, so he cannot pay our salary for it. If you still like to do it, we call it a hobby. You can do that at home, in the weekend.

What can we do less, while delivering more?
Conventional project management tries to do as much as possible. In Evo, we try to do as little as possible, because:

• If it turns out that we did something wrong, we'll have wasted as little time as possible and have to redo as little as possible
• Doing as little as possible takes less time, so we have more time left for the next most important things

What the customer wants, he cannot afford
If we start working on that, we fail from the beginning.

What you write down can be changed. What you do not write down, evaporates immediately.
Our mind is quite happy with fuzzy thoughts:

Did you ever get stuck while thinking about a new plan or design? You went to a colleague and started explaining. After a while you say: "Ah, now I see!" The other person didn't say a word. Probably didn't even know what you were talking about.
By explaining it to someone else, you had to 'unfuzzy' your thoughts into sentences, making it more clear to yourself in the process. Instead of wasting your colleague's time, you can explain it to paper. When writing things down, you 'talk' to the paper. What you write down you can change and people can help you to see flaws in your thinking. What you don't write down, people cannot help you with, because they cannot look into your mind.
Thinking along these lines, I suddenly understood why people don't like so much to make documentation. They think it's all clear in their mind, but when they start writing it down, it proves to be so difficult to get a consistent document. I then suddenly realized that we don't in the first place document for others, but rather for ourselves: to unfuzzy our thinking, and more quickly seeing the flaws in our own thinking! Perhaps now you understand why I have a large whiteboard in my office.

Data may be defined at one place only.
If data (requirement, specification, drawings, designs, software code, information) is defined at more than one place, it will diverge (it will not stay the same, if it ever was). If data is changed while not at one place only, you never know whether you changed every instance. However, you need a method (document control) that assures that all places where the changed data is referenced from are informed of any change. Relational databases use this principle. The same applies to software: every function should be defined only once (it would have made the millennium 'problem' a piece of cake!).

Marketing should establish a system of continuously collecting information about experience with the products by the customers (ISO9004).
This goes back to the original Shewhart-Cycle: Design-Manufacture-Sell-Observe-Redesign.

Service should establish a system of continuously collecting information about problems with the products.
If Service has a system of collecting information, the forms are always well filled in and kept. They seem, however, ignorant of the idea that you can learn from this information.

Outsourcing the help/service desk function is killing the goose that lays the golden eggs.
If you outsource the help/service desk function, the aim of the organization providing this function to us is to maximize the work of the help/service desk, where our aim should be to minimize this work, optimizing the satisfaction of the customers and users. This service function provides important information for root cause analysis, for continuous improvement of our products and services. Will our provider supply us this information? Recently I visited an insurance company where the help-desk people were located in the room directly next to the developers. Not at another floor, but deliberately in sight! I liked that. They also liked it.

If the requirements are not clear (which is normally the case), any schedule will do.
Some project managers complain about 'schedule pressure'. I never complain.
Still, customers want to know when 'it' is done. They usually don't know exactly what 'it' is, but they want to know when 'it' is done.
I teach projects very early in the project to predict what they will deliver when, and then live up to that prediction.
That proves to be much less difficult than most people think.

Heard at Winnie the Pooh:
Tigger: "Piglet, come with me!"
Piglet: "Where are we going?"
Tigger: "I don't know, but we are taking the shortest road!"

We are not perfect, but the customer shouldn't find out.
Of course the customer knows we're not perfect. After all, he's not perfect either. So, more precisely we could say: We are not perfect, but the customer should not be adversely affected by our imperfection. To easily remind ourselves, I like one-liners better, especially once we know what we mean.

Two simple requirements we ask from our development team:

• Any time you deliver, within a week the users will be not less efficient than before
• Only if the users are happy, you get paid

You (development team) find out how to accomplish that. You are a professionals, aren't you?
Most customers don't dare to use these two simple requirements. They fear that the development team won't accept them, or even laugh at them for asking such stupidly formulated requirements.

However, if a development team doesn't accept these simple requirements, they actually say:

• Any time we deliver, the users may be less efficient than before
• The users may be unhappy with our delivery

Would you as a customer accept such an attitude? Actually, the first of the two requirements is a very weak requirement. Whatever a supplier delivers should make the users more efficient, not just as efficient as they already were. At the end of a project there should be a substantial improvement in performance. At intermediate deliveries, however, can't we simply ask for at least not less efficiency than before? If the users become less efficient, this costs a lot of money, which is usually ignored by the developers. They don't even realise the amount of extra costs they are causing. The customer usually also doesn't know...
Once we state these requirements, the supplier may ask for clarification how this will be measured. That's a good sign, because now we're talking! Still, the customer decides whether he's happy or not. It's up to the supplier to make sure the customer is happy and more successful than before (remember the Goal!).

Time is money and we don't have the right to waste it, unless it's our own.
Only if you're the boss and you're the owner of the organization, you may make a project fail. After all, it's your own money you're wasting. If it's not your own money, how do you dare to waste it (...food for a certain type of managers).

Comments or discussion:
niels@malotaux.eu