I have been going back over a book I discovered some years ago related to vertical solutions and lean initiatives. It is entitled Lean Software Development: An Agile Toolkit  by Mary Poppendieck and Thomas David Poppendieck (Poppendieck, Mary, and Thomas David. Poppendieck. Lean Software Development: An Agile Toolkit. Boston, MA: Addison-Wesley, 2003. Print.)

Rereading sections of this fine book reminded me of some of the IT projects with which I have been associated over the years and just how UN-lean they really were—how much time, energy and money was part of project “waste.” In what seemed to be a counter-productive move to “save money,” the owner-clients often tried their very best to minimize the involvement of my organization.

 Maybe I’m to blame, partly, because for years I have been telling my clients—quite openly and honestly—about two very important facts that they should fully understand:

1. Neither me (individually) nor our organization brings anything to their IT project and POOGI (process of on-going improvement) projects that they could not supply in-house. We offer no mystical potion that makes IT projects cheaper or more effective. What we offer are simply these elements:
   1. Years of experience with IT projects in a variety of industries
   2. Knowledge of best practices—both in the realm of IT and business processes
   3. Domain expertise around the technologies themselves. These are all capabilities that might be had in-house provided the client has hired and retained quality people with the appropriate combinations of domain expertise and experience.
2. There is nothing “magical” about having a consultant on-site. Nevertheless, things do tend to be more focused when a consultant is present. This is due mostly to the consultant’s presence functioning as a catalyst. When the consultant is off-site, even if working “remotely” in some way or other, the staff of the firm tend to be more focused on “business-as-usual” rather than the POOGI project at-hand. When the consultant is sitting in their offices or in a conference room, the focus becomes “getting things done.”

In Lean Software Development, the Poppendiecks, mention the Seven Wastes of Software Development [p. 4], but I think many of these can be translated into all kinds of IT-related (and, perhaps, other) projects. Here’s my take on them.

Number 1: The Waste of Partially Done Work

Partially done software development has a tendency to become obsolete, and it gets in the way of other development that might need to be done. But the big problem with partially done software is that you might have no idea whether or not it will eventually work. Sure, you have a stack of requirements and design documents. You may even have a pile of code, which may even be unit tested. But until the software is integrated into the rest of the environment, you don't really know what problems might be lurking, and until the software is actually in production, you don't really know if it will solve the business problem.

Partially done development ties up resources in investments that have yet to yield results. In software development these investments are sometimes capitalized, and depreciation starts when the software goes into production. What if the system never makes it into production? Then there is a big investment to write off. Partially done software development can carry huge financial risks. Minimizing partially done software development is a risk-reduction as well as a waste-reduction strategy. [p. 5]

Even if an IT project does not involve software development, “requirements and design documents” for an ERP (everything replacement project) or supply chain integration project can frequently and rapidly get “outdated” as new requirements are discovered or changes in the underlying business model drive the project toward entirely new value propositions different from those that were anticipated a few weeks (or even a few days) earlier when the documentation was prepared.

Worse! If these changing conditions are not recognized, it is likely that the project will proceed toward “technical success” (i.e., the project was completed on-time and within the budget) while delivering little or no business value while the “investment” (costs) remained unchanged. The net result being little or no R.O.I. (return on investment) for the firm.

The, of course, there is the “middle ground” result—bad, but not quite as bad.

In the “middle ground” case, good progress is made toward a “technically successful” project but changing conditions are discovered late. Then, sadly, partially done development, configuration, training or deployment has to be “undone”—sometimes at considerable expense—while the project gets redirected toward freshly identified opportunities for profit. All, or a significant portion, of the partially completed work becomes waste.

Number 2: Extra Processes

Paperwork consumes resources. Paperwork slows down response time. Paperwork hides quality problems. Paperwork gets lost. Paperwork degrades and become obsolete. Paperwork that no one cares to read adds no value….

….Just because paperwork is a required deliverable does not mean that it adds value. If you must produce paperwork that adds little customer value, there are three rules to remember: Keep it short. Keep it high level. Do it off line.

….[T]here should be a constant search for the most efficient, effective means to transmit the information. [p. 5]

There has arisen a strange notion that paperwork and project controls actually reduce the risk of project failure. Unfortunately, far too many of the controls implemented are not oriented toward project success.

Instead, many of the controls are focused on one and only one thing: affixing “blame” if—or, when—something goes wrong on the project.

The problem is, as W. Edwards Deming so wisely noted relative to human behavior: “Anywhere there is fear, you will get bad numbers.”

If the POOGI project is driven by fear and blame, estimates and budgets will not be real. The will, instead, be bulked-up to protect the innocent.

As shown in the accompanying figure, fear leads to additional controls, and additional controls may (but not always) lead to reduced “problems.” The net result, however, is no additional value from the POOGI project, itself.

What makes a project a success, in my experience, is a collaborative seeking to deliver value as rapidly, as effectively and as soon as possible while recognizing that the value-proposition of the project will almost never be the same at the end of the project as it was when the project was first conceived.

Agility and cooperation is key.

To be continued.

We would be delighter to have your opinion. Please post your comment here or contact us directly.