Our blogs have stressed two themes above all others…

Our blogs have stressed two themes above all others…

  • That most companies really don’t understand how their business works as a whole before they initiate a project to evaluate, acquire, implement or upgrade an enterprise software system.

  • That companies who initiate enterprise software projects without understanding how their business works as a whole give up control of the project to sellers–consultants and software vendors.

A third theme that matters very much to buyers is that most enterprise software consulting is aimed at creating in the buying company a long-term dependency on a seller.

A fourth theme has been that the proper time – in fact, the only time – for truly preventing failure is before a project to evaluate, acquire and implement an enterprise software system is initiated. How have we stressed this theme? By showing, over and over again, that most failures happen because the work that might have prevented these failures are not done before contracts are signed and the project is set in stone.

We will add a fifth theme here that we haven’t mentioned yet. We invented no part of our general approach for preventing enterprise software project failures: We did not invent requirements analysis, preparation prior to the involvement of sellers, or (especially) the concept of managing contractors through detailed statements of work (after all, the aerospace and defense industry, which invented the practice, could not function without it). What we did invent is an organized, reusable approach for applying these tools to most any kind of a business project and especially the specific problem of enterprise software project failures.

Why does this fifth theme even belong here? Because, in the context of enterprise software projects when failure doesn’t happen, it is because the buying company avoided it by doing, on its own, something very much like what we’ve packaged in our product.