The same is true with software development, and casting the project manager is like filling one of your leading roles.
The role of Project Manager (PM) is both misunderstood and hard to fill.
Here are five must-follow guidelines:
1. Understand what the role is
Confusion abounds in businesses about roles on software projects. There are lots of blurred lines, mixed up roles, missing roles, and double teaming of roles. It can look like a soccer game where you’re not even clear who’s on offense and who’s on defense, never mind identifying the goalie.
The Project Manager (PM) role is one of the most misunderstood. The title “Project Manager” sounds very broad. So people just pack into it whatever they think it means, confusing it with the programme manager, business analyst and product manager (more on those below).
Because there is so much confusion about who the Project Manager is, I have consolidated the following definition and description.
Project Manager definition: The PM is formally trained in the methods of project management, often holding a certification such as a PMP. He or she is in charge of interacting with the technical teams, making and tracking the detailed plans, and using project management tools to report on progress. You will see this person conducting daily status meetings, preparing agendas, capturing to-dos and follow-ups, and making sure they get done. He or she will have mastery over project management tools such specialized spreadsheets with lots of macros, ticketing tools, and project planning tools such as Microsoft Project or Jira Portfolio.
2. Understand what the role is not
Looking at the definition above, you may be surprised at how narrow the project manager’s job is. For sure, the PM is of absolute critical importance. However, the role is focused on tracking and reporting.
Folks often confuse the PM with other roles. Here are the roles most often “lumped into” the job of project manager. (And, yes, it’s unfortunate there are so many similar-sounding roles on software projects!)
Programme Manager: The Programme Manager is one level up from the project manager. He or she is experienced in leading medium to large software projects. She is the main interface with the client (internal or external), and organises all the teams. In coordination with the client, she defines the project strategy and goals, make major technology decisions, identifies needs, sorts through conflicts, negotiates solutions, and spearheads execution. In short, he or she is the “uber project manager.”
Business Analyst: The Business Analyst listens to all the needs and requirements of the business and writes a software specification. The BA knows how to translate business needs into documentation that can be understood by programmers and business people alike.
Product Manager: Let’s say your company has three or four software platforms up and running in your business. Someone needs to be in charge of those platforms, how they get modified, extended, upgraded and so forth. This is the product manager. Think of the product manager as the person to whom the software development team “hands off” the finished project.
3. Blend roles at your own risk
Based on a misunderstanding of roles and personalities, many businesses ask the project manager to do business analysis or run meetings like a Programme Manager. But how can a project manager run a meeting when his or her role is to take notes, keep track of what’s decided and who’s assigned to what task? Besides, just because a person has skill in organising and tracking the details does not mean he or she has a grasp of the big picture. It’s a forest-for-the-trees kind of thing.
Project Managers, you may be surprised to learn, are not big picture thinkers. “How can this be?” you may ask. “When they are in charge of the big picture!”
True enough. But the heart of their job is keeping track of the details. Thus, they are often black-and-white thinkers, much like software engineers. Programme Managers, Business Analysts, and Product Mangers all tend to be more big-picture thinkers because of the nature of those roles.
So, asking a PM to perform these other roles is not just outside the job description, it’s actually outside the PM’s wheelhouse.
For the record, I have occasionally seen a very senior PM succeed doing business analysis work.
4. Avoid too much focus on an industry-specific PM
One big mistake people often make in the selection of a software PM is in thinking they need one who understands their particular industry. For example, in media companies, the trend is often toward selecting PMs who understand terminology such as “bylines,” “slugs,” “ledes” and so forth. If the PM isn’t facile with the vocabulary, confidence is immediately lost.
And yet, nothing could be farther from the ideal strategy for selecting a PM. With very few exceptions for some special niches, a savvy PM can learn information necessary to a specific industry far more easily than an industry-savvy individual can be taught the project management skills necessary for a successful software project.
5. Know the key traits to look for & what to avoid
Once you are clear on what a PM is and is not, the key traits for a successful PM make a lot of sense. The traits you are looking for are level-headedness, detail orientation, and facility with numbers, spreadsheets, and planning tools.
Be careful to avoid Project Managers who are tool in love with the tools, or the worst common quality among Project Managers — are overly rigid. A plan is just a plan. It needs to have a certain amount of elasticity to accommodate the shifts that will inevitably occur along the way.
A good PM is flexible in addition to being detail oriented.
Anna Murray is a technology consultant and the CEO of emedia, llc.