Managing Projects and My Weird Brain

I was recently told by a client that I have a weird brain and might be able to come up with a creative solution to a newly-imposed budget constraint. Naturally, the ‘weird brain’ comment set me thinking about many areas of my life, but the key one I thought I’d describe here is how I manage projects.

At IC, we’re constantly building new systems and software to solve unique and difficult problems. We’ve adopted a particular flavour of Agile which is characterised by our Straightforward Billing. In a nutshell, this means that:

• we bill clients based only on the hours that we work, and
• we structure our agreements such that, at heart, the client simply buys blocks of our time (20, 40, or 80 hours typically)
• the client can pause the work at any time by deciding not to buy any more blocks of our time
• the work can change direction at any time, we just always work on the next most important things from a backlog which we sort in collaboration with our client.

This all means that we can approach projects very fluidly, which suits my brain very well.

Why fast matters

Over a decade ago I was struck by something I read in a book called Developing Products in Half the Time. Basically what I took from it was that if you’re developing a new product then you should acknowledge that at some fixed point in the future, which you most likely can’t control, that product will become obsolete. This may happen either because the world has moved on, or you or your competitor thought of the Next Big Thing. This means that you have until that date to sell as many of those products as you possibly can, and after that your sales will decline. This in turn means that every week or month that goes by as you’re developing the product is a week or month of lost sales that you cannot recover, because you always sell your products as fast as you possibly can, and the time you have to do so is now reduced.

These days, I work on software rather than the physical products that were the subject of the book, but particularly with our commercial projects the financial considerations are the same. With commercial software projects, there’s a day when the product is launched, and from then on people can pay money to acquire or use it. Software projects also become obsolete when the world moves on.

When you start to think about commercial projects with that perspective, then even if you’re only going to sell a few million dollars’ worth of your product each year, a week’s worth of sales, and the profit from those sales, comes to a substantial amount. So, on that kind of project, the cost of a delay is high when compared to the cost of our development team, which makes increasing the rate of spending on developer-time a wise investment if it can bring forward the launch date, or if it reduces the risk of having to put the launch date back.

Given that, and the fluidity enabled by our agreements, how do we go about going faster? A big part of it is foreseeing and avoiding delays.

Avoiding delays

As a matter of course when running any project we try to do things like divide tasks in such a way that it’s possible to have multiple people working on them in parallel, or schedule meetings sooner rather than later and so on. But considering that the potential cost of a delay is high vs the cost of development leads us to consider other options, for example:

• It can be wise to insure yourself against a delay by simultaneously pursuing two possible solutions to a problem, even though you know that (at least…) one of them will be discarded eventually.
• It can be wise to work ahead of time on things you know you can’t yet complete, so that you’re better prepared when the time comes to do them for real.

In fact, generally we find that starting a task is very often worthwhile even if you know not everything is in place for you to be able to finish. Starting a task always gives you a chance to learn more about your project. Sometimes starting the task reveals that it was a dead-end anyway and finding that out early gives you more time to adapt. Sometimes when you start a task you find that actually you don’t need all of the other things after all, and it turns out that you actually can finish it.

There’s also a particular delay-inducing mindset which goes something like “I can’t do X until I have Y, and as I don’t have Y yet, I can’t do anything” - too much of that and your project grinds to a halt altogether. I spend a lot of my time thinking up ways to turn that mindset around to find alternatives: “I may not have Y, but I can simulate it well enough for my purposes for the moment if I take half of Z and use it in this non-standard way, or if I quickly build this dummy version, or building this dummy will allow me to at least start X while I’m waiting although I know I won’t yet be able to finish it”.

The way I’m often approaching projects then is similar to the way I’d approach getting across the city if I was late for some unmissable event, like my child’s wedding. I’m constantly reevaluating my options, looking at the traffic ahead, watching for holdups or potential holdups, and rerouting as necessary and also using my spare time to check alternative routes on the off-chance that I may need to take them. Beyond that when I do spot a hold up I start to weigh up the cost of alternatives:

• Can I bypass the holdup by taking a different route?
• Should I just get out of my taxi, walk past the blockage then take a bus?
• If I have to wait it out, what can I do in the meantime that may save time later.

None of those things necessarily affect the event itself (except to the extent that I arrive in a more or less frazzled state); that’s only ever the last resort. Similarly with projects, the end result remains the same, it’s just the way we get there may change.

Adapting to changing flow

In a practical sense, the way that we manage these projects day-to-day is to work our way through a prioritised backlog of tasks. The developers are assigned (or can self-assign) tickets from the top of the backlog, and the rest of the backlog remains free to be reordered (or for items to be added, removed, combined, or broken apart) at any time. Because no one is too invested in those future tasks, it’s not a big deal for them to change. A technical lead (sometimes a small team) holds the technical vision for the project and constantly reviews the work in progress, notes and responds to any external changes, and resolves unexpected technical issues thrown up by the work as it goes on, updating the backlog to match the latest plan.

Because we’re used to constantly reevaluating and changing our plans, and because we have the contractual structure in place to allow any change in scope, when our clients request a change – be it an addition that they hadn’t thought of before, a request to rejig things to meet a tightened budget, or a need to respond to a change in the outsite world – that’s just business as usual. These changes, of course, happen very often, particularly with commercial projects.

The key elements that allow us to succeed with this level of change are:

• straightforward billing, because it means we’re not living in fear of having to make a contract variation for every tiny change;
• the way that we manage projects day to day, just working on the next most important thing; and
• the fact that constantly updating our plans is just what we do.

It turns out that the same techniques are valuable in making non-commercial projects run smoothly too, even though the financial motivation is not the same.

And my weird brain? Well, maybe it’s not exactly weird as such, I think it’s just that over time I’ve become so used to constantly changing the plan and thinking of creative solutions. It’s not just that having change thrust upon me doesn’t phase me, I actually kind of enjoy it.

If you’ve been frustrated by traditional project management or even clunkier agile approaches, then your project might benefit from our approach. If you’d like to discuss what’s possible, please get in touch: studio@interaction.net.au