From McKinsey Insights: Bias busters: Pruning projects proactively
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.
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
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
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
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
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.
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.
I was given some advice about running projects. Just as an electrocardiogram is used for measuring abnormalities in heart rate and rhythm, this ECG helps to ensure the health of the project.
Setting clear expectations for the project, it’s time scales, budget, etc., not only prevents surprises it also gets people to support the project and not be so quick to dismiss it when things go wrong.
Communicating well and often builds confidence in the project. Providing the right kind of information at the right level via a formal means of communication, and talking about the project in an informal way are both vital for getting the message across.
Good governance is essential. And if the decision-makers have clear expectations and have been communicated to well, then they’ll be in a good position to provide good governance.
- have I set clear Expectations?
- have I got clear Communication
- have I got good Governance?
Answer “Yes”, and prevent the project from flat-lining.
Bringing together the four Digital Team Managers and three Digital Business Partners to begin to share their priority projects and get an overview of all of the work the Digital Team
Is it managing digital projects (the what)?
Is it managing projects digitally (the how)?
Or is it digitally managing digital projects (the what, how, and maybe even why)?