Malotaux Mantras

Mantra: a word or phrase that is repeated often or that expresses someone's basic beliefs

During my coaching in projects I hear myself often repeating these sentences. If after a year I return to these projects, I usually hear them repeated in the corridors and at the coffee machine. Once someone called these the Malotaux Mantras. They remind us of important things we should not forget.

If I find time I may add some more explanation.
The links point you to a page where this mantra is used.
If you are puzzled about the background of one or more of these Mantras, feel free to ask!

Mantras, in no specific order:

  • First develop the problem, only then the solution, and only then the implementation.
  • The proof of the pudding is when it’s eaten and found tasty, by them, not by us.
  • Don’t work for a tool (nor for a process). It doesn’t pay your salary. Only if it works for you, then you may.
  • If we put our planning data in a computer, we lose control.
    Some people don't like the visibility and tranparency of whiteboard planning, hence they rather put their data in a computer.
  • The planning on the whiteboard should reflect reality at least once a week.
    We should be able to trust that the planning on the whiteboard is correct, according to our latest knowledge.
    If anyone asks, we can immediately explain what's on the whiteboard and why it is as it is.
  • NoQ-NoI: No Questions - No Issues
    At (least at) final test before delivery, the testers should have no questions and find no issues. If they have just one question to ask, of find one issue: the test is aborted as failed. “No questions, no issues” proved to be a good technique for turning the Zero Defects concept into practice quickly.
  • Testing shouldn't delay a delivery, but the testers don't cause the delay!
    Deming:
    • Quality comes not from inspection (V&V), but from improvement of the production process
    • Inspection (testing) does not improve quality, nor guarantee quality
    • It's too late
    • The quality, good or bad, is already in the product
    • You cannot inspect quality into a product
    Developers caused the delay. Testing can only show that the developers did a good job, or not.
  • We are not perfect, but the customer shouldn't find out
    People make mistakes, we are people, so if we do something we're introducing imperfections. The customer, also being human, is also making mistakes. If we both play macho, as if we never make mistakes, only seeing the mistakes of the other side, we will perpetuating these mistakes. If we're humble enough to admit that we are human and therefore making mistakes which are a risk for the success of the project, that's the start of doing something about it.
    Of course the customer will find out and knows we're human and will make mistakes. That's why I also use as an alternative:
    We are not perfect, but the customer shouldn't be affected
  • Any project that takes more than a year is doomed to fail
  • Time is money and we don't have the right to waste it, unless it's our own
  • Every day we know a problem earlier, we have a day more to do something about it
  • How do we make sure that in the end we don't need an excuse
  • Looking back we see that nobody could have done better, not even us
  • Active Synchronization
  • Interrupt Procedure: "We shall work only on planned Tasks"
  • We failed
  • What are we going to do about it
  • Because failure is not an option
  • If the requirements aren't clear (which is usually the case), any schedule will do
  • The fallacy of 'all' requirements
  • If we add something, something else will not be done
  • Delivery Time is a Requirement like all other Requirements. How come most projects are late ?
  • The Requirements are what the Stakeholders require, however, for a project the Requirements are the set of stakeholder needs that the project is planning to satisfy
  • Customer 'requirements': Nice Input
  • What the customer wants, he cannot afford. If we do that, we fail from the beginning
  • The Bullshit stamp
  • People aren't against change. Subconsciously they don't like uncertainty
  • What is the cost of one day of (unnecessary) delay
  • Important metric: The size of the smile of the customer
  • About half of what people do in a project later proves to be unnecessary hence we have a huge budget to be on time
  • People make mistakes, we are people, therefore when we produce something, we're injecting defects
  • The better focus, the less we'll waste time
  • In any meeting with more than one person, we use a projector
  • The owner of the text types
  • Where are the whiteboards ?
  • What you write down can be discussed and changed. What you don't write down, evaporates immediately
  • What we deliver, simply works
    Question by the PM: "Does that mean without bugs ?" Answer: "It simply works. Did I use a strange language?"
  • Quality is Cheaper
    Phil Crosby said "Quality is Free". Then he said "Quality is still free". My experience tells me Quality is Cheaper!
  • Can we do less, without doing too little ? Not doing what later proves to be superfluous
    Alternatively: Can we do less, while delivering more ?
  • If this project is late, the next project will also be late
  • As a rule, never work overtime, so that you have the energy to do it once or twice a year, when it's really necessary
  • Many documents to be reviewed within two weeks; people stressed: "stupid management", "impossible schedules" (not meeting deadlines is normal) ...
    • How many documents to review ?
    • How much time per document ?
    • How much time available ?
      • Needed time: 99 hrs
      • Available time: 46 hrs
    • So now we already know that we will be late. Failure is not an option. What will we do about it ?
    • Show some possible solutions
    • The puzzle of project planning is a design problem
      Now these engineers can use their bag of tricks, because they know how to design
    • Result ?
      Reviews done on time. Everybody content with the result. All subsequent deadlines are met
  • Why are we doing this ?
  • Is it really necessary ?
  • Is it really necessary now ?
  • Who's waiting for it ?
    • Example: "It worked ! The magic sentence worked !"
  • What does he need ?
  • How much does he need ?
  • Why ?
  • How much time do we have available = gross available time
    • 2/3 is plannable time
    • What are the most important things to do
    • We work on the most important things only. We don't allow ourselves to work on anything less important
      1. How much time do these things take
      2. How much time do you need
      3. How much time do you have
      4. How much time should you use
      5. How much time do you give yourself
  • What will fit the available plannable time
  • What will be done by the end of the TaskCycle
  • What will not be done
  • Will this be completely done by the end of the cycle? How do you know?
  • It's ok if you promise to do nothing as long as that is done, completely done