July 16th, 2007

Why Project Reviews Usually Suck

Posted by Michael Krigsman @ 8:58 pm

Categories: Project management

Tags: Vernon Riley, Executive Sponsorship, Michael Krigsman

Vernon Riley asks, “Do You Want to Discover the Truth About Your Projects?,” as the lead-in to a discussion of project reviews. Vernon offers examples of how biased analysis prevents accurately understanding a project’s risks and potential failure points. Of course, lack of critical oversight ultimately facilitates denial and information-hiding, which is integral to many failure situations.

Unfortunately, it’s difficult to get under the surface of the dynamics that drive success and failure of any complex project. Many project reviews consist of simple checklists and progress metrics, which is fine as far it goes. However, these measuring systems often ignore more subtle warning signals, which is one reason so many failures remain undetected until large sums of money and time have been wasted.

On the other hand, there is a better way to analyze projects. Let’s look at this alternative, using executive sponsorship as an example.

Every experienced project manager knows that gaining executive sponsorship is critical to the success of IT projects. However, measuring whether the level of executive sponsorship is sufficient to support project success is not at all straightforward. In contrast, it’s relatively easy to measure more quantitative issues, such as tracking whether the project is correctly following a prescribed implementation methodology. The difficulty in measuring qualitative, organizational and political risk factors is one reason that so many project reviews produce virtually useless results.

When measuring an ephemeral concept such as executive sponsorship, it’s tempting to directly ask project participants whether their management provides sufficient support. However, that’s a loaded question and not likely to return an accurate answer. In fact, analysis conducted by Asuret suggests that such qualitative dimensions can best be measured when they are converted to observations about easily-described circumstances.

For example, one can measure executive sponsorship by asking project participants about the following:

• Management commitment
• Management role
• Project champion
• Management stability

Drill down into each of these issues and you uncover a piece of the puzzle. Aggregated together, these dimensions create a broad picture of an organization’s capability to support the degree of executive sponsorship required to drive project success. So, executive sponsorship can be measured on a relative basis by making an inference regarding neutral, objective, and describable circumstances inside an organization.

This technique can be extrapolated across all key dimensions that impact project success or failure. The result is a relative, yet quantitative, ranking of potential points of risk. And that, my friend, is the right way to conduct a project review.

If you’ve seen a more effective method for understanding the dynamics around non-technical complexity on a project (IT or otherwise), let me know.

—–

July 11th, 2007

Non-Technical Complexity

Posted by Michael Krigsman @ 11:07 pm

Categories: Project strategy, Tools, Vendor relationships

Tags: Software, Complexity, SAP AG, Michael Krigsman

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.