Project Management

Project Management, like the computer itself, has evolved and gotten better over the years. Manage your software project with the state of the art techniques.

There are two primary project management styles employed when building software projects. The first is known as “waterfall”. This is a traditional management system where all planning is carried out and those plans “fall down” to design, then development, then delivery to the customer. A better term for this project style would probably be “cascade”.

Waterfall projects would work wonderfully if the world were perfect. They allow you to estimate both the cost and timeline for the project. But the plans, design, and construction are seldom 100% correct. And defects toward the beginning of the process (eg in planning) have a compounding effect on the cost to remedy the issue. Even home construction, which we’ve been doing for hundreds of years, tends to have 20% overrun using this process.

In fact, the holy grail of waterfall projects is a perfect scope that never changes during the course of the project. Only then can we hope to have an accurate budget and timeline for the project. Sadly, this is just not possible and on average only 16.2% of software projects are developed on time and within budget. This is shocking because a massive portion of the project budget is spent during the planning phase.

To solve this problem you can double or triple the estimate and timeline or use cost-plus contracts. Both are known to be terribly wasteful and expensive. Usually only the government can afford to be so wasteful.

An alternative way to run a project is something called “Agile”. Unfortunately the term agile is lousy at describing how the project management process works and is more of a description of the problem it’s trying to solve: project flexibility so we can respond to scope changes on the project.

Agile should probably be called “budget based mini-cascades”. We assume that the scope of the project can’t be known. So we don’t bother with a full project scope, and instead focus on small planning sessions that lead to small amounts of design and development. Instead of the design and development happening after all planning is done it happens right after the first small plan is created. We still have a cascade, but it’s a piece of the project rather than the whole thing. The timing between the stages is short. And the delivery of the first working software happens quickly, not at the end of the project. By combining a bunch of mini-cascades, often called sprints, you build a complete project.

This has many benefits. First, the amount of paperwork needed during planning is greatly reduced. This is because the design and development will happen right away, eliminating the need to capture exhaustive detail in scope documents for later. The time saved here can be tremendous. Second, Agile allows for validation and correction as the project progresses, not at the end when it may be too late to fix a mistake affordably. Third, working software is the measure of success, not scope documents or design file creation.

The down side of Agile is that an estimate for a complete project is hard to come by since there is no complete project plan (which is used to generate the estimate). The solution to this is two fold. First we start with a budget and reverse engineer the project to fit the budget. This allows you to plan, design, and build only the things that fit into the budget with very little waste. This allows the scope and timeline of the project to evolve while the budget remains fixed. The second is that we constantly release valuable software. So even if the full scope of the project can’t be known and estimated, we know that for each dollar actually spent we are extracting its value.

So with an Agile project, what you are actually purchasing is an expert team that is committed to working in a cost effective manner alongside you, similar to Lean Manufacturing.