Posted 2020-01-18 23:00:00 GMT

Software projects often get stuck in billion dollar black holes of no results. Five years ago my boss's boss asked me how we shipped our big project on time. Since then we've shipped a lot more and I feel I've got better at it and shipped projects worth hundreds of millions at least. So how?

Partly it's working with incredible people willing to go the distance and get their hands dirty. But a lot is process.

Firstly, there's no point shipping if you're not shipping something good. So clarify what that means specifically for your project, identify the risks to that, work to estimate and control those, repeat and iterate.

There is an considerable jargon around project management: controlling scope, integrating feedback, identifying stakeholders, setting up a charter. These concepts are immensely useful for communicating about and addressing the typical dysfunctions that hold projects back.

However, much is papering over a failure to follow a simple cycle of impact driven development. I think largely because it is really hard as human beings to stay open to feedback, not get defensive and instead proactively keep looking for problems.

1. Identify risks. As a group gets larger it is harder and harder to do this. It's natural human behaviour to attack and ostracize people who bring up problems — especially if they are missing context. Instead, they need to be supported. In software projects, even the most junior engineer is an expert on one component and should be treated with respect. If context is missing, that is a failure of the organisation.

Risks can be anything: that there is no plan for a needed system, that a system has a crippling bug, that a team is missing necessary expertise, that a competitor is going to launch a better product, that a director is squabbling with a VP — anything that can impair achievement of the goals.

Seek out and hear concerns — wherever anybody might have a valuable perspective; this does not mean they all have to be dealt with.

2. Estimate and prioritize attacking the greatest risks. Get rid of luck. The biggest risks are the most inconvenient to deal with: tough conversations with the CEO about legal issues or potential public humiliation from putting a poor product on the market. Address these risks upfront.

Effort must be stopped on easy and comforting work that doesn't address a risk. As risks are managed, it is easier and easier to get people to help; that's when the comfortable work can start.

Seeing the most important risks get acknowledged and addressed is incredible for morale. It's actually really positive, builds trust, and makes people feel their work is worthwhile.

3. Repeat and iterate this risk management process continually. Larger groups are more and more vulnerable to group-think. Assumptions must be tested — with tests as realistic as possible to mirror the real world conditions after things have shipped.

The complexity and scope of tests should scale with the work: a financial computation needs unit tests against audited outputs, a system needs integration and end-to-end tests, a bigger system needs tests with realistic loads, a product needs market tests. The tests need to be targeted to help estimate the key risks identified.

These tests will bring up new risks that need to be addressed. Having a planning cycle that does not allocate time to these issues, or treats them as failures rather than opportunities means risks will be hidden.

Spending throw-away development effort on addressing risk is not throw-away work. It must be recognised appropriately. And testing must happen at rapid frequency so systems are built with the expectation that they are live.

This cycle of measurement and integration of feedback is really hard to follow. Addressing uncertainty is much harder than trying to define it out of scope. It feels chaotic. An ordered plan that never changes and never integrates learning is much more comfortable. But it doesn't make sense unless you are absolutely sure you know what you're doing — admitting you don't is hard but a death march is harder.