Reliable Execution

if there is one thing that differentiates the laggards from the stars it is reliable delivery. A lot of noise and nonsense gets
generated when trying to deal with non-delivery and reliable execution, so here's a view from my own failings and observations.

To be successful with delivery, we should consider why projects fail first. But first what is a failure?
Many businesses see what others call failure as powerful and valuable learning experiences. They are the businesses
that set new boundaries, and push the limits. Their failures are always contributions to a broader body of knowledge and seldom repeated.
Some industries are truly remarkable with how failure is used. Take the airline industry and how they use failures to
make the transport business better. If a single aviation disaster occurs, the
postmortem insights are spread worldwide for a collective benefit. Imagine if banking did the same?

So failure is not about mistakes. It is about not repeating mistakes or acknowledging that mistakes will be made, then
making them quickly, cheaply and not repeating them.

Let's change our view then to stupid, avoidable, foreseeable and embarrassing mistakes, what do these have in common?

Often there is no ownership or senior accountability for what is happening. There's this strange business
habit of management disassociating themselves from the project delivery. Usually because they are technically inadequate and
uncomfortable with providing thought leadership. No thought leadership and project sponsorship = Cancel the project

The project is trying to deliver too much at once. Projects that have long time horizons sometime are necessary, but in reality
very few business projects can't be broken down into more discrete chunks that get delivered in stages.

Focus is lacking, often the curse of competence falls on certain individuals and they get pulled into every single project
and business discussion. Some people manufacture this non-focus into a believable reason for non-delivery. Have you ever noticed
how in some businesses people are so busy in meetings, busy being busy, but getting nothing done?

No integration architecture thinking. By way of illustration. Banks in South Africa still have systems written in code which is 40 years old!
How did this happen? You know, once upon a time it was just too much hassle and there was too not enough time and there were other
priorities, so that temporary system became legacy. This is why in many system driven businesses coding new functionality takes 1/10th of the
time it takes to system and integration test!

Obsession with business cases. A business case is only worth something if it develops into a benefits realization plan.
Show me a sophisticated business case and I show you someone who has too much time on their hands. Almost every business
case has assumptions embedded in it, from interest rates, size of market to contractual obligation constraints. A business case
is only worth something if after reading through it, you understand what they key operational drivers of value are that
must be managed to create value.

Lastly, the psychology of intrinsic motivators, reward and consequence management. Believe it or not, but a "thank-you"
and public recognition and acknowledgement mean more to some people than a bonus. Taking time to understand what effort some
people put in is sorely lacking in many businesses. I really feel for the project members who have to work with some
executive who fails to appreciate that some promise of new functionality, that takes 30 seconds to articulate, can take months to code and test.

The rest of the content here requires face to face coaching but here are some artifacts that serve a useful purpose in making delivery more reliable,

All of these templates are useful, but require some coaching for context.