From Projects to Products in Enterprise Applications

The Project model commonly used in custom-built enterprise applications is fundamentally flawed. In Chapter 3 of their book Implementing Lean Software Development, Mary and Tom Poppendieck suggest that this type of software would benefit greatly from following a Product model instead.

Projects have a beginning and (apparently) an end. Products, on the other hand, have a beginning and (hopefully) no end. Software is much more like a product than a project, because most good software lives on and changes for a long time.

Projects are Waterfall

It is now common knowledge that waterfall software development doesn’t work. And yet we ignore the fact that the idea of software development as a series of steps with inputs and outputs came directly from traditional Project Management theory. In 1982 Dan McCracken and Michael Jackson published a note in SIGSFOT titled Life cycle concept considered harmful. They said:

Any form of life cycle is a project management structure imposed on system (software) development.

Software Development and Project Management are often confused but are clearly distinct, as shown in the table below from Leading Lean Software Development.

Let us not confuse

Software Development

Project Management

Success = accomplishing the system’s overall objective Success = achieving planned cost, schedule, and scope
Learning/feedback cycles Phases with exit criteria
Quality by construction Quality by inspection
Encapsulate complexity Manage scope
Skilled technical leaders Resource management
Technical disciplines Maturity levels
Historically Robust Historically Fragile

It is clear that projects are incompatible with Agile practices.

Projects waste money

One of the main reasons for projects being inherently waterfall is budgeting. Projects get all their money allocated at the beginning and their success is measured against that budget. This encourages Big Requirements Up Front to be able to come up with an estimate. We know we suck at estimating anything but we do it anyway.

The Standish Group’s “Chaos Report” found that only 31 percent of IT projects are reasonably on time and on budget and that on average projects cost 189 percent of what was originally estimated. These results belie the beliefs that fixed-price projects put a maximum on the financial outlay.

Is Fixed-Price Software Development Unethical?

An even bigger concern with budgets, particularly in the public sector, has to be the culture of ‘spend it or lose it’ that they foster.

One problem with cost budgets is that they are viewed as entitlements, so they act as a floor as well as a ceiling on spending. Similarly, the problem with plans is that Parkinson’s Law holds: Work expands to fit the time (budget) allotted.

Leading Lean Software Development

In contrast, Products are usually funded incrementally.

This incremental funding is a clear signal to all that the scope is expected to evolve as knowledge is gained. The success of product development is generally measured based on the market share and profitability that the product eventually achieves.

Implementing Lean Software Development

It is interesting to note the emergence of Beyond Budgeting as an alternative to traditional management practices, including budgeting, and how well their ideas align with Lean & Agile thinking.

Projects have no champions

People are moved (or sacked) between projects with no regard for the impact on the development process. Decisions are made not in the best interest of the customer but only to satisfy a project plan or a budget. Developers get accustomed to not finishing anything and don’t feel any responsibility for the code they write. They leave large amounts of unfinished code and ideas behind them.

Joel Spolsky puts it this way:

As soon as your program gets good enough, you have to stop working on it. Once the core functionality is there, the main problem is solved, there is absolutely no return-on-investment, no business reason to make the software any better. So all of these in house programs look like a dog’s breakfast: because it’s just not worth a penny to make them look nice. Forget any pride in workmanship or craftsmanship.

In this context it is impossible to have a Product Champion, Front-line Leaders or any kind of leader for that matter.

A product company on the other hand is forced to continuously improve its products to remain competitive. Developers are encouraged to find new ways to make the product better, easier to use, nicer, more robust. This keeps them honest and sharp.

All the innovation that results from competition in the marketplace ultimately benefits customers. None of this is present inside the enterprise walls but that is no excuse for sloppy software.

Just because software is being developed for a one-of-a-kind application does not excuse an organization from the obligation of creating value and delighting customers. The objective is still to create software that will deliver outstanding value to the organization that is paying for it.

Implementing Lean Software Development

In the public sector anything less than top-notch quality software is an irresponsible waste of tax-payers money. This level of quality will only be achieved when we start treating software as a product that needs to be sold to our business areas.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s