Project Management Responsibilities and Outcomes: A Primer
A guide for those new to project management
A few years ago I began one-on-one project, program and delivery management coaching.
While I advise at all levels - beginners through seasoned professionals dealing with uniquely complex problems or situations they are unfamiliar with - folks new to project management often have a lot of the same fundamental questions regarding what our world looks like. This is a deck I use to walk through those questions. (Note I have removed transition and title slides.)
This deck wasn’t created to stand alone - I use it as a reference in support of live coaching and interactive discussions. I also sometimes modify it to suit the specific needs of the student. Nevertheless, it seemed robust enough that it may be of some value used independently and in its most generic form as well.
I don’t address any formal, prescriptive “phases” or project frameworks - there are plenty of resources for that and how projects are handled can vary for organization to organization. Rather, I focus on the outcomes we, as those responsible for projects and programs, should be mindful of regardless of delivery approach. What follows would serve anyone in any organization.
For inquiries regarding my coaching services you can DM me or email me at deliveryflow@substack.com.
What the guide is (and is not)
Value of the project management role
This slide is a big deal to me - it’s basically my philosophy of project management.
Some of the skills we rely on
It is necessarily a partial list but these are skills and responsibilities I want those new to the field to have top-of-mind.
The context that the deck occurs in
This deck assumes and orderly workflow from ideation through approval and prioritization. The project manager should ideally be receiving a well-formed work “package” that has been socialize to the critical participants.
(I know that is often not the case but that’s the subject of other articles :)
High level view of the types of activities we need to engage in
Again, this doesn’t represent a project execution workflow (though it, of course, aligns with one). It reflects the work and outcomes that are on our shoulders as project managers.
The rest of the slides will elaborate on each step.
Initial project manager engagement
Even if the work we’ve received was well-formed that doesn’t mean that everything and everyone is as aligned as we need. This is where we look to ensure we begin on the right foot.
As a very wise person once said, Well begun is half done.
Broader project socialization
Now that we’ve aligned our core teams we want to ensure everyone who we need to participate is engaged and that non-participant stakeholders are also aware and have had an opportunity to opine.
We basically continue to ensure everyone is in the loop and there are no surprises (for our stakeholders or us!).
The project team is formed
It is important to ensure the project team is structured in a way that’s optimal to, well, supporting project. I want a new project manager to understand that this often means a project team member’s responsibilities and relationships can be different than what they would normally be responsible for in their day-to-day work.
As an example, I’ve managed projects that have required work from 5 or 6 specialized engineering teams. I ideally still want 1 project engineering lead who is responsible for coordinating the work of all contributors. Sometimes that’s not possible due to expertise gaps or other reasons that but it’s worth making a conscious assessment with a bias towards a single lead.
Project planning
Now that we’ve identified the team we do initial setup of our project: execution approach, meeting and communications cadence, continued refinement of tasks, risks, etc.
Project execution
We’ve put a lot of time into setting things up in an orderly way. Now we get to execute on our plan. As project managers we think about the value proposition we discussed earlier and work to ensure teams are supported and can work efficiently, communications are happening as needed, that the work keeps flowing, we maximize predicability, we anticipate and mitigate risks and communications gaps, etc.
Deployment and transition to operations
While most people realize the need for deployment planning many overlook the transition of ownership to operations. This should be planned for along with the creation of any training or documentation if needed.
Post deployment
I’m a huge proponent of project retrospectives.
A couple critical elements:
The retrospective must result in concrete action and can include improvements to operational or overall delivery processes as well as project and program specific processes and activities.
The progress and results of these efforts should be reported back to the retro participants.
This not only demonstrates to the team that their feedback is sought and respected but also that it will be acted on. Otherwise the retro can feel like simply a gripe session and yet another administrative requirement with little or no value.
Closing Thoughts
