One of the core principles of PRINCE2 is to amend the methodology appropriate to the project requirements. In my experience this almost always means cutting it down for small, short jobs.
In the past I have advised teams and individuals a number of times on how this might look. I thought it would be worth thinking a little more formally how this works for small projects. For our purposes, lets call a small project one < 1 person-month.
Lets start with what makes a managed project as opposed to simply coding. In my very simplistic way (I’m big on simplicity) it’s just this. We need to know:
- What we intend to deliver
- How we intend to produce it
- Who needs to know about it
- What might go wrong.
Of course each of these is complex and involves lots of different areas (build, test, change management just in the producing part for example), but it seems to me that if you know those things you have a project.
So lets look at those areas and the artefacts we might need for each using three types of small project
1. A simple one person, less than one week job – maybe a POC
2. A one person, two/three week job – the kind of work you might be asked to do as a low priority, when you have time thing – perhaps an simple extension to an existing system or a simple online information system from a DB with no transformation
3. A two person two week job. Something significant but still not a major project. Perhaps a simple audit enhancement to a reporting system.
So the artefacts we need for these three levels might look like this.
And that’s it. Simple (I hope) but covers most of the bases. Obviously there will be areas missed, but they simply represent risks. What we want is to have a level of project management which is appropriate to the actual size of the project and the potential downside if things should go wrong.