As referenced previously, I favor maintaining the title of Project Manager for individuals who are working with product delivery teams for tech products. Program and Portfolio Managers will be covered separately.
The only exception I would make is if the teams were delivering in a 100% Scrum fashion, then I’m in favor of using the Scrum Master title. However, that means that the role needs to be defined as in the Scrum Guide, no more or no less. I’ve seen some organizations give the title of Scrum Master, but still expect the person to “hold the teams accountable” and even “be responsible for team delivery.”
If your organization is 100% bought into Scrum, then work with your existing project managers to see if they’re interested in learning and doing the role of the Scrum Master. If they’re up for it, send them to Certified Scrum Master training to learn the basics, and considering providing some additional team or 1:1 coaching to help with the mindset shift needed. As the PMO Director, depending on your familiarity with Scrum, you may also need to enlist outside help to give tactical guidance and help in the area that you’re learning. Not all your project managers may sign up for this, and that’s okay. Work with them to find them another opportunity (hopefully within the organization) vs. trying to adapt to a Scrum Master role in a 100% Scrum working environment.
For those cases where it’s not 100% Scrum, below is some guidance.
Note: Organizations who say they “have their own agile framework” or that they “use a hybrid approach” are sometimes ridiculed as “Scrum-Fall,” “Fake Agile,” or some other term. Be mindful of this – it’s okay to do your own thing as long as you’re obtaining the outcomes and results that you’re looking for. Another helpful resource is the Agile Practice Guide which was a joint effort between the Project Management Institute (PMI) and the Agile Alliance. I had the opportunity to be a reviewer of the guide, and I HIGHLY recommend reading it because it gives a wonderful overview of the various ways to manage work to help you determine the best way for your needs.
What I look for (and don’t look for) in a Project Manager
I’m always recruiting, if not for a position on my team, for individuals in case I know of anyone in my professional network that’s hiring.
Below is what I look for:
- Someone who is continuously learning and growing/has a growth mindset and low ego/doesn’t haven’t to be right. Someone with an open mind and curious.
- Someone who tends toward facilitation and servant leadership; they see success when the team succeeds, not when they do.
- Depending on the level of experience, someone who has been exposed to, worked with and is familiar with a variety of project management practices and tactics. Someone who understands there is no “one right way.” For those who are earlier in their careers, being open to the exposure of a variety of ways of doing something.
- Someone who looks to continuously improve how they, the team and the organization work, not afraid to challenge the assumptions and status quo and/or get to the “why” of the matter.
- Someone who is organized, has strong follow-up skills, has a bias to action and is a creative problem solver.
- Someone who is adaptable, flexible, compassionate and kind.
- Someone with strong communication skills; able to tailor communications to the audience effectively.
- Someone who thinks holistically and has a systems-based approach to make connections and see opportunities.
- Certifications are nice, but not required. If certificates are gained as a way to learn, they will hold more weight with me.
Red Flags
- Someone who puts too much stock in certification. See point above, they are great for learning, but that doesn’t mean that skills are of a certain caliber.
- Someone who doesn’t ask questions and makes a number of assumptions.
- Someone who is hyper-aggressive
- Someone who’s first intention is to distrust and/or not give individuals the benefit of the doubt.
- Someone with a victim mentality.
Operating in a New Way
The biggest shift for the project manager when moving to product-delivery teams is the ability to “let go” of the “what” the team is working on. The scope of the work is to be decided by the Product, Engineering and UX leads. In command and control environments, everyone would look to the project manager to set the scope. It’s not that the project manager can’t have an opinion on the “what,” is just that it’s not the leading voice. Project managers move from a project leadership role to a managerial role.
In Inspired v2, Marty Cagan calls the role a delivery manager, and while I prefer to keep the project manager title, I agree with the ethos of the role.
In growth‐ stage and enterprise companies, many product managers complain that they have to spend far too much of their time doing project management activities. As a result, they have almost no time to address their primary product responsibility: ensuring that the engineers have a product worth building. – Marty Cagan, Inspired v2
In the book, Marty mentions that as companies grow and/or are enterprise organizations, many product managers and engineering leads find that they’re spending quite a bit of time doing project management activities when they need to be focused on product and engineering related items to ensure that products are valuable and feasible.
The delivery manager role is all about enabling the team, which can include removing obstacles, managing dependencies, working with stakeholders across the organization on behalf of the team (e.g. Marketing and Sales regarding what’s being released when and/or if there’s something that the team needs from those groups). This is supplementary and does not supplant the team.
They help the team move faster by clearing the way, not by chanting “go faster!” “Go faster” is too ambitious anyway – how fast do we need to go? Maybe there is a target the team wants to hit with regards to their Cycle Time, then start to figure out where the delays/constraints are and work to remove them. This is another area where project management skills can help as it’s creating a plan for the improvements, tracking their progress and outcomes.
Another example is with retrospectives (or whatever process is used to identify areas where the team can make improvements). A common complaint of product delivery teams is that “nothing is done about the action items that are determined in the retro.” A project manager can take ownership of ensuring that the follow-up items are taken care of, which not only improves how the team works, but also the team’s morale.
This brings us to another project management skill – looking out for the health of the team. As the agnostic person on the team, a project manager can be the go-to person if there’s a problem/conflict that needs to be solved. This is why soft skills and creative problem solving is important. Skills to foster connections and healthy relationships are important so that conflict can be easily resolved without having to get the individual team members’ bosses involved.
Facilitation skills are needed to successfully facilitate whatever meetings/ceremonies the process is relying on. Action item tracking, reminders and follow-ups are needed. Again, remember we want the various folks out doing their parts that contribute to success (e.g. Product/Engineer/UX out talking to customers to validate/invalidate ideas), so as a project manager, being there to remind them of their commitments and target dates is helpful and alleviates the cognitive load.
Communication and transparency is critical. Organization need information on a regular basis of what and how the team is doing, what their recent accomplishments are, their learnings, their decisions and their struggles. Project Managers can provide this function for the team with full transparency and agreement from the team of what’s being reported so that there isn’t a “snitch” or “spy” aspect of the communication. This doesn’t have to be a formal status report, it can just be a simple email to appropriate stakeholders. Do what makes sense in the lightest way possible. If more is needed you’ll find out – subtract, don’t add.
The project manager can also be an internal amplifier for the team – echoing and reinforcing the Product person’s “why” behind the work and how it fits within the larger strategic goals of the organization.
Note: This is also a good time to look at your status reports and other communications that come out of your PMO. Will they still provide value in the new way of working? Ask your stakeholders/recipients for input. You can probably do more with less. I’ll get into program and portfolio level reporting in a subsequent post.
Finally, let’s address delivery planning. Depending on the process and team, planning will take on various forms depending on what approach you are using (see my comments about Hybrid approaches above), so let’s look at a spectrum:
- NoEstimates
- Type 1: The team works off a prioritized list and releases as work as it is done. Planning means providing visibility of the prioritized list, any dependencies needed for each work item and when work items can be incorporated into a production release. The communication and transparency requirement is provided by sharing the list and what made it from the list into the production release.
- Type 2: The team does zero estimation upfront for work items in a particular time box. However, they usually identify a chunk of work to be done in that time box. This approach will work if the team has had quite a bit of experience working together and they all have familiarity with the work to be done and have reasonable confidence that the chunk of work will fit in the time box. Planning is simply that the team is expecting to complete “this chunk” in “this time box.” That can easily be tracked, managed and reported. A strong project manager I worked with previously worked with her team to get the stories all about the same “size” and based on observing trends realized that as soon as the team took on more than four stories in that time box, they were not able to meet their expectation.
- Work Item Estimation – at the beginning of the time box, the team reviews the work items (e.g. stories) and assigns some kind of estimate to it (e.g. story points). The main thing here is that all work that factors into being done needs to be considered. This isn’t only the build estimates; estimates also need to include testing and release. Something is not done until you have a customer using it.
- Full Up-Front Planning – this is more traditional planning where work involved usually requires more than one or two time boxes, and a further-looking plan is needed to ensure successful delivery. This is sometimes called Release Planning, and an example could be where individual teams are all building toward something and/or where there are more dependencies are needed from the back-end/infrastructure teams. This is helpful whenever work needs to be more effectively coordinated and orchestrated and the teams are not able to function autonomously.
For this spectrum, this level of project management planning tactics varies. I hope it’s evident where the project manager can provide value, but if not, please feel free to reach out.
In addition to the above, you may also find it helpful to add a level of confidence to the work items, e.g. 100% – we’re very sure, 75% – pretty good chance, 50% – could go either way and 25% – unlikely, but this is our best guess given what we know now.
Remember the same approach DOES NOT have to apply to planning in every scenario and estimates/forecasts are inherently guesses. This is why project managers are most valuable when they have a variety of tactics and practices to best fit the situation. We don’t want the process to constrain the teams. That team I mentioned who had success with NoEstimates – they were able to launch faster (and realize value) than if they wasted time planning each work item because “the process said they had to…” Be very careful that the project manager does not become the Process Police.
I’ve been known to say (to the surprise of some folks) that I don’t care how the team accomplishes the work. They could lock themselves in a room for two days, but if they reached their outcomes, that’s what matters to me.
I do have a few non-negotiables though in order to meet the PMO’s customers’ expectations, which are: insight into the work currently in-flight, team’s best guess of when the value will be delivered (I’ll even take “not in this quarter” as an answer), where they see risk and what issues they’re running into (and what they’re doing about them), what else they need to be successful and that they share any learnings with the larger organization.
Hopefully, this helps describe how project management can be a win-win for all involved.
Below are some helpful resources. Do you have any to add?
- Johanna Rothman’s – Predicting the Unpredictable, Create Your Successful Agile Project and Cost of Delay.
- Woody Zuill’s NoEstimates
- Cone of Uncertainty
Previous: Functional Managers Next: Program and Portfolio Management
Shortcut: All PMO Directors Series Posts