Solve The Delivery Problems That Plague Software Projects

Software projects are notoriously difficult to manage. Stories of projects delivered late, over-budget and/or defect-ridden abound. You have likely been involved in a few such projects yourself.

Many trainers and coaches claim to offer a solution to software delivery problems. However, before diving into the latest project management fad, it’s important to understand the underlying reasons why software is so difficult to manage.

The problems begin with requirements. There is a persistent myth that software requirements can be fully determined at the outset of a project. Despite repeated project failures traced to faulty requirements, we continue to believe that requirements must be fully documented before software development can begin.

The underlying rational is that we need to do a better job of defining requirements. If we can just get the requirements right, the rest of the project will be easy.

The next fallacy involves change. Changes are to be expected. You will need a rigorous change management system to define, track and control change requests. Unfortunately, most change management systems are really change prevention systems. They only cause more problems.

Where does change come from?

Any project lasting for more than a few weeks is likely to encounter technology changes. Operating systems, security systems, APIs, development tools, etc. will change and require that the team make adjustments. The alternative is to not upgrade the underlying software and risk deploying to the end user with old, possibly unsupported, code.

Competitive changes are a constant threat. If a competitor announces or ships something unexpected, you will be left scrambling to catch up. The only thing you can do is revise the requirements.

Business process changes are always looming. As management strives to improve productivity, reduce costs, react to new regulations, and deal with organizational changes, the software will need to adapt.

Resisting such changes is futile. Even if you succeed in preventing changes to the project plan, you will end up delivering software that is outdated before it arrives.

Another big trouble spot for software development teams is estimation. Any estimate is only as good as the data available and the assumptions made. Faced with changing data and questionable assumptions, project managers will often do their best to hold to the initial estimate. Bad idea.

As changes occur, estimates become less accurate. Even seemingly small changes can have a dramatic impact on an estimate. Force fitting the new information into the original estimate will result in late delivery, defective code or both.

Lastly, there is the problem of constraints, often lumped into non-functional requirements. These are usually a collection of “oh, by the ways”. For example, “Oh, by the way, the software needs to run on a five-year old PC running Windows XP and respond in under 3 seconds. That won’t be a problem, right?”

Every project has many such constraints although they are often poorly documented or just ignored – until delivery. Even when properly captured and documented, such constraints are common failure points. Predicting the behavior of a complex system at its outset is notoriously difficult.

Does all of this mean that software development is doomed to failure?

Not quite. Software can be delivered on time, on budget and with a high level of quality – if stakeholders and managers are flexible and fully engaged.

Being flexible means having a prioritized list of features and functions. What must be delivered? What would be nice to have but can be sacrificed to meet time and cost goals?

Being engaged requires active participation – especially for the stakeholders. Too often, stakeholders help with requirements then disappear for several months while the software is written. By the time they re-engage, some questionable decisions have been made and it too late to revise them.

These ideas fall into the realm of agile software development. While you may not want to embrace Scrum, XP or another agile variant, at least foster a culture that encourages people to be flexible and engaged. You will deliver better software, faster.

Updated: August 14, 2011 — 9:35 pm