It’s probably not too far an exaggeration to say that it’s changes that kill projects. Whether it’s because requirements were incorrectly specified at the start, or the business environment has changed – moving the goalposts mid-way through the game can really screw things up.
So it’s no suprise that most methodologies have a lot to say on the subject of capturing and managing requests for change (RFCs). And a well-run project environment will have some kind of formal process for dealing with requests as they arise.
Some of the problems
But often a project environment won’t have a process – and what processes exist are actually irrelevant in day-to-day use. Do any of these situations sound familiar?
There’s no formal process for capturing requests
The RFC process may simply be to send an email to the project manager – or worse, have a quick chat at the water cooler. This has the advantage of being quick and informal, but there are real dangers in this approach – the more informal the process, the more scope there is for the request being lost, or misunderstandings to arise. These manifest themselves in the “but I though we agreed to…?” conversations – and in the worst-case scenario can lead to the end-product being unfit for purpose.
The requests aren’t visible
If the requests are captured into a formal system – but that system is only visible to the project manager – you run the risk of other stakeholders being unaware of what’s going on. This can result in multiple requests for the same change (a good indication that it’s important, admittedly!), or changes being agreed that then impact on other stakeholders. This can lead to:
The requests have knock-on effects
Project requirements can be like dominos – a change in one can cascade into unforseen effects in other areas. And it may not be possible for the project manager to be aware of all of the potential ripple effects, particularly if they’re working on a project in an unfamiliar area. So agreeing to a change that looks on the face of it to be simple can lead to problems later.
So what can be done?
So if those are some of the problems, what are some of the potential solutions? Here are three techniques that we’ve implemented using weblogs to help in these situations.
A formal process for capturing project changes
In this situation, a blog becomes the change register. Anyone is able to post a request for change, which is immediately visible to everyone. The post’s category is set to ‘Received request’, and the project team is notified through the blog’s webfeed.
Once the change has been reviewed, the status can be updated to reflect this – ‘Reviewed: rejected’, ‘Reviewed: accepted’ and so on; and the blog entry itself updated with details of how the change will be implemented.
The benefits accrue from it being a quick online system that simplified and speeds up registering a change. If it’s a simple process, there’s no excuse for using a conversation at the water cooler as an alternative – which means that you as the project manager can knock back those requests with a (polite!) insistence that they use the blog.
Visible requests
As soon as the request is received, it’s visible on the blog and through the webfeed. That means that there’s a single bang-up-to-date repository of requests that anyone can check – before they raise an issue or a query. It cuts out the duplicates and enables stakeholders to remain up-to-date with what’s going on, rather than the blank periods between update reports.
Making the knock-on effects visible
Knock-on effects are often a problem simply because the person who would have realised that there were potential problems arising from the change didn’t know about it. Either they’re out of the change loop, or they simply didn’t have time to read the latest status report – it happens.
Blogs can help on both counts. Getting people into the change loop is a lot easier if all you’re asking them to do is passively monitor a newsfeed – they can rapidly scan and assess the relevence of an item in a feed far faster than skimming through a paper status report. And the speed with which you can deal with new items in a feed means that you are able to monitor a huge number of them – ideal if you’re in an environment with lots of projects going on simultaneously.
The start
Weblogs and feeds aren’t a ‘magic bullet’ that will banish change-related hiccups from the project landscape entirely. But they are a quick and easy way of making sure that your stakeholders are kept in the loop and up-to-date.
