And while I’m on a linking roll, here’s Martin Burns’ Glossary of Project Management Terms…
Archive for March 2005
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:
- Are understood by everyone
- Are agreed to by everyone
- Are documented such that there is no room for arguments
- Are the basis for accurate planning of work and budget
- 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.
I’m not going to waste too many electrons in expounding what a deranged and fundamentally bad idea the European Directive on Computer Implemented Inventions (aka European software patents) is – there are many, many people who can explain that far better (here’s a few:
- Free Software Foundation
- No Software Patents.com
- Foundation for a Free Information Infrastructure
- Petition for a Software Patent Free Europe
And I’m not going to waste too many electrons on the travesty of the democratic process that has taken place, with a Commissioner in the pocket of the corporate software cartel ramming through a piece of legislation that has been comprehensively rejected numerous times.
The bottom line is that it’s happened, and there’s one last chance to do something about it. For the directive to be kicked into touch it needs to be rejected by a majority of MEPs in the European Parliament – 347 of them, to be precise. So now is the time to start lobbying your MEPs to prevent this happening.
If it does, then open-source software as we know it will be lawyergrammed out of existence. Software will exist only by permission of Microsoft and Cisco and Nokia – anyone seeking to challenge the behemoths will simply be stamped out though the abuse of the patent process.
So write, call, email and fax. If the Directive passes, it’s because the corporations wanted it to happen – not because there’s any kind of a democratic mandate for it. This sets the direction for the kind of society that we want to live in – on the one hand, beholden to the best interests of the shareholders of a few giant (and largely American) corporate cartels; or on the other a society that balances the interests of society as a whole against those of the corporations.
It’s our choice.
If you want to start a fight (or at least a heated argument) amongst a group of project managers, the best way is to gather them at a bar and utter the statement “I think methodology X sucks / blows chunks / is the greatest development in the field of project management since the invention of the Gantt chart (delete as applicable)“.
Then stand back to admire the chaos you’ve just caused.
There’s a similar debate (albeit much more civilised than a bar brawl) going on in the Ecademy Project Management Community forums at the moment – there are advocates and detractors of Prince, those that see methodologies as fundamentally flawed, and every shade of opinion in between.
The discussions got me thinking. The fundamental problem with methodologies is that they’re not always applicable all the time. And the decision process about which parts of which methodology to use at which time is pretty much intangible – it’s something that comes with experience rather than training.
The temptation when you’re an inexperienced project manager – or an experienced one operating beyond your comfort zone – is to use a methodology like a cross between a crutch and a security blanket. If outcomes are looking dodgy, a methodology can be a great process to lean on. And if you’re made uncomfortable by the environment or the stakeholders, you can bury yourself in the familiar rituals of the process to block out the nasty, uncertain world outside.
And if you’re not a project manager, then the temptation to put misplaced faith in a methodology is even greater. It’s a part of the human condition to crave certainty, so if a methodology is presented to you as a sure-fire way of guaranteeing an outcome – and you’re blinded by the flashing lights and jargon – it’s understandable if you put your faith in it.
That’s not to say that methodologies are fundamentally flawed, just that they’re a tool. As the old saying goes, if all you’ve got is a hammer, every problem looks like a nail. Now if only there was a methodology for working out which parts of the methodology to use…
No sooner had I posted about the obsession that some recruiters have with budget size, then the phone rang again with a similar question. And over at Projectified (which comes with a great strapline), Brian Kennemer commented on the post, pointing out:
But I have to say that I think this theory breaks down to some degree. I think that big, high stakes projects carry with them different kinds of pressure than small ones. Also in many cases large budget often equates to large scope.
I think that last point is actually the key to my argument – a budget is actually just one proxy measure to the business scale of the project. The larger the budget, the larger the scope and the larger the impact. But absolute measures of budget are meaningless unless you’ve got the context in which to put the figures – going back to the example I cited, the budget amounted to 10% of their annual turnover, and their entire reserves. Screwing that up by going 10% over-budget would have resulted in holing them below the waterline. If I’d screwed up the biggest project I’ve managed to date – well, missing the numbers by 10% would have resulted in some penalty clauses being invoked and some harsh words exchanged, but ultimately the organisation would have survived.
Which was the “best” project? From a personal perspective, the smaller one – there was no place to hide, so the satisfaction of bringing it in on time, on budget was all the greater. Which was the most glamorous? The biggest one, naturally.
What recruiters should be asking is “which project did you learn the most from, and what did you learn?” But that’s not a question you’ll be asked often until you’re talking to a recruiting manager rather than an intermediary.
