"Ideas are easy, execution is everything" is a favored quote in the tech world. Some MBA courses give students 24 hours to write 100 business plans in order to drive this point home.

All good execution starts with good planning. "Fail to plan, plan to fail" amirite? But you've also heard "plan small, plan often", and Agile preaches that circumstances will undoubtedly change, so deliver in small increments to allow for that. But how small, and what does a good plan look like?

Most people’s natural instinct is to start with what they know. Show early progress, build momentum, get traction. Sensical, but you’re setting yourself up for some negative surprise! Here’s another way to look at software projects: ask yourself how much entropy or unknown there is. It might come from working with a new language, a new system or module, new team members, new scale etc. Whatever it is, start there! Root it out, turn unknowns into learnings. The less unknowns there are the more predictable your delivery, and the earlier you find them the earlier you can do something about it without having to tell people your once bustling project is now very off-track and going to be late.

Most people either love them or hate them (and it’s certainly not a 50/50 split) but few people know how to yield them! And as a manager they’re going to be one of your main points of interaction with other teams across and up the org chart. So it’s best to get your head around them now!

Micro-managers love them, especially when they’re in senior leader roles. In our former lives both of us used to “enjoy” the process of day-by-day slips on projects that were late. I vividly remember asking why we did this, the new date was obviously wrong, and being told I’d be amazed at what deadline pressure does to productivity. And that same company had a lovely process called DFAD - a Date For A Date. I still remember the scowl when I asked about  DFDFAD…

The flip also happens, particularly with senior IC’s. It’ll be done when it’s done. While semantically yes that’s true, business (and life really!) doesn’t always work that way. So how to use dates?

The trick is realizing dates are a tool of focus rather than a deadline or even an absolute. Yes there are hard dates but the majority of them aren’t. They’re really just a way to keep track of a time budget, which is really just a proxy for a company’s real budget since no one works for free. Your company isn’t looking for the earliest possible date (we’re not fans of under promise, over deliver… but over promising is worse) but a realistic one so you can discuss trade offs meaningfully.

Express them in the level of confidence you have in it, if it’s sometime next quarter say Q4 not Dec 31, next month say November not Nov 30. By communicating your level of confidence you can facilitate more meaningful conversations around them with other teams and up the org chart, and you can help spot your own issues as things approach. And when you can do that, it demonstrates how well you’re on top of it, because you actually are!

As a general guide: if something is happening in the next few weeks - express it’s day, next couple months - it’s week, next couple quarters - it’s quarter. And if you can’t get to that level of confidence then you just found an opportunity to dig in and problem solve i.e. be on top of it!

This is why we made sure all dates in KATA have multiple levels of granularity so you can express what you mean. Because nothing ships on Dec 31 ;-)

As the Steve Miller Band will tell you, time keeps on slipping into the future. A great heuristic to prevent this from happening, and combat Parkinson’s law, is to simply create smaller containers for time to fill. When you’re halfway through a project, ask yourself, are you half done?

You can exploit this to your advantage much in the same way real estate developers do by subdividing large plots of land into smaller ones. For software projects they’re called milestones! While projects tend to be longer running, there should always be milestones around the corner. Time is always lost on the margins, so just make many small margins and you’ll find you lose less time than with fewer big margins. Follow the same date guidelines as projects for granularity. You have immediate pillars to make sure the team is focused on, and you’re fighting the time slippage of far away goals over the life of the project. Note if you exploit this too far you get diminishing returns and congrats you’ve re-created tasks :) Keep them to 1-2 week increments at a minimum.

We made milestones first-class in KATA and gave them a lot of upgrades because they are so crucial to fast, efficient projects!

Scope, quality, time… something something project management and the golden triangle of tradeoffs. I dunno, we’re not philosophers or theorizers, we’re practitioners. But if you’re having a scope creep problem, or dates are constantly being pushed back, try this: fix the effort. What’s effort? People’s focus for a period of time. We always assume that’s a variable, just don’t let it be. You have some sense of what’s hard/not hard, so simply create a fixed amount of time for a set number of people to work on something, and be very clear to them with what that is and the goal. And ask them to see what they can get done. Goes great with shipping incremental bits of progress and prevents time from slipping away. The 6-week cycle concept is an implementation of this.

Try to kill projects. That’s right, we’re saying to actively try to stop projects! Not make them fail, kill them. It’s a success. It means you avoid wasting time and energy on something that wasn’t worth it. This is so much of a problem today. Not enough people give a damn, and so we just do work because we’ve started. Just because we started doesn’t mean we should finish, our time and effort is too valuable! So try to kill projects, and if they should exist they won’t be killable!

How do you do it? Build in checkpoints to projects to make sure an explicit decision is forced to keep them going. I’m not talking about waterfall vs agile, that’s about scheduling mechanisms. This is realizing that projects don’t just begin and end, they evolve, they have a life cycle. So insert checkpoints at each lifecycle phase change to understand how it’s evolved, what progress and blockers were learned, and remind everyone what the original intent was and see if that is a bet still worth making. Because rest assured it IS a bet and so you need to be constantly evaluating if the ROI is there, don’t chase bad money with good money!

This is why we built phases into KATA projects from day 1. To make it clear and explicit where projects are moving through their lifecycle so you can check in at each stage and make sure it’s still a good bet!

A good friend of mine is an amateur car racer who builds his own cars as a hobby. He was explaining to me recently how there’s 3 things that win races, but they’re not all equal. There’s the power of the engine, just raw potential for speed. The friction and drag of the car, how streamlined it is, how grippy the tires are. These two are important, but eventually these things converge to what’s optimal. And often are highly standardized. But what really makes racing fun is the third factor, it’s the driver. You see this playout in Formula 1 all the time where there’s huge dollars at play. These race teams have optimized everything down to the nut and bolt, winning more often than not comes down to the human behind the wheel.

So how does this relate to building software? Well when it comes to team direction you, my friend, are the driver. And it’s not just about how fast you go but which line you’re on. Sometimes it actually makes sense to slow down a little, let someone pass, and take the inside one. Or speed up and pass on the outside. You get the drift.

So while tempting to just get going on a project right away, having everyone go as fast as they can, you’re going to end up with a lot of wasted cycles of people going in opposite directions or solving the wrong fundamental problem (because they thought it was the right one). While it seems slow, over the course of any project it’s actually much faster to start more deliberately. Bring everyone together and make sure it’s clear what the goal of the project is, what amount of effort budget we have, is fast and scrappy better than less fast but maintainable? How much scalability is needed? What’s the fundamental goal, maybe there’s some shortcuts along the way. Then set your team off running as fast as they can, just take the time to make sure it’s all in the right direction first.

One of our favorite ways to do this is with a project brief. It’s a short, usually 1 page doc that outlines everything, that is prepared ahead of time, and reviewed async. It’s never “complete” but “complete enough” to drive an alignment kick-off meeting where we work through potential issues, answer questions, make sure we’re all solving the same problem; in effect get aligned. And this is why you’ll find a spot for this on every project in KATA and a dedicated project phase for this type of activity!