adoption curve dot net

And while I’m on a linking roll, here’s Martin Burns’ Glossary of Project Management Terms…

Here’s a useful approach for requirements gathering, courtesy of Martin Burns:

Without a doubt, the most significant thing you can get wrong in running a web development is to mess up the requirements. Get this wrong, and every thing you do after that is doomed. This article will teach you how to avoid this poison chalice and be on the first step of the road towards consistently delivering effective projects.

It’s a straight-forward process (the best ones always are, after all) of gathering, documenting, validating and baselining requirements:

The result of all this is that you’ll have Requirements that:

1. Are understood by everyone
2. Are agreed to by everyone
3. Are documented such that there is no room for arguments
4. Are the basis for accurate planning of work and budget
5. Are capable of being strongly defended against the “This week’s wizard wheeze” type of request

You could also combine this process with one that I’ve used successfully in the past: sanity checks for feature lists – to close the circle. You can then sleep a little easier knowing that your requirements are complete, agreed, documented and sane.

I’ve spent a while over the last day or two trying to coordinate a conference call as an alternative to a 350km rail journey and a face-to-face meeting – so I’m currently acutely aware of the limitations of virtual collaboration.

Dave Pollard has put together a matrix of collaborative tools, their advantages and disadvantages and the type of collaboration that they’re best suited to – which is a useful summary if you’re trying to work out what kind of collaborative nail you’re attempting to bang in with an online hammer. There’s no shortage of resources expounding on why tool X is the best way of doing Y, but what makes this resource useful is the listing of both upsides and downsides.

According to Dave, collaborative nirvana will look something like this:

I am confident that, as bandwidth and processing power continue to expand, we will soon see:

• A single, free, reliable, easy-to-use, professional-looking application that will provide what I’ve called Simple Virtual Presence — the four applications listed… plus the option of videoconferencing
• A simple, free, easy-to-use collaboration space where the results of the online collaboration sessions, and a library of relevant resources and links, are stored, with wiki-like capability so it can be maintained by any and all in the group.

Actually, it’s probably not too far away if you’re happy to mix-and-match tools that are already available – but based on the description above the Open University Knowledge Media Institute might already be most of the way there with FlashMeeting. Add something like SocialText to the mix, and the end result starts to look promising.

From the Enterprise Systems Journal: A Swiss Army Knife for Project Management:

One deliverable, two tools, and three rules form the essential Swiss Army knife of effective project management.

• Tool #1: A messy outline.
• Tool #2: A calendar.

Three rules:

• Small chunks
• First things first
• Like things together

The art in sophisticated project management lies in being clever and insightful about sequencing and clustering activities.

If you’re into mindmapping, then the chances are you’ve come across MindManager from MindJet. If you haven’t, then it’s well worth a look – although nothing will ever replace the sheer flexibility of pencil-on-paper when it comes to mindmapping, MindManager comes pretty damn close.

Via Projectified, I came across Hobart Swan, who’s a MindJet employee just starting up a blog covering the product – it’s relatively new, but he’s covering some interesting ground on topics such as using MindManager with a Tablet PC. That’s about as close as it’s going to get to pencil-on-paper.

But what struck me about the blog were the reasons for starting it:

“I am starting this blog because I believe passionately in the company I work for. There, I’ve said it. I came up in a period in our nation’s history when allegiance to a company was not exactly what my friends and I aspired toward. Old habits and predelictions die slowly. Nevertheless, here is sit four years after I began working for Mindjet amazed at my affection for a company.”

Which by any measure is exactly the kind of sentiment that you want from a company blog, and is the absolute antithesis of the old-style communication-by-press-release which we’ve accustomed to ignoring.

Prompted by an email from someone who found this site via Google, I’ve been playing with mobile posting from a Pocket PC to the blog. There are several Pocket PC clients out there – in more or less ropey conditions – but the one which seems to work the most consistently is SharpMT. Although it’s positioned as a Movable Type client, it’s talking quite happily to a Wordpress 1.5 blog – just amend the CGI-BIN path in the options screen and away you go. I’m using a Dell Axim X5, and it’s working fine via wifi and Bluetooth to a GPRS phone.

I haven’t tried playing around with image uploads yet, as that’s something that’s been a problem with Wordpress for as long as I can remember, but for basic posting on the move it seems to do exactly as it says on the tin.

There’s any amount of advice out there on what you SHOULD do as part of the project management process, so it makes a refreshing change to come across some ideas about things you SHOULDN’T do.

Stephen Seay’s blog provides just such a list, some of which are listed below:

Don’t believe everything you are told about a potential project’s benefits. Investigate for yourself and plan accordingly. Don’t take on a project that doesn’t have a strong sponsor that is committed to seeing the project succeed.

These are interesting ones, because the role of the project manager is often synonymous (or confused) with project cheerleader. To an extent that’s natural – after all, it’s not good for the soul to be running too many projects you’re not enthused about; but there are fine lines between enthusiasm, optimism and over-confidence. One of the most important roles a PM can perform is acting as a questioner of assumptions when it comes to the project’s benefits. If those benefits aren’t delivered, you can bet that it won’t be the sponsor who’s criticised for over-selling the potential – it’ll be the PM who picks up the blame for under-delivery, even if the benefits were unachievable in the first place.

Don’t forget that most project assumptions should also be risks.

This definitely falls into the category of “obvious, but ignored”. The clue is in the word – “assumption” is simply a more business-friendly alternative to the word “guess” – so if you were in any doubt as to why this was important, just try rewriting your project initiation documents substituting the two words, and see how it looks. Ideally, the initial risk log would be the mirror-image of the assumptions, with contingencies set accordingly.

Don’t set project expectations that are higher than reality can deliver. Don’t forget to manage customer expectations.

These two are linked in my opinion, and can be summed up as “under-promise, over-deliver”. Unless over-delivery itself is likely to cause problems – projects don’t exist in a vacuum, so cranking up the volume out of yours isn’t necessarily a good thing for someone else downstream.

All in, the list is a useful mental checklist to have at the back of your mind – the full posting is here.