Non-Technical Complexity

Why do projects fail? Very often, the roots of failure lie in non-technical areas related to project management, organizational politics, and lack of consensus across stakeholders. In plain English, failures often occur when people with conflicting agendas can’t put aside their own narrow concerns and agree on a course of action that is best for the project as a whole.

AcceleratedSAP and similar methodologies have their place as a standardized roadmap for getting all the implementation parties on the same page, regarding the software deployment process itself. Vinnie Mirchandani has called this a “vanilla” approach. However, the usefulness of such tools for addressing non-technical complexity is highly limited. As a note, a company I started developed AcceleratedSAP, ValueSAP, Roadmap Composer, etc. (the tools, not the methodology) for SAP. Sure, AcceleratedSAP includes review points, but I would also question the objectivity, accuracy, depth, and completeness of those reviews. Lest anyone think I am singling out SAP here, the point is only to use them as an example. Virtually all well-established software companies have their own implementation methodology and process — the names may change but the problems remain the same.

Consulting companies often thrive on this non-technical complexity. Even a company as strong in their market as SAP cannot control greed and ignorance on the part of some customers and partners, which in my opinion is what drives many implementation problems.

As an aside, productized services do offer a way to align software customers and implementation service providers. For this reason, I believe packaged services are the way of the future for forward-thinking consulting companies.

Update: click here to see a discussion of one important technique for measuring non-technical complexity.