Starting Projects

We're just about to start a new bespoke LMS project and it's got me thinking again about the right way to start any reasonably sized project. Prince2 calls it Project Initiation and in Prince2 the Project Initiation Document (PID) is a collection of documents that typically covers:

• Project Goals
• Scope
• Organisation
• Business Case
• Risks & Constraints

I don't why but I've always found it hard to write a Project Initiation Document. I suspect a lot of project managers go for the plan first and make that the basis of the initial meeting with the client (internal or external). The Project Initiation Document then ends up being one of those important jobs that gets left until later and then never finished because when the project's well underway there are more urgent issues to deal with.

A project 'kick-off' meeting though is the ideal opportunity to cover a lot of the same ground as the PID and at the same time meet the wider team. I'd aim for a half day workshop and would include the following:

1. Risk Register Run through the format and keep it as simple as possible - a spreadsheet with a few columns that's updated and reviewed regularly is better than a complicated 'dashboard'. Watch out for red/amber/green systems (I've actually listened to people try to define the meaning of different shades of amber) and explain why it's important not to leave the risk register until the last 5 minutes of the progress meeting - who wants to think about risks at the end of a 2 hour meeting?
2. Team Structure Definitely worth sharing a document at the start of the project with everyone involved (especially the people who are the edges and not part of the core team) that explains who does what, why they're important and how communication on the project is going to work. There'll people on the delivery side and the client side who'll appreciate a view of who everyone is and how they work together to deliver the project.
3. High Level Plan - early draft Share it with the whole team and walk everyone through the important tasks & dates. I'd use a Gantt chart but keep fairly high level, I'd add the real detail later by doing it collaboratively with the client's project manager (if they have one). Walking everyone through the plan is also a good opportunity for your audience to spot early issues, things that you might have missed.
4. Reporting Progress Agree up front how you're going to report progress. It might be a weekly phone call and a fortnightly or monthly written report based on a standard template. On a software development project you'll probably want to sit people down every few weeks and show them work in progress - SCRUM and other agile development methodologies have regular 'sprint reviews'.
5. Quality I think it's worth giving this its own slot on the agenda and making a point of highlighting what specific things you'll be doing on the project to ensure 'quality'. Some of this is about 'quality criteria' (often relatively easy to measure stuff like system response times) but also about the processes around testing, who's responsible for what and what has to happen for the client to 'accept' the finished product. What's harder to define is how you're going to ensure the more subjective, design aspects of 'quality' - the stuff that's important because people use it as the basis of first impressions. It's important here to set out the right process and explain how you'll generate designs options and get feedback from reviewers.

Finally the more subtle stuff. Building the right relationships between people is at least as important as the planning, the documentation and the process. Projects work better when the 'project culture' means that people feel able to flag up issues; risk registers absolutely don't work if people are unwilling to be honest about what they think is really happening on a project. The 'kick-off' meeting is an opportunity to get people together, set the right 'tone' for the project and do some early team building.