Preventing Project Failure

The Truth is Out There

No silly, not Area 51, the truth about how to keep your project from failing is documented just about everywhere.

I’ve Been reading a lot about this lately and I see so many commonalities and connections in theory and metrics on project failure, that I’m compelled to say that, should you want to, you’d be able to connect the dots quite easily. The top reasons for IT project failure are well summed by the National Audit Office(NAO) of the UK, who incidentally is currently in charge of audit on the UK’s attempt to convert all their health systems into one large integrated database, arguably one of the largest IT projects ever attempted. Reading about it kind of makes you scared to start IT health projects here.

Back to project failure, the National Audit Office came up with 5 risk factors as indices of potential project failure.And a few fellows at the University College of Londonmeasured their project success rates against these 5 risk factors and found good correlations. They describe these keys as follows:

Design and definition failures - the required outputs are not described with sufficient clarity so the end goal is not achievable,
Decision making failures - the project fails due to lack of a single responsible owner who is able to make decisions about the project,
Project discipline failures - project documentation replaces project management with poor arrangements to identify and manage risks properly,
Supplier management failures - the project fails due to lack of understanding between the supplier and the customer,
People failure – occurs when the project delivers as specified, but the project does not fit the business or clinical requirement.

I would change People Failure to ‘Intent Failure’.Meaning that the intent of the project was not achieved even though the project was delivered. KPMG calls this ‘unrealized benefits.’

And I would like to add a sixth factor:

· Quality Assurance failures – Failure to thoroughly test for quality, stress, and load.

This is sounding similar to Andre Choma’s recent presentation at the EMEA PMI Conference on the Top 10 ways to Sink a Project.

Making theory usable:

So with all these resources available, I think the prevalence of IT Project Failure means that these ideas are not efficiently translating into practical and usable tips for the average IT Project Manager. With that thought in mind, I’ve decided to start a blog series focusing on one risk factor per blog. The idea is to provide tips and examples from real life of how to mitigate for the risk on your projects.

Today’s topic: Design and definition failures

Tip 1: Start with a super clear Project Charter. Clarity in a Project Charter is so very important. I’ve always made sure that my Project Charters included the following:

A description of the problem to be solved. The Charter should fully describe the problem to be solved, in detail. I often find this the easiest piece to write because its basically the ‘complaint’ section of the narrative and I’m good at complaining. Read my post about how complaining can help you find risks, because complaint can also help you find the business problem.

Example: (Note – the example language is taken from a real-life project)

The CEO is the command authority for the ABC Corporation. On a daily basis, The CEO will receive highly critical and important communications from over 10 sub organizations. The CEOs quick action and response is usually required on various items. The primary method of communication used by sub organization staff is email and includes PowerPoint decks, reports, charts, maps, and project updates. The CEO’s time spent sorting through email produces the following outcomes:

· Reduces the amount of time to make key strategic decisions

· Carries inherent risk that important information may be missed in voluminous email traffic

A 2 or 3 sentence scope. Even on the largest projects, you should be able to state what the end goal is very succinctly. I’ve found that when I could not do this, my scope was either too large or too fuzzy. So my practice is to force myself to say the purpose of the project in a 15 second elevator pitch. I’m currently reading the Dod’s Capabilities Based Assessment User’s Guide which I will blog out a bit later. But what’s fascinating for me is that the DoD has created a business problem definition process which forces the DoD to describe the business problem in terms of a capabilities required, rather than in terms of the ‘thing’ that is required. The Guide says “…replace statements such as “we need a more advanced fighter,” with, “we need the capability to defeat enemy air defenses.”” (page 5).

Example:

The CEO has envisioned a central executive level dashboard of information that will serve a primary hub of communication and one stop shop where the CEO can quickly and immediately discern and respond to important information.

Note that this scope is written in terms of capabilities ‘primary hub of communication’ and does not specify the product to be used. This scope document could just as easily have said, “The CEO needs a Sharepoint dashboard.”Stating the technical solution in the scope document can mean a loss of the business requirement. I believe the DoD discovered this issue which is why they focus on capabilities, rather than requirements.

A link to an existing business objective. Link your project to company strategy. If you can’t link to any of the existing strategies, that’s your clue that you may encounter buy-in risks or lack of executive support. This is what a friend of mine calls the ‘Give a S***’ or ‘GOS’ factor. If you can’t explain why an executive should GOS about your project, you need to really re-think the necessity of the project. At a minimum, you should raise the issue during scoping with the project sponsors and if they push back, make sure you log the risk in your risk register.

Example:

This project is linked to the CEO’s direction that ABC organization create and manage a more efficient, organized and productive way to receive critical information and disseminate key decisions quickly.

Measurable success Criteria. Begin with the end in mind. How will you measure that you’ve project is successful? If you have a clear business problem, this should be fairly easy to do.

Example:

The following criteria will briefly describe the measurements of item completeness for the successful implementation of the CEO Dashboard application:

1. Proven usage and adoption by the ABC organization over a specified period of time. Metrics on usages should be gathered from all levels including Sub Organization Heads.

2. A Six Sigma analysis of the key indicators of efficiency gains over time.

3. A repeatable content management process that includes continual updates to the application via controlled change management and code releases.

Keep it Short: The Project Charter is not the project management plan. It should be brief and to the point so that it can be vetted through executive levels quickly. I know some may take issue with this, but I have been able to build enterprise wide web applications off of charters less than 10 pages long.

Signatures by all parties involved. You’d be surprised how much your scope will change when you walk it around to vet it through your organization. This is what should happen however. Your scope will change because you’ll be informed of those things that may already be able to solve the problem and you’ll realize unmet needs that people want addressed. Honestly, the Project Charter process and getting to agreement should be a fairly lengthy process and there should be plenty of re-writes due to vetting. If not, you will probably be forced to re-write your scope later, in the form of scope creep or requirements change.

Tip2: Don’t re-write the wheel. There are plenty of places to get good Project Charter templates:

Gantthead.com
ProjectConnections.com
Here’s a fun sample I did for the Declaration of Independence
The DoD’s Capabilities Based Assessment documents the full project scoping lifecycle. Bits and pieces may be useful to you – it’s a long document.

Tip 3: Don’t underestimate the visual

If you’re like me, you’ve been raised to read and understand, not viewand understand.  In grad school, I read lots and lots of books, with no pictures, some with just a few graphs. So relying heavily on pictorial representations of anything feels like fluff to me.    But this is a new world, where executives use pictorial dashboards, like the Feds new IT Dashboard, and where inches and placement on 15 inch screens can influence a company’s bottom line.

In the past, application requirements consisted primarily of application functionality and data requirements.  But now in this web based age where 95% of applications have a web component, usability requirements, including screen placements, application navigation and user task requirements can make or break an application.   In other words, you may have built the workflow correctly but if the sponsors don’t like what they see, they will push back.

Worse case scenario; if you haven’t vetted a look and feel with your sponsors before you build, you exponentially increase your risk of re-work as they most likely will not accept your design.   Re-work then pushes back project schedules and increases cost.

To avoid this scenario, employ best practices in usability and web prototyping before you begin your project.  Usability.gov provides a wealth of information including requirements analysis tools, design tips and federal government compliance information for web design.    I am currently modifying my project plans to incorporate design assumptions, and to add milestones for look and feel approval to schedules.

The most important thing to remember here is -  get design approval before you build.

• • Comments [4]
  • Tags [project failure, Project Scope]
  • Categories [Controlling Scope, Making Theory Usable Series]