I wrote an article last month about using PICK charts to select which projects could be worked on. One of the categories was projects that are difficult to do with low benefit, and the recommendation was to stop working on these projects before they become too time-consuming. A reader left a comment asking what the criteria would be for identifying this sort of project, so here are some tips for spotting the kind of project that would fall into this category.

Difficult to do, low benefit

There are two main criteria for determining whether you shouldn’t work on a project at all: it’s difficult to do and it would give you a low return on that investment.

Difficult to do

Here are some things to look out for when assessing whether a project is going to be difficult to do:

- Overambitious timescales such as fixed dates over a very short horizon.

- Hardly any money available to complete the project and your estimates show you will need more funds than will be given to you.

- No team members available to work on the project, or those that are available don’t have the right skillset.

- Lots of unique or challenging features (although in itself, this isn’t a reason to cancel a project as most projects have some degree of novelty to them!).

The project is challenging and difficult to do

- Stakeholders who have differing views about what the project should be delivering (again, this alone isn’t a reason not to do it as you can work with stakeholders to assess their position and align their thoughts in many situations).

- Being asked to manage a project that is outside your area of expertise or skill (you could instead recommend that someone else manages it rather than kill the project outright).

- Unrealistic quality targets.

- Unclear scope, requirements, sponsorship or any other areas of vagueness.

A combination of these factors and you can probably think up others, contribute to making a project difficult to do. However, just because a project is difficult to do doesn’t automatically mean that you shouldn’t bother with it. The other factor to consider is whether you’ll get a decent return for your investment, both in terms of time and money.

Low benefit

Some projects simply won’t deliver very much. You’ll probably be able to tell easily which projects won’t achieve massive organizational benefits, but here are some pointers to look out for.

- Low financial return – check the business case to see what the financial projections are.

- Negligible improvement to business processes – some projects may aim to make an improvement on processes by streamlining or implementing continuous improvement suggestions, but make sure that those being implemented are actually worth the time and effort it will take to do them.

- Little or no time-saving.

- Little or no cost saving, for example, implementing a project to save money on each new insurance policy sold, but actually, the cost saving per policy is less than a penny.

- Little or no improvement in quality standards.

In fact, almost anything that can be a project benefit could be delivered in such small quantities as to not make it worthwhile finishing (or starting) the project at all. Sometimes a combination of small benefits in lots of different areas add up to make the project worthwhile, so you could argue that cumulative benefit is what matters.

Low benefit is bad for the project

All of these criteria are subjective. What is a ‘negligible’ improvement to you might actually make a massive difference to the life of a software user. What’s a low financial return on paper might turn out to be something very positive with some creative marketing, or the first step in preparing for a larger, more lucrative initiative.

Of course, some difficult to do, low benefit projects are absolutely essential and may form part of regulatory requirements or something like that (in which case, I suppose you could argue that they don’t have low benefit, they have a critical benefit in the form of compliance). And managers will always have their pet projects. There are also projects that appear to have low benefit to the organisation but actually, they have a substantial benefit – it’s just that you don’t know about it or perhaps understand it. So before you recommend that a project is canceled or not even started, make sure that you appreciate the organisational politics behind it and the true benefits that it could deliver for the business.

The point is that if you have a choice of projects in the portfolio, you should prioritise what to work on. Having all the project management resources tied up working on difficult projects that don’t deliver a great return is not a productive use of your team. Instead, think about spreading out the projects so that some that deliver high benefits or that are easier to do and worth the return are also being worked on at the same time.

There’s nothing wrong with working on difficult projects that don’t have many benefits, as long as the whole organisational portfolio is balanced and you are confident that overall you are delivering the right kind of benefits at the right speed to the business. The purpose of a PICK chart, or any other way of categorising projects and putting them in an order for project teams to work on, is that you think critically about the workload and make sensible decisions based on data, instead of working on a gut reaction or on the projects for whichever stakeholder shouts the loudest at the time.