« "Independence and Objectivity are a Lot Like Virginity" | Main | Wisconsin Fights Failure »

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. 

Posted on Wed, July 11, 2007 at 07:07PM by Registered CommenterMichael Krigsman in , , | Comments4 Comments

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (4)

Michael, agree with your premise - but it is technical AND non-technical complexity which drives scope. At Gartner I wrote a paper titled Project Complexity, more than Product complexity drives implementation scope. If you are doing a global implementation with a lot of process and data change it will be exponentially more complex than a single site, no change in chart of accounts type of project even if both are using same piece of software. But software sales people are taught to still say oh cost of implementation to software is 1:1...

July 12, 2007 | Unregistered Commentervinnie mirchandani
Vinnie, your point is well-taken. However, the non-technical aspects are much harder to quantify and grapple with, which is why I focus there. Of course, it's nonsense to say that on an implementation with any complexity, the license to services ratio will be 1:1. Perhaps in some perfect, parallel universe that may be the case, but not here in the real world which we ordinary people inhabit.
July 12, 2007 | Registered CommenterMichael Krigsman
so software sales people are truly from Mars -)
July 12, 2007 | Unregistered Commentervinnie mirchandani
Unfortunately, the same people who write the specs for huge bloatware products are now designing equally bloated packaged services. Imagine if these guys were asked to create the specs for an oil change or a fall tuneup. Aargh.
July 13, 2007 | Unregistered CommenterTinfoil Hat

PostPost a New Comment

Enter your information below to add a new comment. All HTML will be escaped. Hyperlinks will be created for URLs automatically.

My response is on my own web site »
Author Email (optional):
Author URL (optional):
Post: