The above question is one that many people have posed to me. On big projects it is obvious that the full gambit of project management methods yields benefits that are readily justified. However, on smaller projects, the overhead can become larger than the benefit. How do you solve this dichotomy?
As with all things in life, a small amount of pragmatism goes a long way when delivering your projects. There is no doubt that when delivering large projects, a very structured process driven approach is required. However, not all of this is necessary or beneficial for smaller projects.
Let’s take at look at the essentials for small projects and assume that for larger projects, everything discussed is relevant. By small project, I am referring to a project that is led by one person, perhaps full-time, perhaps not. They have a budget of anywhere from hundreds of dollars, all the way up to say $100,000.
The project amount is a little sensitive, as what is a small amount of money for one person or company, could be a large number for another. Therefore, let’s accept $100,000 as the budgetary ceiling of a small project. You can adjust this number up or down for our own circumstances.
The key elements of a small project will remain as:
- Project Brief/Charter document.
- Scope of Work statement.
- Work Breakdown Structure
- Project Schedule.
- Basis of Estimate.
- Resource Plan.
- A simple dashboard for monitoring progress to plan.
Let’s discuss each in turn so that we have a common understanding of each and what is needed for small projects.
The project brief is as per normal, regardless of project size. It should be approved by whoever approves the release of funds. On smaller projects, it is unlikely that you will have a project sponsor or a governance team. However, it is still very important to ensure that there is buy in from key funders of the project for the direction that you are taking it. Hence an approved project brief is essential. Another key feature of the project brief is that it defines success in terms of the timeline for execution, the money available, the key scope/deliverables and finally, the quality expectations.
Next you need to develop a statement of work outlining the details of the work that needs to be completed to deliver the requirements as stated in the project brief. The scope of work document will be developed in parallel with the Work Breakdown Structure (WBS). The more detail the better, but at some point you do need to get on with the execution.
From the WBS and statement of work, you can then derive a budget estimate and resource plan. Both of these elements are essential for small projects as funding will typically be tight and you will not have any easy opportunities to recover from overruns or poor estimation. You may even find that you need to revisit the intended scope and identify areas that are non-essential. A decision can be made upfront then to either remove these, or only execute if sufficient funds are available after all other scope elements are delivered. The resource plan is essential, as you will need to secure the resource. Since your work scope is small, the work may not always attract the people who you want to execute it. However, the better defined and planned it is, the greater your chances of attracting the right people to work with you on delivering it.
Now you have the key elements to build a schedule, another key tool for successfully delivering small projects. Take your WBS and statement of work to build out the tasks that need to be executed and the durations that you are allowing. Then apply the resources as per the budget and resource plan. Now add in the sequence of execution. Finally, check to see if there is any . If there is, then resolve this by either extending the timeline or possibly adding resources. As you are dealing with a small project, additional resources are unlikely to be the most viable option, so it will either be extended work hours or timeline. I am a great believer in using a scheduling tool as opposed to plugging tasks into an excel spreadsheet. The reason for this is because with scheduling tools, you follow a system of:
- Identifying the tasks
- Identifying the durations
- Identify the resources, including when and how much work
- Identify the sequence of events
- Resolving resource conflicts
- And then saving a baseline to commit the team to and measure against
And finally, you need an accountability partner. A means of keeping yourself honest with respect to your plan. A project dashboard. This can be as simple as the marked up schedule, highlighting the key activities and their status with a simple red, orange and green colour coding. On small projects, I would urge you to use the project schedule to generate the dashboard and focus upon
- Variance report
- Late trending activities – late starting and late finishing
- Critical path reviews
- Resource impacts of delays
I am very interested in your views on this topic, which I feel is very relevant but not discussed often enough or in enough detail.