• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Ben Barden

Product management and process tips

  • Ben Barden
  • Home
  • Music
  • Blog highlights
  • About
You are here: Home / Archives for Project management

Project management

10th April 2021 by Ben Barden

How many projects should a team work on at a time?

I recently posted on LinkedIn, asking for suggestions for post ideas. This one comes from James Nowell:

I would love to know what your thoughts are around the maximum number of projects a team should be working on at any point in time. The ideal number is one for pure focus time however I don’t see that as realistic in an agile, fast changing world. What do you think is optimal?

In my view, it’s not so much about a specific number, but about how your pipeline of work is managed. However, I’ll come back to numbers a bit later on.

Give teams an entry point, or first point of contact

Your first goal should be to make sure there’s a logical and consistent entry point to the team – often a manager or a triager – so that new work requests are given some kind of assessment.

This person is the first point of contact for work coming to the team.

Teams can work on many things at once – but as time is precious and you probably have a backlog you’ll never reach the end of, it’s essential to prioritise.

Why a contact person is beneficial

Without checks on new work coming into the team, a team can quickly become overwhelmed.

It’s easy to say “yes” to every request. It’s easy to get distracted by the latest shiny thing – whether it’s a cool technical tool, or simply a bloody good idea from one of your stakeholders.

But if you try to accommodate every request, or you keep getting distracted by new things, the output of the team will grind to a halt.

First line of defence

The contact person – let’s call them the triager – is essentially a first line of defence, to protect the team from interruptions – as it will take longer to complete a task if you keep context-switching than if you do the task from start to finish.

The triager can also be the face of the team and give requestors a consistent message about what work can be taken on.

It’s fine to say no to things. It’s also fine to say yes, but not until projects A, B and C are done.

It’s important to watch out for the type of work that should jump the queue. A request could present a big benefit to the business. There might be some kind of legal deadline you need to meet, or a project that will unblock some other work.

A good, collaborative relationship

It’s vital for the triager to have a good relationship with the team, which means not accepting every request and telling the team they just need to do it.

The triager should know enough about the work the team is doing, so that they are doing more than passing information back and forth. If they don’t know enough, they can learn about what the team does.

Being able to answer questions about whether something is practical can be useful too. But it’s not essential for all teams.

The triager role works best if they can collaborate with the team to find out how they can be helpful and useful, and not simply add an extra layer of bureaucracy to the process.

Getting organised

Once you have a contact person, the next thing to look at is how to organise the work you do want to do, and spread it around the team.

The target number of “how many projects should we work on” has a cop-out answer here – “it depends” – but it really does. For each project, or block of related tasks, consider the following:

  1. Is it important for everyone to understand the work that’s being done? For projects that will deliver something that becomes central to a lot of your future work, you may want to get everyone working on the project – or at least set some time aside to talk through what’s happening, whether that’s before/during/after the work is done.
  2. How many people have the expertise to do the work? If one person is an expert, you’re definitely going to need them involved. It could be worthwhile to share their knowledge around. But if you have, say, 6 people in the team and only 1 has the knowledge to do most of the work on a project, it might be better to get 1 or 2 other people to learn alongside the expert, and have the other 3 people working on other things in parallel. They can always pick up the skills later.
  3. Is there enough work to share across the whole team? If you have a big team and not a lot of distinct work on a single project, you might not want to have the whole team working on one thing. However, you could pair people up, especially if points 1 or 2 apply.
  4. Is it possible, or practical, to do the work in parallel? You might not want to put 5 people on separate tasks if they need to be done in sequence.

There’s plenty to bear in mind with this.

How many projects should a team work on at a time?

So, what’s the maximum number of projects you can – or should – work on at a time?

In theory, the maximum number of tasks you can work on at a time is equal to the number of people in the team. But if each task is for a totally different project, that’s not really teamwork – you’ve just got a group of people each with their own tasks.

It can be really valuable for a team to “swarm” around a common goal, rather than having each person working on something totally different. It aids collaboration between team members. And I’d argue it’s better to have one thing “done” than 5 things in progress. You can read more about this in my post: Getting things done.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021

Filed Under: Productivity, Project management

14th March 2021 by Ben Barden

Practical tips for organising your backlog, from my home improvement project

For the last two weeks, I’ve had a bit of a break from blogging while moving into my new home. This week, I’d like to write about taking a backlog of work or ideas and getting them organised and ordered.

However, instead of talking about software projects, I’m going to use my recent move as the example. Since moving in, there’s lots of things I want to with the place — so it makes sense to organise these into some kind of order.

What you need:

  • Post-it notes, Sharpie pens, Whiteboard, whiteboard markers
  • Or, a suitable digital alternative

Step 1: Get the ideas written down

First, we write down everything we want to do.

Grab a stack of post-it notes and a Sharpie (per person) and start writing things down. Stick to one idea per post-it note. Keep the text brief.

You can use online tools to achieve a similar effect — particularly while we are working from home, but also if anyone in your group is working remotely.

With several people involved, you may want to timebox the task to 5–10 minutes, or you’ll have more ideas than you can realistically handle.

Step 2: Review and rank the ideas

First, read all of the items and see if they make sense. Are any of them too broad or too big?

For instance, “electrical work” would be too broad of an idea for the things I’d like to do in my flat. Instead, I can break this down into a few specific things — replace fuse box, add new plug sockets, replace socket covers, replace light fittings, and so on. Or, these could be broken down further — replace light fitting in lounge, replace pull cord in bathroom, replace light switch cover in lounge, and so on.

Look out for any duplicates and stack those together. Then, you can rank the ideas.

There are a few ways to do this. Giving each person 3–6 votes and taking the items with the most votes is fine if you don’t have dependencies, or if there’s not already a natural order — i.e. things that you want to do above anything else — or things you have to do.

You can use “MoSCoW” — i.e. Must have, Should have, Could have, Won’t have — to rank which tasks by order of importance.

Or you could do what I did and simply use High, Medium, or Low.

Step 3: Order the ideas

If you have a lot of ideas, you might not get to all of them yet. Start with the ideas with the most votes, or those that are the highest ranked.

Some things can be done in parallel, while others might have to be done before others — or you might want to push a few important things to the top. In a new home, safety is very important, but then so is heating, which might include replacing the windows, or getting new radiators. An electrician could do lots of small things in one day, but it’s probably better to focus on addressing any potential hazards before making the light switch covers look nicer.

The ranking of ideas will help, but the highest priority ideas might not be the ones you can do first. Replacing the windows in my flat is something I’d like to do right now, but there’s a lead time of a few months. The job is all booked in — but I can do other things in the meantime.

To actually write up the order, I titled up 3 columns on a whiteboard:

  • To do
  • Next up
  • In progress

For each task I’d like to do next, I’ve put them in the “Next up” column, in the order I’d like to do them. As a task gets underway, I move it to the “In progress” column. Other ideas I’d like to do soon, but which aren’t top priority, go into “To do” for the time being.

I’ve decided not to have a “Done” column — instead, when a task is done, I add it to a Google doc that lists out everything I’ve completed so far. And I’ll take the post-it note off the board at this point, freeing up space for other tasks.

You might find you have more tasks than you can fit on the board — and that’s fine — you can set them to one side for now. I’d recommend writing these up somewhere, either keeping them in the backlog of your issue tracker, or keeping a short list documented in Google Docs or Sheets.

Step 4: Keeping the board up to date

In a previous post, I explained that the Agile board should reflect reality. It’s all very well to get things in a nice order, but you need to keep the board up to date, too.

That means:

  • moving things to In progress when work starts;
  • moving things to Next up when space frees up;
  • changing the order of tasks as required;
  • adding more things to the To do column as space frees up.

While you can (and probably will!) do this in digital tools, there is a lot to be said in having a physical board. Moving a post-it between columns can feel good — seriously, try it! — I’d say it feels better than moving things around in something like Asana or Jira.

Having limited space is similar to a WIP limit, but it’s much harder to circumvent when you physically don’t have any more room for post-it notes. I guess you could get a bigger whiteboard — or a second one. I will admit to having just bought my second, although they will be used for different things.

This isn’t a particularly new or groundbreaking process, but keeping my home improvement ideas organised in this way has helped me to feel more on top of them, and to see progress being made. It’s very rewarding, and I’d recommend trying something like this for any project you do — tech or otherwise.

In 2021, I’m trying to write more regularly on my blog – hopefully one post per week. See my progress so far here: Weekly blogging in 2021

Filed Under: Agile, Product management, Project management

3rd April 2016 by Ben Barden

Redesigning City A.M. – March 2016

Summary

On 15th March 2016, we released a brand new look for cityam.com. In this post I’ll be digging into the what and why of the redesign.

[Read more…] about Redesigning City A.M. – March 2016

Filed Under: Product management, Project management Tagged With: city am, redesign, user experience

22nd March 2016 by Ben Barden

How I prioritise small requests alongside project work

Recently, I changed the way I prioritise new work requests and projects. Here’s what I’ve started doing.

Prioritising the product backlog

JIRA is our central system for development requests. There’s one project for smaller requests: the “BAU” as I call it, which is anything that takes 2 days dev time or less. Except for urgent requests, which we will drop other work to look at, anything in JIRA is allocated a business area via a custom field.

Each week, I export a list of all open tickets, filtered by area. One or two people in each area indicate their Priority 1 and Priority 2 tasks, and those go into the queue. We also prioritise our internal work, such as changes to the core product, and improvements to our technical stack.

We won’t complete all of the prioritised tasks every week – but it allows us to see what the priorities are.

I believe it’s important for all areas of the business to be included in the prioritisation process. Nobody should feel that their area is being ignored. Allowing each business owner to define their priorities can prevent this issue.

Prioritising the projects

Instead of starting yet another spreadsheet, for projects I decided to use pen and paper. I ordered a stack of 1000 plain white 5×3 record cards and a pack of Sharpies.

I started by writing one project on each card, and laying it all out on the table (literally). Staff involved in the meeting can see all the known projects, ask what they are, and identify anything that may be missing.

Once all projects are defined, we agree what’s the next priority. This makes it very clear which project will be worked on next – and also what won’t be. Showing the number of projects can make it very clear if there’s a capacity issue. There’s only so much resource, so we can’t work on every project simultaneously.

Does it work?

As this is a very new process I’m trialling, it’s too early to say how effective it is. I’ll write a follow-up post on this.

Filed Under: Product management, Project management

  • Go to page 1
  • Go to page 2
  • Go to Next Page »

Primary Sidebar

Substack

My Substack blog

Recent Posts

  • My Substack blog and newsletter
  • Review of 2022
  • How to practise good etiquette in team updates
  • How improving the Okta SMS flow would reduce support requests
  • Flexible working in 2021

Archives

Categories

Handcrafted with on the Genesis Framework