We’ve all been there… We walk into a new project, and it’s already started without us!
How do we know the project already started? Easy, someone that knows more about the project than you decided to assign you as the Project Manager. A project begins the moment it is conceived.
However, the project manager should be the most knowledgeable person in the room when it comes to their project. At the moment you first learn of the project, this is not the case. The sooner you establish this, the sooner you’ll be able to take command of the project. The longer you passively wait, the less chance you have of being successful in your role.
Right out of the gate, we need to be able to understand and communicate where the project came from. Why does it exist? How was it selected and put into the portfolio and who is it’s sponsor and owner. What are the sponsor’s objectives, and are they clear? (Does the sponsor need help fleshing this out?)
Plainly, what does management know about the project, and most importantly what numbers and dates have they seen in regard to the cost and time?
Second, we need to understand the current organizational structure, and what each player’s roles and responsibilities are. Undoubtedly, you’re most likely walking into a project in which much of your team has already been decided for you. At the end of the day you are the project manager which mean you’re responsible for your teams performance. What, if any, are the existing meetings that are established?
Then we need to have one-on-one discussions with each of the team members to understand what they think their role is, what you’re role is, and understand how you’ll be able to communicate with them. Be sure to ask them what kind of deliverables they need to create, or have already created. Ask them what meetings they already have attended or are scheduled in regards to this specific project. Have an open conversation with them coming from a place of understanding.
From this you should be able to develop a clear sponsor’s objective document with scope boundaries, key milestone dates, and buy-in. Along with an organizational chart with a meeting RACI chart.
I understand, it never feels like there is time to develop these critical things, and they also seem like they end up being locked away, buried in some folder on the “E” drive in a PDF, or excel sheet, and get’s lost forever, and never updated…
All of these “things” need to become the cornerstone of your project, and must remain evergreen. The best way to do this is to build your entire project on-top of them. If you can think of these pieces of information as your project operating envelop, and keep it as tight as possible then you will be able to operate your project within those bounds.
Most importantly, your job as the project manager is to be able to communicate when those bounds are threatened.
We build all of our data behind all of our applications up from this base level. Only then can we understand when the details of our project can potentially threaten the project envelope. For example, the “Org Chart” is the basis for all of our resource management throughout all project phases… It simply grows and shrinks through time, and as long as it stays within our envelope, we know we’re communicating well.
Recent Comments