Finding the right balance of documentation and methodology can be challenging on small projects. Here are some tips.
I have been managing small projects for some time now. Some of my project are really tiny, I’m talking about 8 hours of work max. Others can be 2 week or month-long projects. Some span several months, and then you get up into the 6 month and year plus undertakings.
As a student of project management, I have often struggled with finding the right level of planning and documentation for these various sizes of projects. Some things are obvious, as in I’m not going to go through a formal project plan and communication plan, etc. for an 8 hour project.
As a rough guideline, here is what I use:
Level 1 (Projects longer than 6 months in duration)
-Full blown project planning and documentation for whatever is appropriate to the project
Level 2 (Projects 1-6 months in duration)
-Simplified project planning document, which includes brief communications and risk plans, along with scope definition, limitations, objectives, and deliverables. Also containts a simple WBS and Gantt-style task list with dependencies, owners, estimates, and a timeline.
-Weekly status reports to stakeholders
-Project meeting agenda/minutes template – I use this to document the agenda before meetings about the project, then update it immediately after the meetings and send it out to all the stakeholders. It includes a section for decisions regarding agenda items, and a seperate section for action items.
-Project Closure report at the end which summarizes the business benefits gained and effort spent. This is a good post-mortem look at ROI. Lessons learned are also attached to this.
Level 3 (Projects 1 to 4 weeks in duration)
-Simple project request form, where the requestor fills out their definition of requirements and business justification. Since these requests are fairly simple, I normally work out the details of the requirements over the phone with the customer, and just make updates in my project documentation log (which I keep for all projects big and small)
-Weekly status reports to all stakeholders (sometimes yes, sometimes no – depends on the project)
-Project Closure Report
Level 4 (Less than 1 week)
-For this I still have the simple project request form
-Email when the deliverable (usually 1) is ready for validation, asking for approval
I keep detailed activity logs for all levels of projects, even if it’s a 2 hour job. My department has a sharepoint site set up that works really slick for this.
I find that using these guidelines, and the templates I’ve developed, really makes it easy for me to keep my ducks in a row and keep my stakeholders informed about what is going on, for any small to medium project I am managing. For more information, check out this great article by Simon Buehring which I found today and very closely matches my style for managing small projects.
This article was originally published at http://projectmanagementlearningcenter.com/.
No related posts.
{ 6 comments… read them below or add one }
Hi Josh
Here’s a scalaeble model you might like to consider; 50% of the project time should be spent on planning.
What impact do you think that would have on your 8 hour projects? Would your work time go up significantly? Would the defect rate go down? Would customers be happier or less satisfied?
Hi JoshHere’s a scalaeble model you might like to consider; 50% of the project time should be spent on planning.What impact do you think that would have on your 8 hour projects? Would your work time go up significantly? Would the defect rate go down? Would customers be happier or less satisfied?
Thank you for the comment Craig. I’ll give my 2 cents below, but feel free to add some specifics on this topic from your personal experiences too. I’d love to hear your perspective.
It may depend on the nature of the work, but projects under 8 hours that I work do not require that much planning, in my experience.
For the majority of my very small projects, planning means
(1) clarifying the requirements/objectives,
(2) identifying risks and impacts on other existing processes, and sometimes
(3) creating a simple task list depending on the complexity. Since a lot of these wouldn’t even have 3 tasks on the list, normally I don’t even bother with a template, I just write them out in my project documentation.
I don’t agree with a blanket 50% time statement. I do agree that planning is greatly underdone in most projects, especially large and complex ones. I believe the more complex the project, the greater % of time is required for planning and communication. Even at that, a % of time can only be a guideline, and it says nothing about the quality/efficiency of the planning process.
In my experience someone who is really good at planning and estimating can turn out better quality project plans in less time than most project managers. I think a set time standard can lead towards inefficient meetings and other wasted time. On my projects, I know when I’ve reached a quality plan and it’s time to execute. I rarely hold a formal meeting with an 8 hour project…quick phone conversations and adhoc conferencing where necessary work just as well if not better, and usually take much less time.
If I had to generalize an average 8 hour project of mine, I’d say my time is spent like this:
1 hour planning/communicating (20-30 minutes in the beginning, the rest scattered throughout)
.5 – 1 hour documenting
6 – 6.5 hours executing
When the complexity and length increases, I spend progressively more time planning, communicating, and documenting as a percentage of the whole.
Thank you for the comment Craig. I’ll give my 2 cents below, but feel free to add some specifics on this topic from your personal experiences too. I’d love to hear your perspective.It may depend on the nature of the work, but projects under 8 hours that I work do not require that much planning, in my experience.For the majority of my very small projects, planning means (1) clarifying the requirements/objectives, (2) identifying risks and impacts on other existing processes, and sometimes (3) creating a simple task list depending on the complexity. Since a lot of these wouldn’t even have 3 tasks on the list, normally I don’t even bother with a template, I just write them out in my project documentation.I don’t agree with a blanket 50% time statement. I do agree that planning is greatly underdone in most projects, especially large and complex ones. I believe the more complex the project, the greater % of time is required for planning and communication. Even at that, a % of time can only be a guideline, and it says nothing about the quality/efficiency of the planning process.In my experience someone who is really good at planning and estimating can turn out better quality project plans in less time than most project managers. I think a set time standard can lead towards inefficient meetings and other wasted time. On my projects, I know when I’ve reached a quality plan and it’s time to execute. I rarely hold a formal meeting with an 8 hour project…quick phone conversations and adhoc conferencing where necessary work just as well if not better, and usually take much less time.If I had to generalize an average 8 hour project of mine, I’d say my time is spent like this:1 hour planning/communicating (20-30 minutes in the beginning, the rest scattered throughout).5 – 1 hour documenting6 – 6.5 hours executingWhen the complexity and length increases, I spend progressively more time planning, communicating, and documenting as a percentage of the whole.
Thanks Josh.
I threw out the 50% as a straw man – but your point is true that the more complex and more stakeholders the more planning is needed.
Good project management processes are one other way of reducing planning overhead. if everyone knows their role and their deliverables as a result of a defined process it can cut down project planning work also.
My view is that you are using a process (albeit an informal one) and that’s why you get though the work with only an hour or so planning.
Cheers
Thanks Josh.I threw out the 50% as a straw man – but your point is true that the more complex and more stakeholders the more planning is needed.Good project management processes are one other way of reducing planning overhead. if everyone knows their role and their deliverables as a result of a defined process it can cut down project planning work also.My view is that you are using a process (albeit an informal one) and that’s why you get though the work with only an hour or so planning.Cheers