adoption curve dot net

Here’s a simple technique that we use on a regular basis as a ’sanity check’ for the technical requirements of a development project. The idea is that you guard against the tendency to load the system with glamorous – but unneeded – features that will increases the risk of project failure.

The process is extremely simple:

1. If it’s not already been done, write out the functional specifications as a numbered list of requirements.
2. Do the same for the business requirements that were identified in the earlier stages of the project.
3. Take each functional requirement in turn and cross-reference it against one or more business requirement. At each iteration, ask yourself “what business benefit does this feature deliver?”
4. If there are any functional requirements that can’t be linked to a business requirement, ask yourself if it’s needed – and be very sceptical of the answer if it’s “yes”.

The idea is simply that each and every feature of a system should deliver some value to the business – if it doesn’t, you’re in danger of building in flashing lights for the sake of it. And there are numerous dangers with that approach:

• The system will take longer to develop.
• It will become more complex to use.
• The internal interactions between features will become more complicated, and unintended consequences will become more likely.

This technique is just the “keep it simple, stupid” approach put to work. But in virtually every organisation we go into we hear stories about development projects that have gone wrong because of feature creep and its consequences – so this is a technique that’s simple enough to be done quickly to try and guard against these kind of disasters.

If you’re currently engaged in a debate about whether blogging could help the public profile of your organisation – and you’re encountering the “if it was any use then big firms would be doing it” line of resistance – you might be interested in pointing out a new blog that’s just come online.

It’s a small company that you might have heard of in passing – General Motors.

Yes, the General Motors. And it’s not some anonymous drone in the marketing department that’s blogging – it’s the Vice Chairman of Product Development and Chairman of GM North America, Bob Lutz. I always find the US style of executive job titles a bit confusing, but I think we can safely assume that he has the key to the executive washroom.

Reading the posts so far, it does appear to be a genuine blog by a real person – it’s certainly not written in the corporate house style that you’d expect from a PR agency. It’ll be very interesting on three counts. Firstly to see if he can keep it up, and secondly whether he can manage to be interesting without revealing too much that would be of interest to his competitors – you have to assume that the inside of his head would be an interesting place to be if you’re a rival. And lastly, it’ll be fascinating to see if this starts a trend, either within the motor industry or more widely. 2005 could be the year of the CEO blogger.

We all have days when despite a to-do list a mile long, we’ll find any excuse not to get on with the task inhand – or indeed any task. Regardless of best intentions, it’s all too easy to put something off when a few minutes would be enough to get the job underway or finished completely.

This article by Steve Pavlina, CEO of Dexterity Software, has a look at the root causes of procrastination and has some useful insights into what you can do to overcome it.

The solution to perfectionism is to give yourself permission to be human

They’re simple methods, but effective nonetheless – and could easily be coupled with a process such as Getting Things Done to make a good attempt at breaking bad habits. Now should I get on with updating these project plans, or make another coffee….?

Via Moonwatcher, this is a presentation on how Lucent are using blogs as a project management tool. It’s interesting for a number of reasons – firstly as an example of how blogs can be used (and the suggestions that are made in the presentation match our experiences, so this is far from being specific to a high-tech industry).

And there are also a number of very good points made about how to go about introducing new processes into an organisation, regardless of whether they involve software tools or not. It chimes with something that we’re keen on – the idea of having ready a 30-second elevator pitch to sell the project that doesn’t rely on a detailed explanation of the technology. Focus on the benefits that will accrue, and leave the technology – however exciting – alone.

And if you’re unconvinced about the merits of an elevator pitch, consider how convincing is this 2-second explanation of the plot of Alien: “Jaws in space”.

Michael Harmer of the delightfully-titled Nerdherding for Beginners has a useful piece of advice about clarification-requests-as-a-delaying-tactic:

“You can’t drop a ball that isn’t in your court.”

As he points out, bouncing a request back to the originator has a use for evil as well as good – and suggests a way of dealing with requests that get bounced back to you. So beware – if you’re a regular user of this tactic, there may be clients who will call your bluff after reading his post