Top-10 tricks to boost your project management skills
A guide to a tried-and-tested way for effectively managing and delivering any project (whether BI or not)
Managing projects is not an easy task. By definition, most projects involve multiple components, and often various stakeholders who all need to play a part in the overall effort. The more complex the project you’re tasked with overseeing, the more it is akin to trying to heard cats. Difficult.
I recently had to manage a complex project, which reminded me of everything I learned about this discipline while working in the top-tier consulting world. The goal was to prepare a complex package of documents for approval and sign-off by a certifier before construction works could commence for a small bricks-and-mortar project. And we only had a couple of weeks to get everything ready-to-go.
Needless to say it was stressful. And when it got really stressful, and it seemed like there is no way we would be able to hit our deadline, I just ended up instinctively relying on my trusty old project management toolkit from back in the day.
I believe this toolkit is applicable to any project, no matter how big or small it is. In fact, I know this to be the case 100%. So here it is - my top-10 tricks and best practices for managing your projects (better).
1/ Have a draft end-state in mind
This is a really important one. You need to invest some mental energy, time and effort in order to visualise for yourself what it is that you’re collectively trying to achieve in your project. Without it, you won’t be able to tell if you’re moving in the right direction, and how far off the destination you are at any given point in time.
In my project example, we received a list with ~20 items from our certifier. Some of the things on the list were pretty straightforward. But others - I had no idea what they were asking for.
For example, there was mention of inputs from a variety of engineering disciplines - mechanical, hydraulic, acoustic, fire safety. But it wasn’t very clear to me (yet) what those inputs needed to look like. Was it going to be a report from each qualified engineer? Was it a set of technical drawings? Or was it just a signature on some form? It was all a bit of a mystery at first.
And so I just picked up the phone and started calling around. In the first instance, the certifier was able to clarify some things for me. For example, fire safety consultants would need to provide assurance that the resulting project was going to comply with fire safety requirements. That gave me the initial 30% of the view. But I still had questions at a more detailed level.
And so I kept calling. One of the potential fire safety consultants explained that they would prefer to take our space designs and overlay their suggested fire safety management assets where they thought was fit best. They also told me they would likely need to fill out and sign off on an exemption form for certain parts of the regulation that wouldn’t apply in our case. And what that form would look like and what it would say.
After repeating this process on all of the items from the list of the ~20, I had a rough picture in my head of what it is we were looking to collect at the end of the effort. What’s more, because I now understood it better, I also had a rough idea of how long each item was going to take. Some of it, I was told by the providers. For others I just made my own assumptions based on most similar other items on the list, for which I had the information.
But the net result of all of this was having a pretty high-resolution view in my mind of what the package should look like once we are finished. And that helped me develop a sense of where the biggest risks were, and which items I had to pay particular attention to from our overall list. Which proved to be really valuable in the subsequent couple of weeks.
2/ Create and update a 1-page tracker
The next thing that proved invaluable was putting all my thoughts on paper in the form of a 1-pager. I used Excel, but you can use whatever is most convenient for you. I sometimes also use a small square-shaped sticky note, which forces me to be concise.
The biggest temptation you need to avoid with this trick is to jam it with too much information. You need to remember that this tracker is a management tool, not an information repository. Ideally, the fewer words that you use to describe each item on the tracker, the better. It just needs to be described in sufficient detail, so that you can later remember what it is you were talking about.
Reason why a tracker was useful for me is because life happens, and you get distracted with other tasks during the day. And before you know, you totally forget where you were with your project, and where the biggest issues were located. Having a short, simple tracker is a great way to quickly re-immerse yourself into the flow. And remind your brain where the latest priorities are located.
You can also leave notes to your (future) self in the tracker. Updates on each of the ~20 things that you are sure as hell to forget by tomorrow. Just remember not to overload it with information. Keep it short and to the point.
I usually refer to the tracker multiple times a day. In the morning, when I just get to my desk, to re-visualise the ‘battle map’ in my mind. At the end of the day, to see if there are any critical tasks that I might have forgotten to follow up on. And in-between, every few hours, as information and updates come in, or I need to see which items require a follow-up, because there hasn’t been enough movement compared to what I thought would happen.
Without a good tracker, you will lose control of the project faster than you can blink. And when you are playing the ‘quarterback’ (aka project manager) role, this can be really costly.
3/ Align people on ‘the why’
Projects are tricky mostly because they involve multiple people who need to work well together. And the natural tendency of people is to not do that too well. Everyone assumes that others are doing something they have in mind. People get irritated at each other. People forget to do their tasks, even though they are a priority for the project as a whole.
If your project is complex enough, and most high-value projects are, you should just assume that there will be friction in the way that people work together. And your job as a project manager is to reduce or mitigate the effects of that friction. To keep the harmony going as well as you can.
I find that explaining ‘the why’ is really important for this. If people don’t understand why you’re getting so worked up when they miss their commitments, it will not help you. They will just irritated at you, and might even jeopardise the project in retaliation. You need to take the time and explain to people why the overall outcome is important.
In our case, I would explain to the various project participants that we have a collective deadline that can’t be moved. And that failing to hit that deadline is going to cost a significant amount of money. And how certain participants are on critical path for others, and therefore their ability to stay on course was vitally important for the overall effort. I wasn’t picking on them when I chased them for updates. I did it because their role was critical, and they were able to better accept it once they understood the bigger picture.
4/ Put things on paper/don’t trust words
This one might be counter-intuitive and feel a bit micro-managey, but in my experience the dividends it pays outweigh these concerns.
The simple truth of life is that people often forget what they told you yesterday. Especially if they are busy. Especially if they are running multiple things in parallel, which most highly-skilled professionals do. And if you didn’t write down what they told you, it’s as if no promises have been made in the first place.
Another reason to do it is that you (yourself) will often forget what you agreed with people just a day or two ago. It just happens when you get busy. Your brain is only capable of storing a limited number of things in its short-term memory. And it’s very easy to overload your memory when you are multitasking. And then you remember nothing beyond that point.
The trick is to keep it professional. I often just drop an email or a text message after important verbal agreements or commitments have been made. You can say something along the lines of ‘I am just writing down what we agreed upon in case either of us forgets’. There were numerous times when I’ve been thankful for doing this afterwards, when I just couldn’t remember the details of what happened, especially if it was more than a day or two ago.
The other thing this habit lets you do is easier follow-ups. Let’s say some promised to produce a report for you a week ago. A couple of days before the deadline, you can forward them the old email where you documented the agreement, and tell them you’re just confirming they are still able to hit the deadline as was described in that email. And because you sent them the original email previously, they now don’t have an excuse of telling you they forgot.
It’s just one of those things that engineers possible failures out of the system. It feels redundant or intrusive when you do it. But you save yourself a lot of headaches, and your project valuable delay time, by being disciplined about documenting what everyone has committed to deliver.
5/ Follow up and ask for specific due dates
Speaking of uncomfortable things, here’s another one for you. The principle is that you can’t hold people to account if you haven’t specified the details of what they need to deliver to you.
A lot of the time, when you’re working with professionals, you don’t need to worry too much about the quality of their final deliverables. They are professionals at what they do, after all. And if the quality is lacking, you need to be more careful selecting your providers next time.
However, even with professionals, the biggest risk area tends to be around timings and deadlines. They can still deliver high quality outputs for you. It would just be later than when you assumed it would be. And if you haven’t explicitly agreed on the timings, it is almost guaranteed to happen.
One elegant way how you can do it is by saying that you need a due date from them ‘for your own planning purposes’. Then it becomes less about you not trusting that they would deliver their work, and more about them helping you manage the overall project schedule. It becomes about you managing the project and not about doubting their capabilities.
Similar to documenting the agreements as per the previous tip, it is also a good idea to write down the timelines that have been agreed. And once the timings and deliverables have been agreed, you can get off people’s backs for a while, which they tend to appreciate. Up until it’s time to follow-up and double-check they are still on track to hit the deadline, that is.
And it you didn’t explicitly agree on due dates previously, it’s really hard to know when is the right time to follow-up. So you either end up not following up enough, or over-doing it. Either case, it’s a really good way to annoy your project contributors. It’s much better to potentially annoy them once by forcing an agreement on due dates, then do it repeatedly later, or risk slipping the overall project timelines altogether.
6/ Build in buffer for errors and miscommunication
Buffers are a project manager’s best friend. Without buffers, if something goes wrong somewhere, it will most likely affect the entire project (timeline or cost). Therefore, it is very important to keep buffers in mind when thinking through the approach for your project.
In my project example, we had roughly 3 weeks to get the initial package of work delivered. Of the 3 weeks, we had roughly 1 to 1.5 weeks of buffer, in case things went wrong. And guess what happened? We consumed that buffer right upfront.
Some of the things that came up had to do with the initial misunderstandings and assumptions about who was doing what. As the result, there were things that nobody was doing. Because everyone assumed that somebody else is taking care of them.
Having a buffer helped us still stay on track overall, even though it made the back end of the 3 weeks more stressful than it needed to be. But we were very thankful for it to be that way. Better be stressed in the second half of the project, but still deliver within your timelines.
So it’s always a good idea to have buffers. If you don’t end up using them, that’s also good. Nobody minds positive surprises typically. It’s the negative ones that you should watch out for.
7/ Have plans B & C available
Similar to buffers, having contingency plans is something you should always strive for as a project manager. Life and work are simply way too unpredictable if what you’re doing has any degree of complexity at all. You should just assume that something will go wrong somewhere, and be prepared for it.
Having a plan B or C doesn’t mean you have to do double the work, because you’re duplicating your effort. It simply means doing enough thinking and checking, and being ready to activate an alternative when the time comes.
In our example, we were recommended certain engineering and consulting professionals for acoustic, mechanical, hydraulic and fire safety topics. We spoke to all of the recommended ones. But we also lined up another 1-2 backups for each discipline. We sent them our scopes of work and asked for quotes and terms of engagement. So that we were ready to go if needed.
The one thing that I try to do when putting in place contingency plans is being transparent and clear with your suppliers. I like to let them know that we have someone lined up, but are looking for potential additional suppliers. Just to keep expectations right and not have to deal with too much follow-up.
If you are in the middle of a project now, ask yourself - ‘do I have a plan B or C’ for the most risky parts of your overall plan. And if some other parts of the scope start smelling like risk, quickly brainstorm a contingency plan as a first step. It’s amazing how much peace of mind it can give you. As well as helping keep your project on track.
8/ Manage compromises and red lines
Whenever you’re working with other people, as is usually true for BI projects, you will inevitably run into conflicting opinions. The trick is to know which conflicts are resolvable and where a compromise can be achieved, and which conflicts are red lines. Knowing this can save you a lot of headaches and inefficiency, and helps makes the overall process more streamlined.
In our example project, we had an architect drawing up plans for the space, which then had to be reviewed by multiple parties. Some parties turned out to have very strong opinions about where things had to be positioned. Other parties had other opinions, and they often clashed with one another.
It can sometimes be confronting when you’re stuck with this conflicting opinions, but you are the one in charge of ‘quarterbacking’ the overall project. What I ended up doing is just have individual conversations with each party. I told them that their view conflicted with those of others, and asked whether it was something they were able to compromise on, or if it was a deal-breaker for them.
Once you repeat the process with everyone, you should be able to make calls on compromises where those are possible. For areas that can’t be a compromise, you have to then go back to each party and explain how a clash with their preference seemed unresolvable. And then you just have to be prepared that the whole project would get derailed. However, more often than not, when presented with the potential for entire effort to be put at risk, most parties would soften their stance.
Achieving this kind of outcome is, of course, a win for everybody. But getting to this point may not be straightforward. As a project manager, it is your job to navigate ‘the cats’ towards this kind of resolution. And you have to actively work at it, rather than hope that the parties involved will reach the same conclusion by themselves. You have to present everyone with the facts and frame the decisions correctly, so that everyone understands what’s at stake.
You also shouldn’t rush this process, or try to fix everything in one big go. Having a big meeting where parties with contradicting opinions would be forced to battle it out in front of others is often not the best way to resolve an issue. In my experience, it is much better to ‘soften the ground’ first. And you do that by having one-on-one conversations first.
9/ Vary format between group and individual sessions
This one is already alluded to from the point before. To be a good project manager you need to master the art of picking the right format for various kinds of discussions and inputs. And efficiency shouldn’t always be the deciding factor when choosing it.
Sometimes, it is best to start with smaller, individual conversations. This allows you to be more open, but also for your stakeholders to open up better to you. They might not be comfortable sharing their apprehensions openly in bigger groups. But if it’s a one-on-one conversation, they might let you in on why they prefer for things to be done a certain one. You need to be smart in the way you orchestrate these interactions.
You also need to be clear whether each of your interactions is an update, or an opportunity to provide inputs. Sometimes you actually don’t want too many inputs, because this can put your entire project timeline at risk of slippage. But at the same time, you wan to provide ample opportunity for inputs, within reason, as it helps you get better buy-in and understand the project from multiple different perspectives.
In general, I’ve found that big group discussions are rarely helpful or productive. But they might be an effective way to generate the final sing-offs and agreement. If you need to achieve a resolution, and it’s been providing difficult through one-on-one interactions, you might actually want to push the discussion into a group setting. And then the fact that parties might not want to share all of their concerns openly with everyone might come in handy for you.
Of course, that would be a somewhat extreme case, where you have to move the process forward despite someone having unresolved concerns. It is much better to be able to resolve those concerns beforehand. But the world is imperfect, and sometimes you just have to keep the process moving. Just do your best to avoid ‘steamrolling’ anyone if you can avoid it, as it’s just a much better way to do work.
10/ Keep information flowing / over-communicate
And finally, as the quarterback for the process, you need to always keep communication flowing in all kinds of different directions. It is usually best to control the flow of that communication, however. You want to avoid an uncontrolled flow, as it can create more chaos than good. But as a general rule, more communication is almost always better than less.
One thing I learned through firsthand experience is that whenever you’re communicating with someone, always start with context. People are often busy with multiple different things, and they not thinking about your specific project as much as you think they might. So starting with a context reminder always helps. If they already know or remember the context, they can always let you know and ask you to move on to the actual content of the discussion.
Similarly, after you’re done discussing the content, always describe the broader process (and where you are in it) and next steps. This helps people see and appreciate the bigger picture. They can also better understand their own role in the broader project, and be able to better contribute as the result.
Knowledge and clarity on next steps is also critical. Firstly, it just helps put most of your stakeholders at more ease, if they know there is a process in place for how things would progress from where you are now. But secondly, it is also helpful to you as the project manager. Because it can be a forcing function for you to put a process in place, if there isn’t one yet. Or remind yourself of critical activities that you might otherwise forget about (like sending out those updates to everyone, based on the discussion you just finished).
Finally, communication doesn’t have to be tedious and time-consuming. You can use multiple forms of communication, depending on your specific requirements. Sometimes, just a short text message is enough. Text messages do count as formal communication. And sometimes, you might want to write a longer email, or pick up the phone and give that call. You just have to strike the right balance between frequency and depth of your updates.
Conclusion
Hopefully some of these tips, tricks and best practices are somewhat helpful, as you navigate your own business improvement (or other) projects.
If you have and comments or suggestions, we would love to hear about them. Feel free to email us or leave comments on the web page below.