Hi there! If you’re a project manager in any capacity, you may have wonder what are the essential duties of a project manager.
Understanding the "essential duties" helps you focus on the most critical things you have to do, at any moment of the day and at any stage of the project.
However, I'm sure you also know that it often seems a project manager does almost everything in a project.
This can range from managing stakeholders, to running status meetings and at times, even rolling up his or her sleeves and fixing the nuts and bolts of a project.
In this article, I want to remind us all of five essential duties of a project manager. Out of the sea of tasks that a project manager can do, there are five key duties which you should never forget.
They are, in no order of priority:
Some may argue that other things like boosting team morale, being a mentor or even sales are included in the list of a project manager’s duties. However, based on my experience, I find that the above are the ones that are most prevalent in projects, regardless of industry.
A project manager acts like the “brain” of a project. You can say that all the team members are arms, legs, organs and other parts of the body and it is the PM who controls who does what. Without the project manager performing the oversight duty, everyone would be scrambling, doing their own thing and not sure whether the project is closer or further away from its end objective.
Case Study: I’ll highlight a personal example. I’ve seen projects where there is no dedicated project manager to act as the “brain”. When I was working for a technology services company back in the early 2000s, I once heard of a colleague of my who was deployed to a project at the stock exchange in a particular country.
The objective of that project was to enhance the stock exchange’s trading system so that trades from brokerages could be routed more effectively and trade orders fulfilled more quickly.
Here’s the thing - in that project, he was designated the business analyst, systems architect, developer and project manager - all rolled into one! You’d be surprised - in Asia, many technology companies do this when they are short of resources. And the end result is that you effectively have no project manager on the ground!
Needless to say, the project went into trouble and my colleague, faced with intense and unrealistic time lines, staged a protest by going on a self-declared holiday a whole WEEK. He let the partners and sales people clean up the mess and just disappeared.
So remember, the key thing is to ALWAYS HAVE a dedicated project manager on board - regardless of the size or objective of your projects.
The second essential duty of a project manager is to allocate tasks. Again, this is often overlooked and leads to huge delays in projects.
Many project managers are what I call “Desktop PMs” - meaning that they draw up a very nicely detailed project plan in Microsoft Project, share it with executives and say that this and that will be done by when. But what do they fail to do? They fail to move on to a deeper level of detail and ensure the tasks are distributed and done!
I’ve heard of project managers who simply give the overall project plan to team members and say “There you go, make sure you deliver this by this date”. Now, granted, this is not all wrong.
You CAN delegate your projects in this way - provided you have worked with your team members for a long time - project after project - and a definite level of trust has been built up. Unfortunately, most projects are not like that and you HAVE to allocate tasks and track them after they are given to team members.
I have a simple system (described here) which I like to use when delegating and assigning tasks to team members. And one thing I also try to remember is that I follow up with team members, ask them how they are doing and whether they are facing issues with their tasks. I don’t just sit behind a desk and wait for folks to “report in” to me.
Communication is one of the key items a project manager MUST be good at. Everything in a project - getting people to do things, getting stakeholders to sign-off on deliverables, evening convincing senior management of why a project should be delayed - comprises of communication.
Also, to me, I’ve begun to realize there are two levels of communication that a PM can employ - Level 1 and Level 2. A “Level 1 Communication” approach means that as a PM, you communicate at the most fundamental level, e.g. you run status meetings, you update stakeholders on deliverables and you basically inform what needs to be known.
A PM who is adept at “Level 2 Communication” does more. He or she doesn’t just draw up status reports and reads them off at status meetings. He or she is good at the “soft” side of project management. You’ll see this person walking around stakeholders’ departments, going into their offices - smiling, chatting and having coffee with them.
And they know that these seemingly frivolous activities are an important cornerstone of stakeholder and communication management. By communicating with your stakeholders in informal settings, you’ll much better able to convince and persuade, rather than doing it in status meetings where everyone is tense and formal.
Case Study:I’ll give you a personal example. When I was running a core private banking system implementation for a well-known bank in Malaysia, I had the arduous task of convincing my business stakeholders to accept several “manual workarounds” in order for the system to go live by the stipulated date. A key stakeholder of mine (the Chief Operations Officer) wanted to have an enhancement regarding trade reconciliation built into the system.
He’d flatly mentioned he’d not sign off on the User Acceptance Testing and go-live if that functionality was not built. I checked with the vendor who mentioned it would cost 20 man-days to incorporate basic trade reconciliation features into the system. The go-live date promised to management was a week away. This was the final hurdle we had to get through before obtaining sign-off for go-live. But the COO was adamant the feature had to be in.
One way around this kind of situation is to talk to the CEO and ask him to bed down the COO. But in our case, the CEO was new and a weak fella who often did not make decisions. The decision making for most of the project was in fact with the COO, who knew the ins and outs of the bank’s operations.
In the end, I was honest and upfront with the COO. I took him out to coffee and we had a one and a half hour discussion. I told him, look - it is in our interests for the system to go-live and I knew how important trade reconciliation was to him because it cost his team many, many hours of pain on a daily basis.
However, the system does did would reap other benefits for operations in other areas. Why not go-live and then schedule a priority roll-out two months after the system stabilized?
It took some time for the COO to agree but eventually we agreed on this approach. In the formal go-live meeting, the COO gave me his full support and the system went live as planned.
Lesson learnt? Apply advanced communication strategies, particularly around stakeholder management, to “soften” your key stakeholders. Don’t engage them only during formal meetings. Do it offline, in less confrontational settings.
A project manager also needs to know how to control scope. To me, making your stakeholders happy while controlling scope is usually the KEY challenge for most PMs.
To make your stakeholder happy, the project needs to deliver the benefits intended. This means consumption of time, resources and energy. However, most of the time, stakeholders see only the business side of things - they don’t see the project and timeline aspect of the initiative.
sIf I give in to my stakeholders and give them free reign, implementing anything and everything they deem fit - my project scope and budget will be blown way out of the water.
A good way to control scope is to phase your roll-out of enhancements. In system delivery projects, it is common for us to divide projects into “phases”. For example:
When I have scope discussions with my stakeholders, I don’t usually say “Oh, it’s interesting that you want to have this functionality rolled out. However, that’s not within the project scope”. That kind of conversation usually ends up in a stalemate - the stakeholder will usually refuse to give in, citing that his or her work will be very painful if the functionality is not there and they will not sign-off on go-live.
I find that a better way to approach it is to say "I think this new functionality will be very useful. However, we want to concentrate on rolling out base functionalities in Phase 1. Are you ok to slot this functionality into Phase 2, where we roll out two months after the Phase 1 of the system goes live?"
This approach, while not guaranteed to control scope, does give much better results for me.
Project managers should also be intimately familiar with crisis management. In projects, there are a thousand and one things that could go wrong, and it is the project manager who will stay calm and collected to steer the team out of the crisis.
In my line, we do a lot of systems implementation for banks and insurance companies here in Singapore and Southeast Asia. Typically, when systems are about to go live, we encounter a host of mini crises - from users who refuse to let the system go live, to deployment issues over the weekend, e.g. cash balances not tallying between the old and new system.
Those of you who have been in charge of “go live” situations in system projects will know exactly what I mean.
The key in resolving a crisis as a PM is to stay calm. Get the people who know the issue well to come together and brainstorm solutions.
Is there a manual workaround that can be put in place in the interim until the system can be fixed - if so, is the stakeholder group ok with this? If they are, you can still go live.
If there are no manual workarounds and you need to call off the go live, then you need to stay cool headed and justify to management why the system cannot be put into production.
The above has shed some light into the five essential duties of a project manager. Very often, we as PMs - experienced or inexperienced - tend to forget these basic responsibilities. I suggest that the above five points be printed out and stuck on your desk so that you can see them everyday.
When I was starting out in my PM career, it never occurred to me that such basic checklists were necessary. Now I know much better - on my desk are lists and lists - from requirement checklists, to quality checklists and go live checklists.
And yes, I also have the five basic duties that every project manager has to perform right up there in front of me.
Practice applying these concepts to your projects and soon you’ll start to see benefits in project delivery. The more you remind yourself of the essential duties of a PM, the more successful you’ll be in managing projects!
Are you wondering how to break into a Project Management?
Would you like to understand how others have successfully switched to a PM career?
Or discover what skills, certifications and domain / industry knowledge are required to excel in a PM role?
I’ve written a practical, easy-to-read guidebook that will help you find your best path to Project Management – one that leverages your unique skills, experiences and career background to your advantage.