Category: Project Governance

Why Small Projects Take Too Long

Small projects are easy right?

People tend to think that “small” projects equals “simple” projects – but in my experience small projects can be really frustrating to manage and consume a disproportionate amount of time to their size.

Project Managers often need to be quite tenacious and really exercise all of their skills and experience to get them finished. They will often be juggling multiple small projects at the same time or together with a larger project.

In this article I explore some of the constraints on small projects. I also outline some typical types of small project, how they come about, the associated challenges and some strategies for running them.

Note – it should be said, at this point, that size is relative and small in one organization doesn’t necessarily translate directly to small in another organization so you will need to adapt this information to your own organization.

Small project constraints are the same as any other project

All projects operate within a set of constraints in terms of the scope that can be delivered in some timescale to some agreed budget.

Small projects will typically have to deliver a limited scope, but they may have constraints on budget which could manifest itself as follows:

  • Project Management time available is small (say 1-2 days per week)
  • Resources or delivery team limitations such as time available or ability to increase team size or capacity

Limiting the time available on a small project can actually be beneficial as we will see later. This assumes that there are less constraints on budget and scope.

There are also other constraints that impact small projects.

Small projects are often “lower priority” projects

Small projects can often be lower priority projects for the delivery team. This may be fine if the project gradually works its way up the priority list and gets completed as planned. However, this can become problematic if it gets bumped down the priority list repeatedly.

The impact of this could be on other dependent activities and extended timelines for your project.

The Project Manager needs to address this with whoever manages the delivery team and also seek help to increase the priority via the Project Board.

Low priority extends timelines so use time as a project driver

A project with a low priority will mean that time constraints have been lowered, removed or become flexible. Whilst having unrealistic timelines in a project can be a bad thing, having a project with flexible or changing time constraints can also be a bad thing too.

Having a time driver can be really beneficial as a focus for getting a small project done and out of the way.

The Project Manager should do all they can to raise the issue with their Project Board for assistance and also negotiate with whoever prioritises the work in project delivery teams. 

Some typical small projects

There are a number of other types of projects that present challenges for the Project Manager. They are often associated with small projects.

The “unloved essential” project

This type of project may be seen as essential by the Project Sponsor but no-one else involved is bought into it or wants to do it. The Sponsor normally has a good business reason for doing the project but there is a disconnect between the technical delivery team and business viewpoints.

Sometimes you also get a disconnect between the people managing the delivery team and the sponsor.

What you have here is a disagreement in the priority level. This can be even harder if the disagreement is not explicit ie people are saying one thing and doing another – so they may appear to be supporting the project but in reality, they are not backing it. This rubs off on the delivery team and the result is slow delivery, lack of focus and often lots of moaning from the delivery team as they would rather be doing work that they see as higher priority (and so do their managers).

The Project Manager needs to get hold of this and try as many of these as possible:

  • Meet with the Sponsor, Key Stakeholders and Managers of the delivery team to discuss and clarify the priority of the project
  • Question the need to do the project and get it stopped if possible
  • Cut scope to the bare minimum
  • Push to get the project finished and out of the way
  • Communicate any agreements to all involved in the project

The “post-launch phase” project

This type of small project could be a mopping up phase, final phase or decommissioning phase of a much bigger project that has been running for a long time. Typically, the main launch has been completed but there is still a body of work to complete. Often these types of projects are handed over to more junior project managers to complete.

These can often be quite good projects to run but the problem here is that sometimes the urgency element has gone out of the project so getting traction can be difficult.

Another challenge with decommissioning type projects is that they can actually be quite complex and involved to unpick from a technical level.

Another challenge with these types of project is that they are often handed over mid-flight so this process can be a bit messy.

It is really important for the Project Manager to either setup the project properly from scratch or do a project audit to establish the real status of the project and set it up for success. I cover this later in the article.

The “must do but tricky” project

These types of project can be challenging because although the work required may appear to be small in fact it may be tricky, boring, time consuming or just really difficult to do. So, if it is also lower down the priority list too then project teams tend to put it off as long as possible in preference for other more straight forward work.

This can obviously delay the project.

The Project Manager needs to tackle this head on and urge the team to take on the challenge, support them as much as possible, make tea, offer cake or do whatever it takes to get the project done.

The small “nearly finished” project

I’ve been handed a few of these small projects in my time – the ones that I could run in my “spare time” – one of them took nearly 2 years to finish. The Project Manager is taking over an in-flight project, so they need to get a handle on it quickly.

The problem here is that someone has perceived the project as small and nearly finished. You need to go in with your eyes open and make your own assessment of what the true position is.

One really effective approach is to run a really quick project audit – I have outlined how to do this in a later section.

The “important low priority” project

These ones are always a challenge to run. Typically the organization really wants to do the project. They may even have to do the project to reduce business risk, comply with some regulations or some other important reason. However – the importance and priority never really quite makes it far enough up the priority list and so gets pushed back and back. Sometimes the project may have been started and some elements finished but has since sat on the shelf to come back to later.

The only real way to tackle these types of project is the same as the “unloved essential project” ie by trying as many of these as possible:

  • Meet with the Sponsor, Key Stakeholders and Managers of the delivery team to discuss and clarify the priority of the project
  • Question the need to do the project and get it stopped if possible
  • Cut scope to the bare minimum
  • Push to get the project finished and out of the way
  • Communicate any agreements to all involved in the project

How to tackle small projects

There are many ways to tackle small projects, but the key is to run them as you would any other project.

Light weight Project Management process

All projects benefit from using a repeatable Project Management framework or process. This is no different for small projects – it simply means that some of the processes and governance put in place will need to be simplified and pared back to a minimum, but still effective, level.

Starting a small project from scratch

Using a standard planning and startup process will really help the project. This should be documented. The project startup framework should cover the following:

  • Identifying the Project Sponsor and Key Stakeholders
  • Understanding the project requirements, scope and deliverables
  • Defining the project benefits and criteria for success
  • Identifying and establishing the project delivery teams and any suppliers
  • Agreeing the delivery approach, timelines and delivery schedule
  • Setting up a simple governance process

I covered this in a separate post How To Start Your Project Faster.

Once the project is planned and approved to start then the project needs to be managed closely but efficiently.

Taking over projects in mid-flight

Some of the small projects outlined above had the scenario where the project was handed over to someone else in mid-flight – this can be a bit messy but again the project needs to be established or re-established on a solid footing.

If you are taking over the project you need to understand where we are on the project. One method is to run through the Project startup framework and fill out a standard plan to understand the project in its entirety. This may be just for the benefit of the Project Manager’s understanding, but it is really effective for getting to grips on what the project is all about.

Project audit

Another method effective method is to run a project audit.

Asking lots of questions like these can help to understand the true picture:

  • What is the scope of the project?
  • What has been delivered?
  • What is there left to deliver?
  • When is this forecasted to be complete?
  • Do we think we are going to be able to deliver this?
  • Is the team on track to deliver?
  • Are there any issues, blockers or risks to the delivery timeline?
  • What is the project budget, how much has been used so far and is it enough to complete the project?

Simple project governance

On small projects it is essential to run a simple light weight governance process. This will help to tackle the challenges around project prioritization and keep everyone up to date on the challenges of the project.  The minimum governance I would run would be this:

  • Regular Project Report:
    • Weekly or fortnightly (but always done)
    • Issued to Sponsor and key Stakeholders via email
    • Includes Progress update against plan and summary of risks and issues
    • One-page summary should be the max required here
  • Project Board:
    • Monthly if possible
    • With Sponsor and key Stakeholders
    • Progress update against plan, and budget since last meeting
    • Summary of risks and issues and any help needed
    • Decisions to be made
    • A few simple slides should suffice for this

Small projects are fun

As we have seen running small projects has its challenges. However, if they are run in the same manner as any other project, but with a lighter weight set of processes, they can be run quite smoothly and effectively. They can also be quite fun to run as you can run a number of them together and you get the satisfaction of finishing things and moving onto the next project.

How To Write Better Project Status Reports

As a first-time Project Manager good communication is an essential skill that you need to learn quickly. All Project Managers need to be good communicators and to update their stakeholders with a regular status update in the form of a weekly project report.

Project Managers do not enjoy doing them, and they are often done quite badly, but they are an essential method of communication on projects and, if done properly, they can help the project run more smoothly.

What’s the problem with project reports?

There are a number of problems with project reports, I think.

From the Project Manager’s view point – they hate doing weekly project reports for these reasons:

  • They are time consuming to write
  • They find them difficult to write as they are trying to find something different or new to say about their project each week
  • The mere fact that they hate doing them makes them more of a chore
  • Finally – they also have a nagging suspicion that no-one actually reads them – so why put all that effort in?

From the audience viewpoint i.e. the people reading the report, I see a number of problems with weekly reports that I read every week as part of my role as a Programme Manager:

  • Report is too wordy, waffles too much, is too long and complicated to read
  • Report has too much technical jargon which is hard to penetrate or understand
  • It is hard to get to the really valuable information
  • Highlights information that is irrelevant to the audience
  • Doesn’t highlight important information or underplays its significance

So how do we improve weekly reports?

What’s the purpose of the project report?

Let’s start by looking at why we are doing the weekly project report. What purpose does it serve and what are we trying to achieve?

Communicating regularly to your project stakeholders and also keeping your project delivery team in the loop in terms of what is going on in the wider project, and what is being communicated to stakeholders is a good thing.

The weekly report is the opportunity to keep a wide group of people involved in the project up to date with what is going on in the project.

The audience for weekly report falls, broadly speaking, into three categories

  1. The business stakeholders – including management, customers and users
  2. The project governance team such as Project Management Office (PMO) or managers of the Project Manager – they are concerned with ensuring that the project is under control
  3. The Project delivery team – the team(s) working on the project day to day including suppliers. They will know quite a lot about the project progress but may not be across all the different areas of the project

I have also known Project Managers to send their weekly report to their project delivery team first for review before it is sent out to wider list of stakeholders – this is a great idea, I think.

What qualifies as good communication?

When writing the weekly project report, it is essential that you focus on what the audience want to get updated on. The content is covered in a later section but here are some guidelines:

  • Keep the information clear and to the point
  • Ensure the information is up to date and correct
  • Keep jargon to a minimum
  • Keep it brief, but not so brief that it is hard to understand – use sentences and good grammar
  • Ensure the information is relevant to the audience
  • Ensure important information is highlighted
  • Avoid repetition

How often should we do a project report?

Ideally you should be writing a project report every week. The more often the Project Manager writes it, the easier it should be to update. It is a lot to easier to remember what you did in the last week, whereas sometimes 2 weeks in a project seems like a long time to remember exactly what has been achieved. However, this is dependent on the project itself and also where you are in the project lifecycle.

Not every project is going flat out for the whole time. In some phases of the project there might not actually be much going on for a few weeks, so there might not be much to report. In this situation I would negotiate with your key stakeholders and request that you push the project report frequency out to every 2 weeks. You can always go back to weekly again when the project pace picks back up again.

In some organisations they do project reports once a month. I would question the value of that. The overhead for the Project Manager is high as this would take quite a long time to go back through the months’ worth of work to write the report. It would also be likely quite out of date.

My preference is for weekly project reporting to ensure the regular flow of information to the project stakeholders and also so that we can act quickly on any concerns, risks or issues.

How long should it take to write a project report?

I would argue that a Project Manager should be able to write a project update in 15-30 minutes. If it is taking longer than that they are spending too much time on this. There are occasions when you might need a bit longer to do an update and it will depend on the size of the project and on how busy and fast paced the project is, but I would still aim for the 15-30 minutes.

Report format and delivery method

My preference for weekly reports is a text document in MS Word, GoogleDocs or similar. This should be maximum 1-2 pages.

Sometimes a presentation type format such as MS PowerPoint or GoogleSlides is used – this is quite common particularly in projects which are part of a larger programme. The same content should be included as per next section.

Sometimes a simple email will suffice as long as it summarises the information as outlined in the next section.

My preference for distribution of the weekly report is via email – either with the file itself or a link to where the file can be found.

Don’t forget to date the files and email subject headings so that reports can be easily searched at a later date.

What should be communicated in the project report?

I have outlined a typical format for the project report below. The format may vary between organisations, but the content should be similar to that outlined below.

Weekly Report 
Project <Name>                      <Date>
What’s been achieved this week:
<approx. 3-5 bullet points>
 
What’s planned for next week:
<approx. 3-5 bullet points>
   
Main Issues:
Issue 1 – brief summary and action plan
Etc.
Key Milestones
Milestone 1, status (red, amber, green, done), and forecast date
Etc.  

Key Risks:
Risk 1 – brief summary and action plan Etc.    


When to distribute the weekly report

Reports are often issued by Project Managers at the end of the week, but this can also be dictated by what project meetings are scheduled for the week. So, the Project Report contents can be discussed in these meetings. So generally speaking, late Thursday, Friday or early Monday are the most common days I would say.

What not to communicate in a weekly project report

Clearly the weekly project report is used to communicate information about the project to a wide audience and highlight challenges, risks and issues. However, I would not use the project report to highlight new information to the audience as the first point of communication.

If you need to highlight project challenges, issues, risks, budget changes or changes to timelines I would use your regular project meetings, monthly Project Boards or one to one meetings with stakeholders to communicate this information before you put it on the weekly report.

People don’t tend to like surprises or feeling like they are the last to know about issues and challenges on the project. I have seen many mini stakeholder rebellions and extra project management calming work created because of one small sentence in a project report. The Project Manager’s role is to keep everything under control and running smoothly not create extra communications challenges – whether well intentioned or not.

Happy report writing

So you should have a set of useful tools and pointers which you can now use to produce your weekly reports more efficiently and effectively. Good luck.

Chris Wilson

%d bloggers like this: