What are the first steps when you take over as a project manager of a new project?

Project Manager Resources & Tips

Firstly, I’m hoping you know the triple constraints (scope, budget and schedule) and their importance to the PM at the start of a project, at the end, and every second in-between. If you’re not sure about that, then I would recommend reading up on PM basics, or possibly pursuing a career in the circus. Assuming you know the triple constraints, I’ll touch on them briefly throughout, but it goes without saying, always know what you are trying to deliver in the project (the scope), for how much (the budget) and in what timeframe (the schedule).

Project management is both common sense and an art

Project Management for me is two things. Firstly, common sense – can you get the right person at the right place at the right time; secondly, an art form. It’s an art because successful Project Managers are really Project Leaders – it’s leadership, people management, soft skills. There is no magic formula, calculating Earned Value certainly won’t help get you there, nor will knowing how to use a sextant. As a disclaimer, I don’t intend this article to be the final word on the art side of project management, nor do I claim to be a messiah of project management, but I do hope to impart some useful first steps to take when starting a new project, or taking over an existing project from another PM.

Understanding the project and what you are delivering

Let’s define our project: For the purposes of our discussion, our project is to build an application that measure and model the curvature of space, has a budget of $1M and needs to be launched in 6 months from today.

Here you are, first day on a new project. Excited? Let’s hope so! With a pile of print-outs on your desk that amount to a scope, you need to build a picture of what you are delivering. First understand what it is you are delivering (in this case, a model of curved space), but also understand the business case for delivering it. As a PM you may not have built the business case or the justifications, but you are responsible for ensuring that the business case is realistic, and that this project delivers to the business case. I realize in some organizations, PMs don’t have this accountability, but if you want to be a great PM, consider yourself accountable to delivering the benefits of the business case regardless. In learning the business case, you are already on your way to understanding the players on the business side of this project; you also learn which of the triple constraints is flexible. The business side is not evil, even if others in your team think so. They are your partners in this project. Don’t build the best technical application you can think of only to miss the goal that the business was trying to achieve (yes, I own that t-shirt already).

The world of stakeholders can be complex; you have could have people on your project team who are business stakeholders who have no say what so ever in making business decisions about your project, and likely the people that do have the decision-making ability are not on your project at all. This is a veritable minefield of a position to be in. This is where leadership comes in. You need to navigate that minefield and determine who the actual players are, not just who is listed on your project as being stakeholders. It takes tact to ensure that weak stakeholders still feel involved, and guile to determine who the real stakeholders are and ensure their continual involvement.

On the IT side, or the delivery side of the project, understanding how the team fit together, their personalities, skill sets, wants and desires is very important – equally as important is understanding how the organization works on projects. This is the team that will do the lion’s share of the work, and at times they will be under a lot of pressure, either from you as the PM, or other organizational constraints such as other projects, direct requests from line management etc. Being able to call on your project team to work late, or stop what they are doing and work on a priority that you just received, or estimate a new change control, all of this is so much easier if you have spent time understanding the dynamics of the team as a whole, and each of the people that make up a team.

The importance of communication and creating relationships

It sounds like a lot to do on your first day, but so far you have read a few documents and then started using the three most powerful tools a PM has at his or her disposal – their left ear, their right ear, and their mouth (I want to point out for a minute here that just because Van Gogh had one ear at the end, that wouldn’t prevent him from reaching greatness in project management. Indeed he seemed to be a little crazy, and that’s definitely a good attribute for a PM). People call talking and listening many things; walking the floors, empowering people, leadership. I’m not sure any particular moniker works for better for me than any other, but it is by far the most important task a PM can do in their project. I would rather spend a few hours a week interacting with the IT and business team face-to-face (or video/conference calls for a virtual team) than 40 hours churning project plans and status reports.

Reports and project plans are important, but let’s take an example. You need to issue a report saying there is a 1-month delay in Go Live due to someone forgetting to include the calculations for the curvature of space based on non-Euclidian geometry (oops!). That report will go down pretty poorly if you spend your time doing traditional PM tasks such as updating your project plan, working out the cost of the delay, and then reporting upward to the Project Sponsor. Without a relationship of trust, you’re probably off the project – spending time working with your Sponsor, or developer or Test Lead, whoever, changes that message. The message is now received with the knowledge of who is giving the message, the thought that went in to discovering alternative solutions to remedy the issue, and led to the position that you are now presenting as the only feasible outcome (or perhaps you are offering alternatives such as reduced scope to stay on track).

So that’s the trust/relationship piece – the single most important task any PM needs to work on every single day of the project.

Taking and knowing risks

Other first steps to take? Two spring to mind instantly. Determine how risk averse your sponsor is, and the other stakeholders – it will determine how, what and when you communicate. Again this becomes easier with trust already built, but ask the simple question “things will go wrong on this project, when do you need to know about it?”. By asking this question, you’ll understand who in the team are prepared to take risks. I did a project where I worked with the sponsor frequently refining this answer as we moved through a 15-month project, each time the sponsor became more comfortable with the team’s ability to deliver so he didn’t require an immediate communication around the smallest issues. This again builds on trust.

Holding daily project meetings

The second step to take? Find a place to meet with your team regularly, and stick to it. In those meetings ask three questions “what did you complete yesterday, what are you doing today, and is anything stopping you from doing that”. This is straight from Scrum, though you may not be running Scrum project, they keep the meetings focused and short. Daily project meetings can be very effective, if they last less than 15 minutes.

You are the morale manager

One last parting word. Have fun, I say to every team I work with that if a project is not fun, it’s not worth doing. I’m not talking about making something fun, just having fun doing it. You’re the PM, the project manager, but also importantly the morale manager – bring in pizza every so often, make a rule that if you are late for a meeting then you buy bagels for the next meeting – it doesn’t matter what it is you do, but make it something light-hearted for the team.