A Different Way to Think About Digital Project Managers' Work

As I reach my four-year Vigeversary, I want to surface something that's bothered me for a while about how digital project managers are perceived and how we perceive ourselves. There's a gaping hole in the understanding of much of what we do.

People typically think of digital project managers' responsibilities as encompassing two or three broad areas:

• Managing logistics: Budgets, resourcing and scheduling, spreadsheets qua spreadsheets.
• Managing process: Process meaning a framework for planning and doing work, and the framework's components (tools, rituals, communication protocols).
• Managing relationships and people: Not I'm-your-boss people management, but literally dealing with and addressing personalities and interpersonal dynamics that arise when working with teams, stakeholders, clients, etc. This is either a third area or a subset of the first two, depending on your point of view.

PMs themselves think of project management responsibilities this way. Look at the agenda from last year's (awesome) Digital PM Summit conference — nearly every session was about logistics, process, or people. And certainly these subjects cover a large portion of many PMs' jobs.

However, there is another major area of PM work: the connective-tissue elements — stuff besides designing, wireframing, prototyping, coding, etc. — that are needed to turn ideas and feedback into a real product. I think of this stuff as the dark matter of web design and development. This work is pervasive and a huge part of many PMs' (and other non-devs') responsibilities, but nobody has formally articulated what it is. It's barely covered at conferences; there aren't books about it.

With this and future blog posts and presentations, I want to start illuminating the dark matter. By more clearly articulating this broad area of PM work, I hope we can bring more rigor to the learning, teaching, and execution of the work, and ultimately change the perception of what digital PMs do.

Project Managers' Other Work

Here's my best attempt to articulate project managers' connective-tissue work:

• Facilitating and/or doing definition
• Documenting/communicating that definition for implementation and testing
• Testing what was implemented

All of this work is centered around doing things so that an app can actually be implemented, and ensuring that it's implemented well. (I'm using "app" as shorthand for all types of modern software development projects.)

This work covers of a bunch of things that otherwise would distract developers from development and that other team members may not think of as part of their role (or that they may not know how to think about in the first place). Certainly devs — and UX and visual designers — can and should be involved in definition and testing. But there's a lot PMs can do to help with definition, and it's probably a better use of skills to have devs focus on automated testing and have others do manual testing.

Here's a brief introduction to each connective-tissue area.

Definition

Definition is the transmogrification of ideas, mental models, and pretty pictures into high-level project contours; a shared, consistent project language; and implementable details.

A zillion things need to be defined in order to plan and implement an app, from the high-level to the granular, including:

• Broad understanding of the work to be done
• The app's universe — its sites (e.g. public, admin), integration with external 1st- or 3rd-party apps or data.
• Users, roles, and permissions
• Views, i.e. user-facing pages
• CRUDable objects, their attributes (aka fields), and their associations
• Data surfaced on a given view, and the data's rules
• Hard-coded content on a given view
• Logic for a view's data and hard-coded content
• Interaction behaviors
• Workflows

Definition means something different for each of those things. Understanding what needs to be defined for all the things, and who can best do the definition, is key to being an effective project manager.

Documentation

Documentation is the communication of definition.

Documentation gets a bad name in an agile world, conjuring nightmares of old-school 200-page spec docs. One of the four principles of the original Agile Manifesto is valuing "Working software over comprehensive documentation."

But documentation is still crucial: It captures nuances, abstracted details, and decisions that implementers can't store in their heads or that are hard to convey verbally. And it makes those details available to teammates, clients, stakeholders, testers, and users.

Documentation can take many forms: sketches, annotations, sticky notes, whiteboards, tickets, slide decks, Google docs, wikis. Depending on the company or situation, project managers might not be the only or the primary documenters. But often we are.

PMs need to understand what type of documentation is the best balance of detail and efficiency for a given context; which details need to be communicated; and what the best structure/format is for a given piece of documentation.

Testing

Testing ensures that our implemented work is of high quality. There are many measures of quality, and hence many different kinds of testing. Project managers primarily focus on manual functional, interface, visual, and multi-screen testing.

Testing leads to further definition (of bugs, changes, and new ideas) and documentation.

PMs need to understand the different types of testing and who should be responsible for that testing on a given project. If we're responsible for testing, we need to understand how to test effectively and how to effectively communicate what we find in testing.

Toward a New Perception

Being a digital PM can be existentially stressful because our colleagues and industry aren't good at teaching us connective-tissue skills and thinking — which means we're often ill-prepared for much of our work. This perpetuates perceptions (by others and ourselves) that PMs are surface-level managers rather than in-the-shit makers, and results in work that's lower quality than if PMs focused as much on these skills as on logistics-process-people skills.

Expanding the understanding of PMs' work will therefore greatly improve our own lives, our companies' work, and the overall industry.

So I'm excited to flesh out this heretofore-mostly-hidden aspect of project managers' work. I'd love your feedback or references to things others have written in this vein, if you know of good ones!