I’ve not been as effective as normal. Or have I? It’s been harder to engage. It’s been harder to structure a long string of thoughts. I’ve attended fewer meetings. I’ve dominated fewer conversations.  My little world did not stop turning on its axis. I’ve not been haring around with ten hours of back-to-back meetings and calling it work.

Instead people have approached me with their issues. “How do I best approach Purchasing to get something done?” “Should we even think about this one off piece of software?” “How do we go about boiling down a few thousand free text responses to a questionnaire?” “This component isn’t acting as I expected, can I just chat it through?”

Their issues. But presented to me not in a “you boss you set agenda you take decision” but in a “I could do with some help and I think you’re quite good at this” way.

Yes, some of this is about shifting the agenda from the formal to the informal. But I noted two generalisations:

• There were a lot of  ”should we’s?” I was being approached on “are we doing the right things?” (Ok, I grant I’m an unlikely person to approach to ask “am I doing this the right way?” But I’d rather focus on my strength for a moment.)
• There were a lot of “how do we simply?” In the face of a mass of confusion where did we leave Occam?

So, in terms of my strengths as others perceive them, I was used to simplify, strategically and tactically. I wasn’t asked what the best process to do something was. I wasn’t asked to design processes. I wasn’t asked to review budgets. I was asked to simplify, remove steps, boil to the essence. I was asked how cut to the chase and cut through the crap.

In this pay forward, play to strengths, era, this has me thinking – if that’s the value people seek from me spontaneously, should I emphasise this more?

If you were ill and slightly under the weather for a while – and let down your guard a bit – what do you think your “oh, while you’re not too busy” value added be?

If my intuition tells me there is a problem brewing with something IT related, I am going to go digging until I am comfortable. Right now, I am working on something that has provoked me to look at the approach we are taking to developing software. The first project on this particular got into all sorts of trouble and I would really like to help the organisation avoid making the same mistakes again.

What I have come up against is religion and bigotry. In the organisation I have in mind, there are two religions: “Waterfall” and “Agile”. The followers of Agile believe that those who do not follow or understand their beliefs are deluded individuals who live in a past that no longer works. The followers of Waterfall tend to be older than the young Agile radicals. They have seen it all before and have seen many false religions proclaimed, only to fall by the wayside when tested in what they refer to as “the real world”. There is no common ground. Each regards the other as heretical. I believe that there are good elements in each depending on the situation. I also believe there are good things in other religions that are no longer widely worshipped.

The history of software development is littered with “methodologies” that bear all of characteristics of religions. A very smart, charismatic person finds that the dominant religion of the time does not do not bring the salvation that was promised in their situation. They explore new ideas. The experiment with those ideas and refine them. They begin to discuss their ideas with critically minded individuals. Some of those individuals become disciples and spread the word. But then, crucially, as with all religions, the disciples interpret what the guru has said and write it down. The written word becomes the law, especially for new recruits who have no direct access to the guru. The original context is lost and now there is only the law and zealots.There is a ton of good stuff in “Agile” and I have already referenced Ken Schwaber’s excellent video in an earlier post. But as I continued on my dig, much of the stuff I read by Agile acolytes uses the terms “must” and “always” far too often for my comfort. Every new religion believes that it the only truth path. Actually, software development is often more like fashion that religion. I seem to recall experiencing.

• Structured Programming (notably Djkstra)
• Jackson Structured Programming
• Structured Systems Analysis (De Marco et al)
• Functional Decomposition (Yourdon et al)
• Spiral Model of Development (Boehm)h
• Information Engineering (IE)
• 4th Generation Languages (4GL’s such a Natural)
• Mathematically provable software (e.g.Z)
• Finite State Modelling
• Application Generators (e.g Telon)
• Rapid Prototyping
• Evolutionary prototyping
• Joint Application Development (JAD)
• Business Process Modelling (BPM)
• Object Orientation (OO) – does anyone really use inheritance?
• Object Oriented Analysis and Design (OOAD)
• Unified Modelling Language
• Architecture Driven Development
• Unified Process
• Dynamic Systems Development Method
• Service Oriented Architecture – functional decomposition in disguise?
• Scrum
• Agile
• Extreme Programming (XP)

I am sure you could add to the list.

Some of the above were progression from other son the list. Others discarded what had come before. But all have something to offer in the appropriate situation. Why not dip in and see what a Data Flow Diagram of the problem space might reveal? Or perhaps consider whether your off-shoring behemoth could be delivered in discrete working increments? Or could the problem be solved with a Finite State Machine? And so on.

If you need religion then how about being a software Buddhist. See your principles as guiding your journey but let other religions fulfil other complimentary needs as well?

“My fellow Americans, most of you probably know who I am by now but just in case not, I am Barack Obama and I am your new president. I’ve invited you here, so that I can run through about 30 or so slides that set out the aims of my presidency. And of course to have some drinks.”

Obama pauses, steps forward and taps a laptop key.

No of course it didn’t happen. The most engaging political speaker of his generation doesn’t do PowerPoint slides. Nor for that matter does Tom Peters or any number of business or political speakers. In fact, the video clip on my previous entry shows a technical but terrific presentation powered only by a felt tip marker and a whiteboard.

So why do speakers within our organisations, such as I suffered this evening,  persist in subjecting us to slide after slide of bullet points, designed to assist the speaker rather than the audience. Of course, styles vary. Some people simply read out the bullet points, extemporising as the fancy takes them. Others don’t even refer to the the bullet points, leaving us to wonder whether we should be reading or listening and failing to do either.

“It is a about time we did an update for the troops,” says the boss.

“Absolutely, communication is so important,” says Bob.

“So what shall we talk about?” asks the Boss.

Silence.

The boss is forced into action. “Bob, you can talk about Project Nectar, we haven’t done an update on that for a while.” Bob nods with a tight lipped smile. “Laura, you can talk about the strategic roadmap for the global capability outsourcing initiative. And Dave, you can talk about the work we have been doing on vales and behaviours.”

“Great”….”Sure no problem”….”Look forward to it”.

“So,” says the boss, “that means that you need to get your slides to me for review by close tomorrow, OK?”

And the steamroller is off and running. Each prepares about 10 slides, mostly in bullet points with one or two existing graphics – time is too short to do anything more creative.

Now, I reckon it take a minimum of 2 minutes to get through a slide, even if one just reads it out. So 30 slides equals a minimum of 60 minutes of being talked at. Now consider that a feature film, packed with pyrotechnics and tricks, needs to be pretty good to keep your attention for 60 minutes. It is going to feel like a long afternoon for the audience.

Not everyone can be Barack Obama when it comes to oratorical skills but everyone can learn from him

• Tell an interesting story
• Relate it to your audience’s experience
• Determine the 3 key things you want people to remember
• Learn to use rhetorical devices – say things in memorable ways
• By all means use pictures and graphs if they enhance rather than repeat what you are saying
• Use notes if you need reminders – no one minds
• Bring it up a level from the level of detail you think is needed – no-one is as interested the detail as you
• Keep it short – people reach saturation point after about 20 minutes

For help with the above, I strongly recommend Lend Me Your Ears: All You Need to Know About Making Speeches and Presentations

About 18 months ago, they decided to use a world-leading offshore software development organisation for a major new project. It was a long time since they had done anything as large, so they were keen to get the “requirements right”, especially as the development work was going to be done offshore. Unfortunately, this meant that they spent a very long time writing the requirements in enormous detail.

I say unfortunately because my experience is that that trying to write a  “perfect”  set of requirements is self-defeating. The approach resulted in a huge volume of paper which had to be signed off by a large number of people. Not only did this take a long time but with such a large volume of paper, it was expensive and things got missed. Needless to say, once the requirements went offshore, they were not interpreted in the way that the authors expected.

It is twenty years since Barry Boehm proposed a Spiral Model of development. Since then, we have had a range of approaches that sought to tackle the problem of writing full requirements, including 4GL’s, Rapid Prototyping, JAD, Iterative Development and now, fashionably, Agile.  All recognised that it simply isn’t possible to write perfect requirements. They all devised approaches to reduce the risk through regular deliveries of chunks of the finished, or near finished, software. Usually, this meant that the developers interacted closely with the users and were sometimes co-located.

I think the need for this type of apporach was accepted by 80% of the industry. But then along came offshoring. People compared day rates and skill sets, and concluded that offshore is cheaper. But as the work is being done offshore, the response of many companies was to go back to a waterfall approach, so that the full requirements can be handed off to the offshore team. Offshore companies try to mitigate the risk by having onshore teams but, often, they are not as tightly integrated with the development team as one might think. Cheaper rates do not translate into lower costs if the requirements take forever and the delivered software doesn’t meet the organisation’s real needs, as was the case in this instance.

I am about to help my client embark on the next phase of development. I have advised them to emulate an iterative approach by getting early and regular visibility of designs and developed software. As a minimum, they need to insist on prototypes, wire-frames, models and examples. Ideally, they need to insist that the software is delivered in regular coherent chunks. In adddition, I have advised my client that they need transparency of the supplier’s organisational struture, to fully understand where the supplier’s people fit in. They need to inist that the development orgnisation is directly involved, not just an “Implemetation Team”.

My inuition is that this is not the way the developer works and it is going to be a battle to get them to change. But I believe it is a battle worth fighting and will benefit both client and supplier in the long run.

I have set up a category for the project, named Project O, and will try to post regularly to that category, so that you can see how things turn out.

A company that I know of recently cut contract rates for IT staff by 10 to 15% across the board. To some, this might seem like smart management, responding to market conditions. After all, isn’t the role of contract staff to insulate permanent staff when things get tough? Well yes but, perhaps, by shedding labour rather than reducing contractor income.

Contractors know that they will get the chop when things are tough. But the quid pro quo of this is that they get a very good rate when they are in work. Cutting their rate just cuts their commitment to the organisation. And in this particular instance, over 50% of the IT workers are contractors. Many have worked for the company for years rather than months. Others are there because of the specialist skills that they bring. commanding premium rates.

Leaving aside the wisdom of a 50% ratio, across the board cuts are not a great recipe for workforce engagement. Contractors are an essential part of the workforce and need to engaged like anyone else. They also have the characteristic of being more likely to switch organisations than permanent employees. The ones that add the most value may not be able to leave straight away but will do so when opportunities arise, taking knowledge and skills with them.

I was advised that, “we don’t do points of view,” as if I had suggested something ungentlemanly. Their strategy was to offer help – a great sales technique!

My preference, if I was lucky to get in front of someone senior, was to tell them something they don’t already know. Something like: “from our research, this what we think is going to happen. If you don’t do X then your competitors will.”

They might not agree with what you are saying but if you can make them shift uneasily in their seats, thinking that maybe, just maybe, there is something they need to worry about, then you are on the verge of  a sale. And of course this applies as much to influencing from within an organidation as it does from without.

So if the person you see to influence doesn’t  have pain then maybe you can create it?

I am easily confused. I am confused now. Salesmen or, laughingly, “business developers”, cold-call and try to introduce me to their proposition du jour. I usually can’t puncture the armour of TLAs, USPs, value propositions and seamless interfaces. If they’re nice I share a cuppa and some biccies and bid them adieu. If they’re not the meetings end a bit more quickly. Why?

So, when do I think I should buy something? When it’s a free trial? Nope. I recognise that internal costs of resourcing and change often dwarf the cost of the product. The nose of that camel shall not enter my tent.

I have developed a clear model. It’s not sophisticated.

Am I in pain? Have I got a reliability issue? Have I just lost a valuable resource? Have we run out of something? That’s pain. I’ve probably screwed up. The odds are good I should have seen it coming and pre-empted it. I didn’t. That’s pain. If you call me on a bad day where I’ve finally figured out what my problem is and offer me a simple convincing solution I’ll be gagging to buy and get on with it. Your risk is that I allow myself to be over-sold – and you will have a pain scenario in a few months.

Pain always wins. Any pain blocks my syanpses. It’s like a bad paper cut; it needs salving.

If I have no pain points I am probably thinking of what’s going to next bite me on the butt. Fear. It could be my pain of the future. It could be thinking I might be missing a future boat; incurring an opportunity cost now by not being clear about the future. I’m afraid that if I don’t do something then pain is the next stage. I’ll be interested, thoughtful, engaged. These are usually the best sales experiences for both sides.

Hey, if nought else, if I’m afraid of something all you need to do is demonstrate that there is no boogie man in my closet. If I’ve seen the boogie man and am traumatic you really have to get rid of him.

Finally, there’s gain. Intriguingly, most people try to sell the prospect of nirvana: avaricious wealth, six nines of reliability, lower TCO than the interest on an RBS bank account, eternal youth. I almost never buy for gain. 75% of my budget, time, energy is spent on keeping the lights on. 15% is spent on keeping projects up and running. 5% is thought thinking about the future. And most of that time is spent on pain or fear.

So, sell to me. I know you have to eat. I spent most of my life on your side of the table. But know your animal. Probe for pain, fumble for fear – but only if all else fails, gamble on gain. I’m a simple beast. If you’re a commission bunny look for pain and close the deal. If you want a long-term relationship find my fear.

Pain is a transaction. Fear is a relationship. Gain is usually a chimera.

Clearly there is a responsibility on those presenting the options. But let’s face it, most people present options that push their own preference. You know the story, three options are presented:

1. The totally unacceptable
2. The one that brings fame and unimaginable wealth
3. Something in between

In reality, only one real, favoured option has been worked through and presented. The corollary of this, is that senior decision makers have to take responsibility to investigate and challenge what is presented, not take it at face value. It helps greatly if members of the decision making group themselves have diverse views that they are not afraid to air.

Take a lead out of Barack Obama’s book. He appointed Hilary Clinton as Secretary of State not because they agree on everything but because that do not. If you doubt it then you should know that one of Obama’s touchstone books is about Abraham Lincoln. It is named: “Team of Rivals”.

Of course, once the arguments have been hear and the decision has been made, there needs to be collective responsibility to stick by it and not bad-mouth it subsequently. That’s another aspect that some organisations find particularly difficult.

The senior members of the programme and functional management teams waited anxiously for news from the steering committee. But none came on the day of the meeting. The next day, the programme manager had a snatched conversation with the IT Director, who is on the committee, to get a debrief. The senior marketing person on programme talked to her boss, the Marketing Director, on the phone.

Unsurprisingly, the respective interpretations of what was agreed at the steering committee didn’t match up. The IT and Marketing  Directors had recalled the decision through their own particular lenses – similar but subtly different. A week later, nothing had been communicated in writing and squabbling broke out between the IT and marketing departments about what had been agreed.

Now I much prefer a two-way conversation to swapping emails but decisions need to be clearly communicated. This doesn’t have to be in writing if, for example, it is possible to get all or most of the team together for a debrief. Peter Drucker said that a decision hasn’t been made until it has been clearly communicated, with action plans are in place to make it happen and those plans are monitored in some way. Sound advice for any decision but particularly executive level ones.