Tell 'Em

In one of my early consulting roles, transitioning from a technical consultant to a management consultant, I received some great advice from someone who had been in a purely consulting role for most of his career. Ironically, he'd been a student of mine when I was teaching the technical side.

When making a presentation, you can't make assumptions about your audience, & they won't make assumptions about you, so the best way to communicate your message is in three steps:

1. Tell 'em what you're about to tell 'em.
2. Tell 'em.
3. Tell 'em what you told 'em.

I know that sounds stupid, but it's true - have an introduction that explains what the presentation is about, then have the presentation, then a summary that reinforces the key messages.

When put like that, it's obvious. But how often do you present like that? Or how often do you sit through a presentation that has a middle & no beginning or end, where you walk away wondering if you missed something?

What has all of this to do with software development? Seriously - shouldn't this be in yet another blog? Well, no - software development has an equivalent.

1. Tell 'em what you're going to build.
2. Build it.
3. Tell 'em what you built.

Again, bleedingly obvious. Again, how many times have you not done it, or seen someone else not follow the pattern?

How many times has what has been delivered been a complete surprise to everyone? Or been ignored or misunderstood? What about the broken promises?

All sorts of software development infrastructure go into the three-step process - budget allocation, project sign-off, executive buy-in, business analysis, product management, user acceptance, test planning, marketing. All of the machinery around developing software relies on the three steps being there.

It is imperative that

1. Communication occurs before a software project starts, ensuring that the project parameters are understood & accepted, producing a plan.
2. The plan is followed, & variations are communicated (where agility allows for variations).
3. Deviations from the plan are communicated (plan hasn't changed, but the project has), & it can be shown how close the delivered product is to the intended one.

It isn't rocket surgery, but it is sound advice - even if I received it from a consultant.