On how things get done

A confession: I am not a project manager. A second confession: I don't even like project management. A third confession: I'm not even convinced that most projects need formal Project Management.

I'm going to let you in on a secret: I think the majority of the work of good project management happens up front at the very beginning. If everyone involved in the project has the same picture of success from the very start and the same idea of how success will be evaluated, a foundation has been put down that allows for a lot of diversity of approach and flexibility in execution. Without that shared view of success, there are a few issues that can crop up:

1. component overperformance, system underperformance - without a clear view of overall success, it's a lot easier for people to push exclusively for success in the area that they own.
2. misaligned scope - even simple projects still tend to have at least a few different moving parts. When the big picture of success isn't clear, every person might have a different view of what it takes to get there and what they need to do.
3. lowered expectations - if success isn't clear from the beginning, there's likely to be inertia that drags everything down to a level below what it ought to be. To be honest, this often happens even when success is clear from the beginning. Without it, teams can end up making marginal optimizations when they need to make significant changes to reach the right threshold.
4. the cult of busyness - defining success helps to clarify for everyone involved what really matters. The absence of that definition makes it easier to default to doing things just to keep busy, without any deliberate thought to how it contributes to success.

This foundation isn't a guarantee of project success, in the same way that a stick of butter isn't a guarantee that you can bake a great cake...but good luck without it. On top of that foundation, success needs to be broken down into the different outcomes that build up to top level success. And then the people working on the project are entrusted with outcomes, not with tasks - but the team as a whole is entrusted with the overall success of the project.

Taking this approach at the beginning also affects how the project leader operates during the duration of the project. The biggest shift is that the project leader delegates responsibility for outcomes to the members of the team, not responsibility for tasks. As a result, the project leader also ends up engaging with team members by coaching them towards the outcomes rather than dictating the activities they need to do to meet those outcomes. The difference on this is a little nuanced, but very meaningful: coaching towards outcomes involves asking questions and keeping someone anchored to the outcome they are trying to achieve; dictating activities ultimately just becomes task-based responsibility rather than outcome-based. As the leader, it is often more difficult to coach towards outcomes, especially because in the short term it feels less efficient - you might actually know better what your team member needs to do - but you don't have to extend the time horizon too far to see how outcome-driven coaching ends up outperforming task-driven. When you coach towards outcomes, the people responsible for those outcomes become more capable of thinking through challenges and defining strategies.

There is a natural question that arises here: how does a project leader know how much responsibility someone can handle? My glib answer is that a person can handle a bit more responsibility than they have handled successfully in the past. Of course, you don't always know where that line is right away, so you need to make your best guess and be on the lookout for signs that they are thriving as well as signs that they are struggling. In my experience, the major signs that someone is struggling are:

• they lose sight of the big picture and get stuck in minutiae
• they can't make decisions
• they aren't asking good questions (and especially so if they aren't asking questions at all)
• shared work in progress isn't on par with previous work

On the flip side, signs of thriving include:

• proactively sharing work in progress for specific feedback
• identifying and sharing important insights
• asking good questions

Ideally, a project leader wants to be able to get a read on whether someone has the right scope of responsibility as quickly as possible - almost certainly within a week or two of them taking on new responsibility.

The second shift as a project leader in this construct is toward harmonizing the people, and the outcomes. The reality - either fortunate or unfortunate, depending on how you look at it - is that the picture of success from the very beginning is almost certainly going to change before the end. That means some of the outcomes will change, some of the initial scoping will change, some of the timelines will change. The only constant is change. The project leader is the person that needs to ensure that all of the change remains directed at the right final outcome and that change in one part of the project is reflected in the other parts of the project.

An implicit assumption embedded in all of this (that I'm about to make explicit) is that a project needs good rhythms and routines. Rhythms are what allow for adjustment, correction, and change in general. They provide a forum for ongoing calibration and alignment. They create space for shipping and sharing the pieces that come together to make the whole. (When not done dogmatically, I think this is still something that the Agile approach gets right. When done dogmatically, the agility gets squeezed out of Agile and it just becomes short cycle waterfall). The right cadence and frequency of the rhythms and routines depends so much on the kind of work, the context, and circumstance; but the underpinning question should always be, "What's the amount of time we need to tackle a meaningful piece of this project?" Sometimes it's 2 weeks, sometimes it's a month. It's almost certainly not longer than 6 weeks. There's some room for trial and error in figuring it out...and it's probably just a little bit shorter than you initially think. The other thing to be careful with is that those rhythms and routines don't turn into the tail wagging the dog: they are always meant to enable the team to do their best work, not to stifle work with too much process. As a general rule of thumb, if you're seeing bad process compliance from a well-intentioned team (and especially from people that are, nonetheless, delivering good work), there's something wrong in the process - either it's too much, or it's poorly designed. Again - this all goes back to the beginning: process exists to enable the team to succeed. When you know what success looks like, you can see when processes work to help the team move toward success versus when they act as an unnecessary impediment.

As a final note, I want to point out that this approach to project leadership uses people as the organizing principle. It assumes that project success comes from bringing people together in a way that produces gestalt - when the whole is greater than the sum of all parts. There are some projects that might be more purely process driven, there are some projects that actually need very formal and detailed project management. But there's an assumption that most or all projects need that, when there are a lot of projects that need a handful of people to come together in order to achieve something meaningful. The spirit and intent of formal project management still applies, but the approach needs to shift dramatically to reflect the more relational, interconnected nature of that kind of project. What I've laid out here is the thinking that has served me well, but it's not a rigid dogma or highly specific approach. It still requires a lot of the project leader - but those requirements are more about understanding and harmonizing people, rather than details and activities.