Some thoughts on digital project management

Inspired by be more digital‘s post on Simple project management here are some of my far less useful thoughts on managing digital projects.

Why is digital project management different from non-digital project management?

Because the Internet changed everything. It changed almost every aspect of our lives, it changed how organisations run, and it changed the way we think. Internet-era ways of working from Public Digital and the Digital Design Principles from CAST have lots in common (including a move away from project-orientated thinking, but more of that below). A few of the principles that change how we approach project management from a digital mindset are:

  • User first – Digital projects should ‘start with user needs, and keep them involved’, ‘design for user needs, not organisational convenience’, ’embed user research’, and understand how ’emerging technology may alter or create behaviours’.
  • Test and learn – Digital projects should ‘Start small and optimise for iteration’, ‘Take small steps and learn as you go’, and ‘Make things open; it makes things better’.
  • Safe, secure, private, accessible and sustainable – Digital projects need to understand the opportunities, and risks that being online brings. This includes, ‘Be inclusive’, ‘think about privacy and security’, ‘build for sustainability’, and ‘Recognise the duty of care you have to users, and to the data you hold about them’,

Whether the project work is digital, such as building a new website, or not, the project can and should be managed using these kinds of modern principles and practices. It achieves better things for the people that use what the project delivers.

Does it need to be a project?

Is the work you intend to undertake really a project or is it just what you do packaged as a project?

  • Will it have a deadline for completion that is external to the work? – Not just a date that senior management teams want it finished by but a date where something else is going to happen that will fail is the project isn’t completed on time.
  • Will this work have a separate budget from other work? – Not just a line on an internal budget sheet but actually a specific and dedicated budget, perhaps from a funder who expects this project to be delivered using the funds.
  • Will it have people dedicated to working on it (maybe even, if you’re lucky, as their only priority)? – Not people doing this work as part of their usual day job but either this is all they work on or it is very clearly recognised that they are working on this in addition to their day jobs.

If you’ve got three No’s it probably means the work you want to do either isn’t a project or is a project in name only. Three Yes’s means you should probably be approaching the work as a project. Why does it matter? Because, even though all work is fundamentally about these three things: time, money and people’s knowledge and efforts, a project ties them together more tightly and has extra pressure on all three.

What are you managing?

There is a universal law of projects; there is always too much to do in too little time. And there are really only three ways to deal with it:

  • Reduce what work you do to fit it to the time available,
  • Increase the time available to fit the work you want to do, or
  • Increase the capacity and capability of people working on the project.

Actually, in reality, a flexible shifting of all three is most likely to help a project be successful. It might be seventy or so years old, but the iron triangle of project management represents these three things as Scope, Time and Cost. It says that:

  • The quality of work is constrained by the project’s budget, deadlines and scope.
  • The project manager can trade between constraints.
  • Changes in one constraint necessitate changes in others to compensate or quality will suffer.

‘Quality’ is at the centre of the triangle. A project that is delivered on time, on budget and scope, is considered of high quality. A project that is late, over budget, or doesn’t deliver what it should is considered of lower quality. Project management is about managing the quality of the project. It is done through managing the scope of the work, the available budget and the time and skills people have, but project management is much more then just task management.

Managing the work

How do you prioritise project work?

You shouldn’t. All of the work that needs to be delivered in a project is the work that need to be delivered. Using Must, Should, Could (MoSCoW), for example, as a means of prioritising the bits of work introduces more uncertainty than it brings clarity. “What do you mean by we ‘should’ do this piece of work? Are we doing it or not?”. There shouldn’t be any uncertainty about the deliverables.

Prioritisation is often used as a proxy to avoid having the difficult conversation about scope, time and people, but all it does is cloud the issues and take focus away from delivering the project. Keep it simple. The project work is all of the work, and all of it is important (if it isn’t important why is it even part of the project). If you can’t deliver it all, for whatever reason, have the conversations that lead to solutions.

Working in phases

Phasing project work is sometimes seen as a means of deprioritising some work. “We’ll do it in phase 2” sometimes means some non-specific future that may or may not occur. If that’s the case, let it go and focus on delivering the current project. If the project is actually broken into phases then you need a means of deciding which work to do in each phase. Assuming that each phase corresponds to work being released to users, then the work should be sliced by what will be most valuable to the people who are going to be using it. One thing finished and delivered in a phase is better than two half finished things over two phases.

Managing time

Is the project on schedule?

All project schedules are a guess. Some guesses are better than others, and having some sense of when the project will finish is important (as I said above, what usually makes projects different from other work is the added pressure which often isn’t sustainable for long uncertain periods). Sometimes the ‘is the project on schedule?’ question is more often a reporting problem-to-solve than it is a scheduling problem. Because no one ever really knows whether a project is on schedule at any point in time until it’s delivered, this question is really asking how confident are we that it will be delivered on time. How that confidence is communicated is more fundamental than answering schedule questions.

Managing people

Do the people have the right capabilities and capacity?

For a project manager, managing people isn’t about telling people what to do, it’s about ensuring the project team have the necessary skills, knowledge and experience to be able to do the work required in the project, and that the team has enough time to do all the things. This is often the hardest part of project management, which is why the easier parts of managing scope and schedule are often focused on instead. The people involved in a project are the greatest factor in the quality of the project being delivered, give them the consideration they need.

Good digital project management not only puts users first, it also puts the people on the project team ahead of scope and schedule. (Tweet this)

Prioritising those side-projects you started

Prolific project starter? Yeah, me too. Lots started, hardly any finished. How do you prioritise which side-projects to work on?

Here are some options for picking from unfinished projects.

By potential

Pick the project that has the greatest chance of success.

If you started a project from a random idea but didn’t give any thought to who the audience is, what problem it might solve or opportunity it might create, or how to maintain the project, then it might not have a high chance of success. But if you have a project that has the potential to be successful, perhaps because its similar to other projects you’ve done or because it follows a proven approach, then pick that one to work on.

By need and impact

Pick the project that solves a problem for you or someone else.

Comparing projects by which is going to have the most impact and/or the least effort might help you pick which projects to prioritise. Projects that might help other people, teach them useful things, help them connect with others, etc., could be prioritised over more whimsical projects that are just fun things to do.

By excitement

Pick the project that interests you the most.

If an idea excites you it’s probably have more motivation to work on it (and maybe even finish it). Follow your heart.

By random selection

Pick a project by rolling a dice

Avoid choosing by letting random selection do the work. If all or your projects are equal to you and it doesn’t really matter which you work on, you might as well just pick any.

By divination

Pick the project that you’ve seen a sign for.

Did someone mention something on Twitter that relates to a project you started? Maybe it’s a sign that you should get back to work on that project (some people call this market validation).

By most finished

Pick the project that is closest to being finished.

Work on the project that is closest to being finished, even if it isn’t the most exciting or has the most potential, because finishing might teach you something and feel good.

Let them go

You don’t have to finish any of them.

It is completely ok to start something because you’re interested in it, and not finish it. Leave all those unfinished projects and move onto something else.

But if you just keep starting more projects, it doesn’t matter how you prioritise them, you’ll never finish them all. So, maybe you need to think about why you start and not finish?

More ideas than time

If you have more ideas than you have time to work on projects, accept it and share those ideas with others so they can either pick up the project or rework the idea (there’s another idea for a project).

No end in sight

Maybe part of the problem is that you don’t see an end point for the project. Thinking of starting a newsletter? Do you really want to have to write something of high enough quality to send to your subscribers every week? Want to build a website? Do you really want to be maintaining it and adding content for the next ten years. Perhaps not wanting to maintain it stops you from shipping it.

Starting is fun

Maybe it’s the starting of projects that is the fun bit. The creative exploration and discovery of starting something new is what you enjoy. If that’s the case, then the measure of success for you isn’t finishing.

Don’t mystify projects with metaphors 

I think communication about projects should be as clear, simple, and as easy to understand as possible.

But I hear Project Management is referred to as ‘Air Traffic Control’, with Project Leads called the ‘Pilots’ of their projects and them trying to ‘land’ their ‘in-flight’ projects.

Metaphors can be used effectively in communication to draw parallels with everyday experience and create familiarity but this relies on the metaphor that is used being something everyone is already familiar with. Referring to projects as planes, the person leading the project as a pilot, and the project control process as air traffic control doesn’t achieve this, it just adds a layer of confusing language. Using metaphors to mystify the process of project delivery adds no value to the projects.

If you tell me that the project is ‘in progress’ I have a clear idea of what that means. If you tell me that the project is ‘in-flight’ I have to filter the metaphor through my understanding of what it could mean to reach the conclusion that actually the project is ‘in progress’ but I’m still not sure that I have the correct conclusion.

Keep it simple and so obvious that no one has to think about what is meant by the language being used in order to understand what is being said.

Using Trello for task and project management

We use Trello for all of our task and project management. It gives us a view of everything that we’re doing, have done, or need to do from big projects to the smallest task.

Flexibility beats consistency

The most important thing to understand and accept about Trello is the flexibility of what a card, a list and a board mean to you. There is a tendency to formalise Trello by, for example, making a board represent a team or business area, making lists represent projects that team is working on, and cards represent features or tasks that are part of the project. Or think to yourself that lists need to be steps in a process such as To Do, Doing, Done, and as each of those lists as representing a state that the cards step through as part of the workflow. This is wrong. Don’t do it.

The strength of Trello is that lists and cards can represent all kinds of things, even on the same board. One list could be for all outstanding tasks with the cards as each task, another list could be for all projects with the cards representing each project, and if you need to, you can create another list for a specific project, add cards to it whilst the project is live and delete the list once all the cards have been moved to the Completed list. This flexibility of what the various elements in Trello represent to you is it’s strength as a system. It allows something like a project to easily move between a micro and macro level depending on it’s complexity, how much of a priority it is for the team, or how diverse the work required will be. It’s important to accept this fluidity of what represents what in order to use Trello to its best.

Tools and Workflows

There are four parts to our workflow for using Trello. We have a single Trello board, use email to create cards, ifttt to create recurring cards, and butler bot to automate jobs.

Trello Boards, Lists and Cards

Trello Boards, Lists and Cards


We use a single Board so that everything is available to see in one place. We could have one board for tasks, another for projects, etc., etc., but that makes it difficult to see all of the work of the whole team, especially in Calendar view which only shows an individual board.

We only have a few Lists. One is a backlog of ideas we might do one day, another is all our tasks, and three others are Queued Projects, Current Projects, and then Completed, which is where all cards eventually end up.

We have lots and lots of Cards. As cards are easily moved between lists they have an easy flexibility about them, and we like flexibility. A card can represent an idea, a task, or an entire project. So, we might collect idea on separate cards and then find that a few of those cards are related and can be grouped together to make a piece of work, so then the details on all those cards might become a checklist on another card and those original idea cards get moved to the Completed list.

Each card has a Description, an area of text near the title of the card. We use the description to record anything that you might want to find again and again such as a link to the Google Doc of the project requirements.

Comments are a good way to keep track of the state of a project without having to write a formal status update. When something changes in whatever that card represents its easy to just add a quick note about it or copy and paste an email.

Checklists are another way of keeping track of and showing the current state of a card. If the list has ten items and six of them are ticked then it’s easy to see that the card is sixty percent complete. Again, the tendency to try to formalise Trello and say Checklists are for this and Comments are for that takes away the flexibility.

Using IFTTT to create recurring cards

Using IFTTT to create recurring cards


We have a number of tasks that have to be completed every day, week of month. We don’t want to have to manually create all of cards ahead of time or have to remember to create them when they are due. So, we use IFTTT and have a number of applets that creates cards on schedule, assign members and set a due date and time.

ButlerBot to automate jobs

ButlerBot to automate jobs


Butler bot does a few different things for us. If someone is mentioned in a card it adds them as a member. Every day it counts the number of cards in our task list to tell us how much work is outstanding. And when a card is moved to the completed list it changes the date to today. Using ButlerBot for these kinds of regularly occurring jobs that are part of administering any system says time and ensures consistency. ButlerBot doesn’t forget to do things.

Email to create cards

Email to create cards


Sometimes being able to send a quick email to your Trello board to create a card is easier than actually going to Trello to do it. Trello understands using @membersname in the subject and assigns the card to that member, but it requires everyone to remember everyone else’s user name. We get around this by using ButlerBot to look for cards with each team members name and then assign that member to that card. Adding labels works in a similar way, just include #reporting in the subject line of the email and Trello will assign that label to the card. Adding cards by email falls short of being about to assign a due date to the card but again this can be handled by asking ButlerBot to look for words like ‘today’ and changing to due date to today’s date.

This combination of using a really flexible tool like Trello, the usability of being able to and cards by sending an email, and simplicity of using services like IFTTT and ButlerBot to automate jobs makes Trello a great way to manage all kinds of tasks and projects, and provide an overview of everything in one place.

Transitioning from Project to BAU

Running a project is easy. There’s a methodology for it; write the business case, get the budget, draw up the plan, do the work, etc., and at some point the project comes to an end. That’s the definition of a project, it has a limited time span and then its complete.

But after the project comes the process of transitioning into business as usual work. This requires planning too. It’s almost a project in it’s own right, except it isn’t because there isn’t an agreed methodology to guide it. So how to approach it? Here are a few things I think need to be considered:

1. Understand who, what, where, and when the BAU work is going to touch.

Does the new BAU work result in a change to the working practice of someone in the Finance department? Does it only have an impact on a Monday when some reports are being written? Is the new income being captured in a particular csv file transfer? It’s only after the project has been implemented that the effects can really be unearthed.

2. Communicate why

Everyone involved needs to understand why the project happened, why the transition needs to align all the BAU practices, and. Just as communication is important in a project, it’s important in managing a transition.

3. Develop new processes and practices together

Help the people affected to develop new processes and practices to account for the changes. It is important that these people are helped in this as they won’t necessarily understand the project that drove the need for the changes and so could risk creating a new process that doesn’t exactly match what is needed. And of course, working with people in other departments helps to break down silos.

It would be easy to say that all of these things should be thought of as part of the initial project but discovering and understanding all the potential impacts requires developing an understanding of how lots of existing business processes operate, and this would shift the focus of the project away from delivery. So, I do think that the transition should be thought of separately from the project, and probably after the project when as many of the impacts and implications have become visible. Then, as the business evolves and more projects are delivered, it should become easier to go through this process of transitioning the project work to BAU.