If one reads the Project Management Institute’s Project Management Body of Knowledge (or as the cognoscenti call it, PMI’s PMBOK) you’d think there was just one way to be a project manager; a heavy waterfall approach that the cool kids think is old fashion. In the latest edition, they’ve added some information about agile approaches, but it reminds me of the parents in a mid-1960’s movie trying to sound cool to their hippie children. They just don’t quite get it.
If you talk to fans of an agile approach, you’d think everything can be broken down into sprints and that requirements documents are a waste of time. For them, an engaged stakeholder is assumed but—news flash—some stakeholders just want to be left alone until you’re done.
Fans of Kanban like to break everything into a queue.
As a fan of an adaptive approach, I like to talk about constant replanning based on learnings and risk reduction.
There are many ways to be a project manager, and none of them are perfect. The experienced project manager needs to have a variety of tools to manage a variety of situations.
Build your toolkit like a Superhero
In 1966 Abraham Maslow said, “If all you have is a hammer, everything looks like a nail.” To be an effective project manager you need to be Batman with his utility belt, not Spider-Man with just a web shooter. Maybe if you have super strength and spidey senses you can get by with just one tool, but most of us are mere mortals and need some options.
Speaking of spidey sense, what a great tool to have for risk planning! Experienced PMs develop spidey sense by seeing projects go sideways again and again. Even without the scars of experience, a structured approach to risk analysis can reduce the tingles of an unrecognized risk leading to problems down the road.
One of the challenges of a PM is to get the truth out of your team, so Wonder Woman’s lasso is a great tool. The team may know that the stakeholders want something in two weeks that will take them three and might be tempted to tell you what you want to hear, not the truth. You need to know up front how long the tasks will take in the beginning, not when you’re a week behind schedule. When things go wrong, team members sometimes try and fix it before the PM (or even worse, the stakeholders) find out. This is as helpful as a bad guy hiding the location of a bomb. The magic of the lasso is to never punish the messenger. Thank the bringer of bad news and work with the team to figure out how to proceed.
One does not need to travel to the Himalayas and seek out The Ancient One like Dr. Strange: your local PMI chapter probably has seminars that are more convenient and certainly more welcoming. You can also read books and blogs (like the LiquidPlanner blog!), talk to colleagues, experiment on your team (obviously, you need to be careful about this one). There’s no shortcut and it’s a process you should be following throughout your career.
If you start a new job and they do project management differently than you have (as they probably will), think of it as a learning opportunity. Think about what this new paradigm does better than how you’ve practiced the art in the past, and what it does worse. (If it does everything worse, that’s the topic for another blog post on change management.)
A senior PM should be as flexible as Mr. Fantastic. “We’re going to do agile with the software team, waterfall with the hardware team, and Kanban with the test team.” shouldn’t pose a problem. There are structural challenges with multi-paradigm approaches but one of the problems shouldn’t be, “The PM doesn’t know how to manage an agile team” or, “The PM hates waterfall”. (There’s a great blog post on how LiquidPlanner can help.)
Choosing the right paradigm
Once you have a tool belt filled with cool gadgets, which one do you grab? Imagine how embarrassed Batman would be if he pulled out the grappling hook when he really needs shark repellant.
Or, using the hammer metaphor, before you get started on a project you need to recognize that the problem is installing a screw, that the right tool is a screwdriver, and that you know how to use it.
Leaving the metaphors and getting back to project management, let’s start with understanding the situation.
1. What is your project like?
I think the most important questions you can ask about the project are:
- How complex is it?
- task dependencies
- multiple teams not co-located
- How much uncertainty is there?
- new tools
- requirements undefined
- solution not currently known
As a rule, waterfall handles complexity better. If your project has lots of tasks that must be completed in a particular order you’ll want to use waterfall or something the resembles it. If having a realistic schedule of when things will be completed is important, then you’ll also want to go with waterfall.
Agile and it’s fellow travelers (e.g. Kanban) handle uncertainty better. You can’t put together a work-breakdown structure if you don’t know how you’re going to meet your challenges. If you don’t have clear requirements or an architecture, you’ll want to avoid waterfall and use something in the agile space.
2. What is your team prepared for?
Next, look at your team.
- What do your stakeholders need and what can they provide?
- In what paradigms is your team experienced?
- What paradigms do your process, procedures, and tools support?
Remember that your stakeholders are part of your team and you should start with their needs and capabilities. If they’ve provided you with a full and stable Product Requirements Document (PRD), then waterfall might be a good approach. If they’ve only provided you with a vague vision of the finish line, then agile might be the right way. If your stakeholder has never been the stakeholder in an agile project, make sure they understand what’s needed of them and that they are willing and able to do it before you go down that path.
The best path might just be to do whatever the team has strength in. If you’re Aquaman, you try and figure out how to use your ability to communicate with fish helpful. I worked at one place that was so waterfall, they used it even when it made no sense because it was the only process the executives understood. Introducing a new project management paradigm would be harder than getting the US to go metric. I’ve worked at other places where a discussion of a PRD might as well be held in Klingon because only a few people understood what the word “requirement” meant. Just like Aquaman fighting in space, you often find your tools are not optimal, but you do the best with what you have.
Some tools (like LiquidPlanner) are flexible and can support multiple paradigms. Others (like MS Project, post-it notes on the wall) are specifically designed for a particular approach. If your desired approach doesn’t align well with your tools and procedures, you need to decide if you can make do with what you have. Otherwise, it’s time for your company to invest in introducing new ways to work. Not a task to be taken lightly, rolling out a new approach is typically a major effort that will only pay off in the long term across multiple projects. It’s definitely not worth doing for just one project.
Be the mild-mannered Superhero your projects need
A project manager is in the “Batman” category of superheroes, people who have honed their mastery through dedication and experience, not the “Superman” ones who were born into it or bitten by radioactive spiders. I’ve always preferred these types of heroes since their accomplishments are more impressive for the relative normalness of these people. And remember to always act as the mild-mannered alter ego; the best PMs are the quiet heroes who let the credit go where it belongs, to the team.
eBook: How to Manage Chaos
Every month, project management expert Elizabeth Harrin fields readers’ questions about the challenges, risks, and rewards of project work on the LiquidPlanner blog.
We’ve compiled our favorite columns in this eBook:
