Three Project Management Principles

Here are three simple project management principles that any team can implement to improve the speed and quality of their work.

It’s remarkable how far you can get with only these three ideas—and remarkable how often the default project management habits push in the other direction.

The first is a simple one, and it’s to visualize work. This is what we do when we use a Kanban board or a tool like Trello.

I’m not going to go into detail on this one other than to point out that visualizing work is not the same as documenting work or creating tickets. In my experience the more an organization is obsessed with tracking every detail in Jira, the less visible the work becomes.

The second is to limit work in progress (WIP). This is a critical and often overlooked component to high-performing teams.

If your backlog is growing out of control, if it seems like it takes forever to get anything done and when things finally do ship they’re often buggy, the most likely culprit is too much WIP.

This is a hard realization because if we’re not happy with the amount of work getting done, our intuition is to ask for more. We start loading up the sprints with more tasks, so at least something gets done. This leads to a downward spiral.

If we consider our personal work we know that if we take too much on at once we struggle to get anything done. The same is true for teams, except in a team context the negative effects are amplified.

Here’s the secret power of using WIP limits: when you limit the number of tasks that can be worked on at once, it turns your workflow into a pressure system. The demand for new work puts pressure on what is currently being worked on and that pressure pushes work through the system.

The pressure works both by forcing focus on the WIP and by forcing teams to reevaluate the previous priorities.

Finally, the third principle, which is the opposite of how things are usually done: that the people doing the work should decide how the work is broken down, described, and represented.

This is part of a broader concept of empowering designers and engineers. It means handing these teams whole problems and letting them work out the solution. It means letting them self-organize and decide the best way to arrange the work.

In a narrower project management sense it means something like having designers and developers write their own tickets.

Many companies, often attempting to adhere to an outdated and misunderstood development methodology, create a division of labor where the special power of creating a Jira ticket is reserved for project managers or business analysts.

The problem is that the person defining the work doesn’t have a solid understanding of the work itself. The problem is compounded in the Ticket Factory approach to development, which creates incentives for more and more tickets and results in someone splitting up the work up front, often fracturing the project and putting boundaries between the wrong things (Ryan Singer refers to this as the paper shredder).

A simpler, faster, and better approach is to have people write their own tasks. In addition to improving the quality of the definition, it improves the quality of the solution by forcing designers and developers to articulate the problem themselves.