A big part of managing a software development project is monitoring and managing the risks involved. Software development is a risky activity. Remember that throughout our tumultuous history in software development, according to the Standish Group, one-third of all software projects get canceled and never see the light of day. This was true in the 1994 CHAOS Report, the 2004 CHAOS Report, and every other Chaos Report published to date. This is true regardless of the methodology used, team size, and any other factor we can think of because it doesn’t depend on development capabilities but is more reflective of the business environment we live in.
Things change. That’s a fact. When I asked developers why projects that they had worked on were canceled, they gave me a variety of reasons. They tell me that the needs of the market changed, or a competitor came out with a similar product before they did, or the team was reorganized, or any number of other things.
Change happens. Change is inevitable. And because most teams cannot keep up with change, primarily due to technical debt, they cannot respond, and the project gets canceled. One-third of all projects get canceled in software development. One third! That represents a huge amount of waste. This is waste in Waterfall that is never addressed. This is waste in agile that isn’t addressed either.
So far, we have not been able to deal with or improve the cancellation rate of projects. It’s like the movie industry. Nine out of ten films lose money. But that tenth film makes so much more that it offsets the rest. The movie industry looks for blockbusters, or at least they did before COVID.
I’ve always been somewhat envious of the movie industry. Every film seems so completely different, just like a computer program seems different from every other one, but somehow the film industry has been able to standardize what they produce. They have well-defined roles, and while they can take dozens or even hundreds of people to make a movie they all seem to work together seamlessly.
Not so in software development. We don’t have standard ways of doing things, and it seems like we are constantly reinventing the wheel. I often find managers measure the wrong things, and they often get a false sense of security from monitoring the wrong data.
We can’t think about progress linearly when we do software development. It’s not about how many keystrokes you type or how many story points you complete if the quality of your work is poor. It takes experience and skill to know what ‘good enough’ means in software development.
We are not striving for perfection. We don’t want to overbuild. We want to do just enough so that our users can benefit from the features we create, but we don’t want to put too much effort into things that are not of high value to our users. Finding the balance for what’s good enough can be challenging, but it keeps us from overbuilding.
To my mind, the first step in managing risk is to identify it, prioritize it, and find ways to mitigate it. In software, risks come in many forms. There are risks in misunderstandings, technical debt that can make it challenging to extend the software, and risks in trying something new. Some of what we build has never been built before, so there are inherent risks in researching and discovering new ways to do things.
Managing a project that tries to do something genuinely new and innovative is different than managing traditional projects. Sometimes we have to take a lot of faith, but that’s what it takes to create something truly innovative and new.
Previous Post: « Invest in Automated Tests
Next Post: Work Through Unknowns »