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.

Just Add Ingredients & Stir

This is how to make money in IT:

• envy others who have made money
• find some investment
• make promises
• hire some cheap developers
• tell them to build a product that is going to make money
• provide them with 'sufficient' capital expenditure
• base software decisions on open source options
• claim that you don't want to build a Rolls Royce solution
• demand harvesting of low-hanging fruit
• wonder why it's taking so long
• sit back & reap the rewards

If any of this sounds familiar, then you definitely work in IT. If this sequence has ever actually worked for you, then please send me an email, because I'd like to be one of those investors.

Reality is harsh, even in IT. People make a lot of money out of having brilliant ideas & the drive to put them out there & make them work. You cannot capture the market from your armchair, any more than you can develop good product without investing in what makes good product - people (product people, development people, marketing people, etc) & infrastructure (support, teamwork, process, leadership). There are no easy solutions, otherwise everyone would be able to just do it, which means that no-one would stand out, which means that no-one would be able to have any real success.

When packet cake mixes were first introduced, they were literally "add water & stir". These didn't sell. No-one wanted to move from fully-home-made to "do no real baking process" - the producer failed to understand the market, no matter how excellent the product was. The solution was a marketing one - ensure that the end user has to add an egg. This added complexity in the process made the production cheaper & made the end-user happier. The product sold like ... hot cakes.

Success in IT is the same - the product needs to be not just an excellent collection of ingredients, but a solution to an end-user problem that the end-user appreciates & can understand as fulfilling their needs. Anything less will sit on the shelf & grow mould.

A complete solution takes time to 'build' - as software, as an idea, as a product, as a solution (& these are distinct phases). There are no short-cuts. There is no easy way.

The newest buzz is "lean" - lean start-ups, lean development, etc. This means no wastage. Every CEO rubs their hands & says "That's what we want!" & cuts budgets or expectations. Lean actually means investing in the right things so that we don't waste time & resources on the wrong things. Process is essential when they support the development of product. People - the right people - are essential to produce good product. Wastage occurs when hiring 'anyone' is deemed sufficient, or else trying to hire "the right person"; when processes are imposed because they're "best of breed", or when no process is followed & people go around in circles doing the wrong thing for too long without realising, because they're too busy looking busy to notice what they're too busy doing.

Waste occurs when the only outlet for frustration is a blog that no-one reads.