Eyes on The Prize
So - a new year and, through careful preparation and planning, I have a whole new client as well. When I say “preparation and planning”, of course I mean that I answered the phone when the agent called, I showed up for an interview and then signed a contract.
Nonetheless, I feel that I have rather smoothly sidestepped the January slowdown. It’s a shame that the client’s offices are so far away, but at least I manage to get home each evening, unlike in the last job.
My new client has two major advantages: (i) He knows what he wants; (ii) He hasn’t done anything about it yet, other than hiring me. This gives us both the opportunity to get off to the right start. (This is much better, for example, than arriving to manage a new project and cheerfully being told “The good news is that we’ve already got a plan and everything - you just need to deliver it all on time”.)
So what makes a good start to a project? Without doubt, the most important thing to have is a clear project definition.
Initially you need to know Who’s paying for it, who’s managing it and what the point of it is. (This is pretty much where my cient is now, but the knowledge is only shared within his immediate circle of loyal departments.)
That’s all fine, but to really get a project started you also need to know:
- Specific objectives - How will we know when it’s done?
- Business justification - Why should we do it?
- Estimated timescales - Just to give an idea of the scale and to allow aligment with other projects
- Project approach - How will we do it?
- Team members and their roles - Who will be doing it?
- Project Management Plan - Who manages what ad reports to whom?
- Quality Plan - How will you make sure that things are produced properly?
- Initial risks - What could possibly go wrong?
if you think about it, there are very few ventures of any value that can be started without this information. Actually, that’s not true; you can start, but how will you know when you’ve finished? How will you know who should be involved and what they should be doing?
For a small project, all of this information might fit onto a single page. Others, including some that I have worked on in the last couple of years, have been sizeable documents and have taken two or three months to prepare (or, in one case, one month to prepare and one month to approve).
Aside from the nice warm feeling you’ll get from knowing that your project is becoming better defined, the real effect of this documentation starts to show when you get it approved and / or signed off. By forcing your senior stakeholders to think hard about these individual points (and they will think hard if they know they have to sign something afterwards) you are removing some of the worst possibilities for misunderstanding and lack of focus later in the project.
You can call these documents what you like (in Prince2 they are the Project Brief and the Project Initiation Document) you might even have a separate document for each point I’ve listed. The important thing is that someone has thought about it and written it down.
One thing I don’t have a clear feeling of is whether it is OK to change these documents later in the project if, for example, there are organisational changes that impact the team definitions. I’ve been asked to do this recently and it doesn’t seem right. I would rather leave the documents frozen at the point they were approved and add separate, supplementary documents as necessary. Anyone have any better ideas?
February 14th, 2007 at 3:28 pm
You are certainly starting your project off well, documenting and getting agreement on that list is a great start, and any changes to those things are certainly going to impact your project in a big way - much bigger than a piece of functionality not working for example. However, busines is business, and it often needs to change to be competitive, and projects need to change to ensure they deliver benefits to the organisation.
If you don’t update your documents, then they will not reflect reality (and you could have saved the 2 months you spent on writing them!). If you create additional documents people will have to search through multiple documents to find the truth about your project, and this makes it very difficult to be sure they are working with the same assumptions that you are. As the size of the project grows, the number of addenda increase and the more chance of people not sharing the same information about the project. Then, the trouble starts…
Personally I would put these changes through your issue management process, completing an impact analysis as a first step, and then identifying potential responses. From the cost of these responses, I would determine whether I could deal with this within the tolerances that the board had set, or whether it would require board approval to respond. Once the response has been identified and approved, I would update the existing documentation to show how the project was now going to work (ensuring the change control record had details of what had changed, why, when and who approved the change). If I had not asked for project board approval, then I would ask them to re-approve the documents at the end of the stage, as they are key documents within the project.
In your example of the organisation change, the project board may not be able to do anything about it, but they need to understand that they may get less than they were expecting, or that it may cost more money (or take more time) and adjust their expectations accordingly.