Discipline makes Daring possible.

Get off on the right foot

Get off on the right foot

Is there anything more annoying than having to give your information over, and over, and over again, every time you deal with a new department or a new team?

Well, yes, probably. But this annoyance is easy to fix.

So, create a simple checklist for setting up a client, so their information is in the right place, right from the start.

Download our free e-book on setting up a new client checklist for more.

Let me know how it goes.

Develop your corporate memory

Develop your corporate memory

You probably get fed up of answering the same questions over and over again.

People get really fed up of asking them – over and over again.

Collect frequently asked questions into one place and make them easily accessible to everyone – including prospects and clients.

Download our free e-book on FAQs for more on how.

Let me know you’re doing.

Tell your clients’ stories

Tell your clients’ stories

If your service is at all complex, stories make it much easier to explain your value.

So, collect as many mini-stories as you can about how you’ve worked to help your clients, and make sure everyone knows how and where to tell them.

Download our free e-book on collecting client stories to find out how.

I’d love to share some of your stories – let me know how you get on.

Don’t let the wrong one in

Don’t let the wrong one in

Your time is valuable.

Your prospect’s time is even more valuable.

So if you’re not right for them you need to let them know as soon as possible.

Put together 3 questions that will tell you whether or not your business is right for them.

Then ask them as early as possible.

Download our free e-book on qualifying out to find out how.

Let me know how you get on.

Paying is part of the experience

Paying is part of the experience

I vividly remember the butterflies in my stomach as I handed over the cash. It was a lot of money to pay for a book – £40, when a paperback cost less than £1.

Would it be worth it? Would I regret it? What were the other people in the shop thinking of me as the assistant handed it to me, here in this ‘insider’ shop, catering to the trade?

They were oblivious of course, but for me, buying this book was my initiation into the world of fashion designers and insiders, the people who go deeper than the weekly magazines or even Vogue. Handing over what my friends and colleagues saw as an obscene amount of money for a book was an essential part of that experience.

If, like many small businesses, you see payment as an add-on, a bit of admin you’d rather put off, you’re depriving your client of the chance to relive the reasons they agreed to buy from you, diminishing their experience and in the process, subtly de-valuing what you’ve given them.

If paying is part of the experience, then taking payment is part of the service and that means it should be an integral part of your process.



You know, that stuff you do out of hours, in the evenings or at the weekends. The stuff you put off to the last minute because it gets in the way of ‘doing the real work’ – even if it means you get paid late.

Except there is no such thing.

Your business is a single end-to-end Process of sharing your Promise of Value with the person who wants to hear it, then delivering on that Promise once they have signed up for it.

That person has agreed to pay you money in exchange. Taking payment (however you do it) is part of the service.

Everything else is a side-effect.

A blast from the past

A blast from the past

In my early days as a software engineer, back in 1988, this book (“Principles of Software Engineering Management” by Tom Gilb) was my bible.

We’d just acquired a new client, who’d been told that the networked point of sale software they’d just ordered would be ready in 3 months.

The trouble was, what they’d seen was a mock-up. We hadn’t even begun to think about designing or building it.

So, having found this new book a few weeks earlier, I decided to follow its principles.

Having mapped out a high-level architecture for the system, we put ourselves in the shoes of the customer – a large department store – to work out which elements we should deliver first.

Next we worked out which parts of the standard software development approach we could ditch, without compromising maintainability (I learned to code with the MOD, so maintainability was key).

Having stripped our development process back to just what would support the things we really cared about – software that did what the customer wanted reliably, delivered in business-useful chunks and in code that could and would be easily maintained in future – we were rigourous in sticking to it.

Everything else was low-tech and informal. We were a small team in one room with a whiteboard, and could communicate well enough to keep things on track and under control.

We were helped by a fantastic boss, who believed in us, and defended us from the traditionalists outside our team.

It worked. We didn’t deliver the whole system in 3 months, but the client was more than happy.

They got what they needed when they needed it. As they populated products, we built the departments piece, and so on, each delivery fully tested and working properly, building on the previous one until the system was complete.

And we were the first to market with this kind of product.

The point of this little nostalgia trip?

The right level of discipline makes daring possible.

In praise of Maps

In praise of Maps

The idea of making a journey foolproof isn’t a new one.

Published nearly 350 years ago, John Ogilby’s road map isn’t so different from your GPS device – simply follow the route from one point to the next, as if you’re travelling in a straight line from London to Harwich.

This is great when everything works as expected.

When it doesn’t its useful to have a more accurate idea of the direction you’re taking, where you’re headed and what’s around you along the way. That way you can quickly work out a practical alternative for getting to your destination.

By all means optimise the routine with a GPS.

Just make sure everyone also has access to the map.

A business notation?

A business notation?

Here’s what I think works well:

  • Simplicity. A small number of elements with very few variations. In the above example, bubbles represent Activities, the arrows the pathways that can be taken through them.
  • Plain language – what I call ‘Anglo-Saxon’ – as spoken by ordinary people. Active verbs, combined where needed with a single noun. Together they express the desired outcome of the Activity.
  • Some rigour, but not rigidity. The aim is to communicate the what to a competent and intelligent human being, not a robot or a computer. A bit of fuzziness is tolerable if it helps to get the idea across in an uncluttered way.

Frameworks for Collaboration

Frameworks for Collaboration

Whenever we want people to collaborate on a complex project – each person contributing their own expertise – we find a way to share information about what we’re trying to create.

Whether the project is a religious ceremony; a dance; a film or a building, we have no problem with using simple, clear, shared notations that help everyone involved to understand what needs to be done without getting bogged down in the detail of how to do it.

We’re happy to let each person be responsible for the how, as long as it delivers the what we asked for (or better).

Why do we make it so hard for the people in our businesses to do the same?