The role of the project manager is pretty clear. The job’s description is in the name itself -manage the project- and the position has become ubiquitous across industries. Dozens of certifications exist to prove one’s skills, and entire university programs now exist in Project Management. So, despite the fact that we all know what PMs do and involve them in our work accordingly, why do projects still fail? There are the obvious answers that the PM might simply not be that good at his or her job, or that executive sponsors don’t provide the necessary support to make sure projects get what they need. While that certainly accounts for some failures, there’s a larger issue at blame; tech teams are isolated from organization-wide project management. This is especially apparent in tech-heavy companies, but as technology now spans into every industry, it’s an issue everyone must face.
Avoiding dumpster fires is easier than you think
Let’s take a step back and see what the internet claims project managers should be focusing on. This is aggregated across job descriptions, certification boards, and professional organizations:
Develop roadmaps and user stories
Ensure business asks align with proposed solutions and what’s actually possible
Manage timeline and budget
Ensure customer success and operations understand goals and what’s being released
Measure progress against KPIs and metrics
Great! These are, indeed, good things to do when running a project. Say a company was working on a next-generation peanut-butter-and-jelly sandwich. Understanding how much money and time is available to buy ingredients, assemble, and test the sandwich is critical. Knowing what the sandwich should look like at each step is also important, as is educating the rest of the company on what’s new and great about said sandwich. Ensuring the C-level team agrees on approach is also a great idea. If the list above is the only reference used to run this project, the sandwich, from concept to completion, is actually fairly well mapped-out.
Except for the people actually making the sandwich.
This is the most common pitfall in today’s project management; the complexity of IT orgs and their often wholly-separate management systems makes them easy to exclude from project planning and execution. Project managers and executive sponsors tend to believe that existing IT frameworks -for example, daily scrums- can be immediately adapted to fit new initiatives with little warning or consideration for impact. Various project management frameworks place heavy emphasis on budgets, timelines, buy-ins, milestones, and other important areas of execution, but fail to detail how these parameters can be applied to the often-disparate teams executing the critical tasks.
Recent project management research recognizes that projects are failing, but manages to miss exactly why. A recent whitepaper from a major cloud provider demonstrates this well. When discussing the changing nature of project delivery, they stated that “adoption of new technologies…to deliver more quickly and efficiently” would be key in meeting increasing project pressure. Nowhere is it mentioned that new technology provides little value if the teams can’t use it correctly.
The root of this problem is two-fold:
Project managers are historically not technical. PMs are often required to know a little bit about a lot of things; it allows them to be involved in various aspects of a project from a high level, enough to steer the conversation and make sure objectives are met. As projects become increasingly technical, it can seem harder for PMs to hold these types of driving conversations with highly technical teams. The task is then placed on other managers within the technical team, such as product managers or architects, with often unclear guidance as to how the project should be managed and what success truly means.
Tech teams are often siloed from the rest of the business. These groups typically operate differently than the rest of an organization; even SaaS companies have been known to have project management offices (PMOs) that only interact with tech teams on an as-needed basis, rather than integrating them into the rest of the organization management structure. Part of this is due to the rapid growth and constant change of these teams, especially when compared to groups like HR or Customer Success. Another part is that the content tech teams deal with is often outside of many people’s understanding (or so they believe), and thus “ignoring it” is easier than trying to understand it.
With these two issues compounding each other, project management teams often assume tech teams can be self-driven; simply pass down requirements, and allow them to “scrum it out” and deliver it back when it’s done. As with any other team, however, failure to set expectations and parameters means variation and deviation will inevitably creep in. This is the first step to project failure.
Luckily, the solution to both of these issues is easier than hiring highly-technical PMs and reorganizing entire tech teams.
PMs don’t need to “get it” to manage it. The basic tenets of project management hold true for any team, including the technical ones; how many people are available? What priority is this project, in relation to the other work they’re doing? What’s the technical budget? Asking the same questions that are put to every other team will yield great results.
Understand tech teams’ workloads. It’s a common misconception (outside of those reading this, I realize) that if something isn’t broken or being updated, tech teams aren’t doing much. In fact, they’re often the most understaffed and overburdened teams, in part because of this misconception. Understand the workloads of the teams and how they manage their tasks, and plan around them.
Technical teams are often seen as limiters, but they’re really the key to success. Finding time and resources to complete technical parts of projects can be stressful, but remember that without their contribution, the project can’t get done. Treat these teams as keystones to the project and be amazed at how much more smoothly your timeline and milestones progress.
Ignoring tech teams or assuming they can manage themselves is demotivating. A great way to ensure a project fails is to make enemies with teams critical to its success. “Throwing work” at tech teams and assuming it will be assimilated into their existing processes is not only poor project management, it’s enraging to those having to execute the tasks. Understand their workflow and listen to their feedback; not only will you increase communication and willingness to help, you might uncover project risks you didn’t previously recognize.
As project management evolves, it will eventually need to account for the omnipresence of technology in everything we do. Perhaps extremely technical PMs will become the norm, or entire companies will adopt true agile methodologies from the top down (for anyone who hasn’t spent time in the PM industry, the latter is probably not happening any time soon, sadly). In the meantime, minute adjustments to how projects and organizations are managed can better include tech teams, leading to smoother projects and happier teams. Assuming *any *team can manage themselves within a larger initiative is incorrect, and introduces a level of uncertainty and risk into a project that can be easily avoided. Applying basic PM skills -communication and planning- to tech teams can yield terrific results.