Category: Project constraints

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.

5 Project Team Blockers Making Your Project Late

What project team blockers are making your project late?

There are many reasons why projects become late but often project teams are operating under severe constraints. In this article I will be looking at the typical constraints, blockers and impediments for project teams. The key here is that understanding why the teams are blocked is the first step to working out what to do to fix it.

Quick definition of a project team

But before we start let me just clarify that when I talk about a “Project team” I mean a Delivery team, software team or some sort of Engineering team. However, many of the constraints mentioned here also apply to teams that are not working in a specific project context. For example, Agile software teams may, or may not, be working on projects but may be delivering software for product roadmaps etc. these constraints will often apply to these teams too.

So, what are the typical constraints?

Common project team delivery constraints

1. Mixing Operations and Project work

I have seen this one so many times that I would say that this happens on almost every project that I work on. This is the situation where, for example, an engineering team has an operational role to support an existing set of systems. In addition to this they are also given project work to upgrade, change, or enhance these systems. Often these teams are the resident experts in a particular domain, business area or technology and so are key to the organisation.

The challenges with these teams are as follows:

  • Operations work takes priority over project work
  • Users pressurise the Operations team to fix their issues asap
  • Even non-urgent critical Operations work gets prioritised above project work
  • Operational issues come in at random and so are very hard to forecast
  • Operations issues may involve significant analysis and fault finding to find the cause of the issue before it can be resolved
  • The size and volume of the issues is hard to predict and therefore plan for

The impact here is that the team members are taken off project work to work on operations issues. This will stop your project work dead in its tracks.

The only way to resolve this is to somehow separate out the project work and operations work – they are completely incompatible activities. Operations work will always take priority so if the team is also to do project work then part of the team needs to be dedicated to that work only.

2. Too many distractions and interruptions

A similar one to the previous point is that members of the project team (normally senior, experienced people) are continually interrupted. This can take the form of:

  • “Drop ins” or people walking by someone’s desk to ask a question or put in a request
  • People emailing or messaging for information from one key person
  • The expert(s) being pulled into meetings to share their knowledge or consult on issues or challenges in other areas

This is a “Hero” culture and very common. It is much easier, and quicker, to ask the expert rather than find out yourself or ask someone with slightly less knowledge or experience.

Assuming that the expert is a key part of your project team then this will delay or stop your project work getting completed. The challenges are the same as in point 1 – it’s really hard to forecast project work timescales due to the random nature of the interruptions.

There is also another issue here that the hero culture is perpetuated as the only people that get to work on the hard challenges is the expert, the rest of the team don’t get to learn, and this makes the dependency even worse.

In order to resolve this the hero culture needs to be tackled and that will take time. You may not have much time on your project so you will have to make some first steps in this direction. The first thing I would do is: gather the project team together and discuss the issue as a team. I would then work out some ideas for tackling this problem with the team and try them out. The flip side to this of course, is that as well as getting the team better managing their interruptions; then you will also need to talk through a plan for the people that are making the interruptions – if you don’t do this part nothing will change.

3. Poor planning ahead and hitting blockers

Good project teams deliver a steady flow of completed work. Inefficient teams, who don’t plan ahead, hit problems and blockers. Sometimes they can’t see why this is happening until it is pointed out to them.

The symptoms of this are:

  • Large number of items of work in-progress at the same time (I once had a team who had over 50 items of work in-progress – err no you haven’t – 45 of them are blocked!)
  • Lots of work items started but not much being finished ie no “flow” of finished items
  • Team often run into blockers and have to stop one piece of work and start something else until the blocker is removed
  • Team often waiting for other teams to complete tasks before they can start work

The impact of this is as follows:

  • Slow progress
  • Feeling of lack of achievement as lots of blockers and not much delivered
  • Reputation for poor delivery

This is about breaking down tasks into sufficient detail, dependency management and planning ahead. The way to tackle this is to work with the project team to plan ahead. You should run regular planning sessions – the next 2-4 weeks needs to have a fairly detailed plan with dependencies and potential blockers identified and action plan to resolve. Further out than 4 weeks needs a less detailed plan – but blockers or dependencies that are big or time consuming need planning well in advance.

The aim is to start finishing things and enable better forecasting – this will have a big impact on the team as they will have greater sense of achievement and not have to stop-start and revisit things.

4. Significant new learning required as part of the project

Project teams, by definition, build new things – however some projects are delivering completely new things that have never been done before by that team or organisation, whilst other project teams might be delivering something that is very similar to what they have delivered before.

So, if there is a significant “new” element to the project that the project team has not done before then this needs to be factored into planning and forecasting. In my experience this always takes much longer than everyone estimates. Typical “new” elements might be:

  • New or unfamiliar technologies
  • New or unfamiliar business domain
  • Undocumented legacy system requiring significant understanding and translation to new business and / or technologies

All of these scenarios require the project team to allocate significant learning time to understand the problem, only then can they come up with a design and understand what the potential solutions are. It is often difficult to estimate timescales on this.

There is no short cutting this challenge on a project. One option to consider is to allocate a specific Proof of Concept or Feasibility phase to this problem. This is essentially a mini project within itself to really get to the detail of the problem, understand the requirements, solution options and delivery plan.

5. New (project) teams take time to get established

  • Recruitment of senior leaders in the team
  • Recruitment of rest of the delivery team (probably by senior leaders above)
  • Build team baseline tools and processes for delivery

It always surprises me how long it takes to establish new teams. What I mean by that is: getting to the point where the team is really in flow and delivering at a strong pace. The challenge is that many projects have to form new teams as part of the project. Getting the team up and running takes time and impacts the project timelines. Setting up new teams can include some or all of the following:

Setting up a brand-new project team is a hugely time-consuming process and only once a team has been running for some time can you even start to consider planning and forecasting work items and project plans. If building a new team is part of the project then you need to discuss this with your project sponsor and stakeholders so that they are really clear that this will take time to setup.

Understanding team constraints is the first step to fixing blockers

So, in this article we have looked at some of the typical constraints, blockers and impediments for project teams. The key here is that understanding why the teams are blocked is the first step to working out what to do to fix it.

Chris Wilson

%d bloggers like this: