Don’t let your team show up to the project management knife fight with a squirt gun

We often get asked by product & engineering leaders how we define a project. But we've never taken the time to write it down. So recently, I decided to change that, and here's what I came up with:

A project is a series of human, tool, and/or machine-driven inputs and outputs that add up to a specific outcome within some defined constraints (e.g., scope, budget, time).

Unfortunately, when compared to the reality of what we see with our customers, this definition drastically oversimplifies what a project entails. In many ways, it does a disservice to the people that have to manage them by underrepresenting the many variables within a project that need to be continuously monitored, synthesized, and communicated. We should try a different approach. Instead of defining a project generically, let's outline the attributes, challenges, and requirements engineering teams are attempting to solve for as they wire up projects in KATA.

• Projects have a core set of framing attributes, including a summary description, owners, contributors, followers, milestones, action items, and dependencies.
• Projects are usually assigned a name tied to the desired result, though it's the work required to achieve that outcome that defines the project's state at any point in time.
• Projects can be done in person, but increasingly they are worked on by distributed and asynchronous teams.
• Projects are cross-functional. They rarely align cleanly with an org chart. They often span departments, teams, tools, and time zones.
• Projects can vary in size and duration. They are usually a component of a larger organizational objective, like a goal or initiative.
• Projects are often defined by different phases they pass through over the course of their lifecycle. Something like Propose -> Explore -> Execute -> Validate. The names of these phases differ by company.
• Projects have events naturally occurring daily that mark progress. These critical checkpoints are often human-driven inputs like decisions, discussions, demonstrations, check-ins, status updates, risks, and escalations. Unfortunately, they usually get buried in the cracks of various tools, threads, and docs.
• People assigned to projects use various tools to accomplish the work required to complete the project. Similar to events, these tools, and the artifacts produced by them, serve as valuable markers of activity and progress or lack thereof.
• Projects have a status that often needs to be communicated on both a scheduled and ad-hoc basis through different channels (e.g., In-Person, Slack, Email) to various stakeholders, including executives, project teams, and individual contributors.
• Projects are dynamic, moving objects. The distributed, cross-functional, and asynchronous nature of project teams, all working within different tools, makes it challenging to stay on top of what's going on in anything close to "real-time."
• Project history must be preserved. New employees need to catch up quickly. Tribal knowledge on a project should not be lost when a key employee leaves. Rework should be avoided at all costs.
• Just as a project represents the collection of work that defines it, the collective project portfolio effectively represents the company's strategy. Understandably, companies want to scrutinize their project portfolio at different levels - some sort projects by goals or groups, others by initiatives, and others by teams.
• Projects often have named processes (Scaled Agile, SCRUM) or company-by-company protocols for how they should be managed. The former requires multi-week certifications to understand and expensive job roles whose primary function is to enforce them, and the latter often sees slow uptake after failed attempts at tops down process or tool standardization.

While not exhaustive, this is a pretty comprehensive list. Clearly, an attempt at a simple definition trivializes what a project is. They are complex & dynamic work containers, capturing all the contributions required to achieve an outcome against a specific set of constraints. And somehow, we expect project owners and managers to keep track of everything listed above, yet we arm them with a spreadsheet, task management tool, or some retrofitted OKR or roadmap tool. To overcome the limitations of these solutions and get the visibility they need to properly manage projects while continually gathering and communicating status up, down, and across their org, they resort to some costly combination of check-in meetings, ceremonies, and slack pings. Bogged down with this extra process, rework, and double (or triple) entry status "bookkeeping," it's no wonder that teams were seeing TPM team growth outpacing overall engineering. They've been showing up to the proverbial project management knife fight with a squirt gun. In the resource-constrained environment we're operating in now, this is no longer an option.

We have it backward. Project management software should empower the PMs, TPMs, and engineers working on and managing projects, not the other way around. In the context of project management, this requires a modernized approach designed for the realities of today's engineering organizations. In other words, project management without the management. This is what we're building with KATA. It delivers the highest value aspects of project management in a single platform – Automated Updates, Visibility, Human Signal, and Goal Alignment – WITHOUT the tedious overhead required to extract the same information from other tools.

Want to see what modern project management looks like in action? Sign up for the KATA Early Access Program today.