Why do Projects Fail?
I imagine most readers have been involved in projects that have failed or, at least, not gone so well. Over the years I’ve seen a number of them and let’s be honest, I’ve probably caused one or two as well! But the bottom line is, clients are not bringing project management consultants in because, “things are going great!”, “everybody’s getting along with love, peace and harmony” or “the project will be delivered on-time and in budget”.
Recently I worked with a client that had spent $800,000 on a project that was basically going nowhere. They asked me to come in and conduct an analysis.
The first question I asked was, “do you have a Scope Document or maybe you call it a ‘Project Charter’ or Project Initiation Document or anything that defines the parameters, assumptions, specific and measurable deliverables?”
Well you can guess the response. It was, “No”. .
When I asked why not, they said the project was developing an intranet application. That it was dynamic and fluid, and therefore they felt they didn’t need one. I could smell the “B.S.” right away.
So the next question I asked was, “Did you do a formal Risk Analysis?” They hadn’t done that either, although they were using some complex technology, I found the only person who knew how to program that technology had moved to San Jose. This was certainly a foreseeable risk!
I then asked, “Do you have a Project Schedule to plan what you didn’t know you were commissioned to build?” In fact, they did have one – they pulled out 18 pages from Microsoft® Project that could only be defined as garbage. There was no comprehensible work breakdown structure or any other type of work package. The resource list showed all kinds of over allocation and none of the tasks had been updated. So, we decided to start over from the beginning and define the objectives. Once the objectives were defined in specific and measurable terms, we didn’t merely create a project to achieve those objectives, we did an “As Is Analysis” to determine their current situation.
After a few site visits, the analysis showed they already had a solution that satisfied 80% of the now known objectives. I asked, “Good enough?” The client said, “Good enough!” and they pulled the plug on that bizarre project and saved $1.2 million dollars.
Who are the Project Stakeholders?
The Project Stakeholders are those parties impacted by the project and have an interest in its outcome. They may include the people who establish project deliverables and constraints, and implement the strategies and schedules. Examples of project stakeholders include project sponsors, project managers, line managers, team members, customers (internal and external), outside agencies and vendors.
It can sometimes be an overwhelming challenge for a project manager to juggle all of the stakeholders. It can also result in a lot of frustration if one does not identify the key project stakeholders upfront. The lack of identifying them in the initiation stage will probably result in them identifying themselves during the execution stage and could result in changing the overall direction of the project.
So, it’s important to understand whose expectations we should be meeting and to identify not just one of them, but to ensure all the key stakeholders have been properly identified.
In working with a major association, I was called to determine a problem with the system they’d implemented. I found the system was highly customizable but the project manager had not identified all of the key stakeholders. He had only identified one of the four. And in turn, had built and implemented the system to satisfy only that key stakeholder’s overall needs.
The other three (or 75%) directors weren’t at all satisfied with the solution. They thought it was a technology problem. We quickly communicated it wasn’t a technology problem – it was a problem with the project manager not being able to identify all the key stakeholders; therefore he didn’t define all of the requirements and of course, the system wasn’t meeting the requirements of all key stakeholders.
Over the years, I have developed an acronym to help us identify key stakeholders. I’ve defined those as:
the people with the Money – sometimes this is the people with the money or the budget-holder; the people with the Authority to deploy the resources or the authority to say yes or no; a party that represents the end-user or the person who’s going to Need the product or service that is being implemented.
So, we’re looking for the MAN, but we also don’t want to forget we need to identify key stakeholders who have the Willingness and Optimism to work with us in a spirit of co operation. So the real project key stakeholders are defined as the W.O.M.A.N..
What are Their Expectations?
Very often, there is a limited time to perform a needs analysis. Therefore, it is essential that you have a framework for structuring your questions and collecting information. The following baseball example is an excellent framework.
For many years, I have used this baseball framework as a method for gathering requirements and understanding a client’s current situation, future needs and existing problems.
Recently, I was asked to do a diagnosis of project management processes and solutions that were being employed by a company involved in the software development for healthcare insurance.
Going to ‘First Base’, I interviewed 18 people about the current situation. I discovered they basically had a few forms that they filled out. They closed projects when the customer stopped calling.
Well, I moved forward to ‘Second Base’ to discuss future needs.
Their response, “… we’ve bought 300 licenses of Microsoft Project®. We’d like to know how to use it. We’d like to know how to do a risk analysis, to have clear, concise and consistent scope documents and to manage change”.
I then moved to ‘Third Base’, because even as a hockey player I learned that you can’t run to home plate from second base and score a run, if you skip third base.
From my third base perspective I asked, “What kind of existing problems are you facing?” And they indicated that they were hit during their last quarter with $500,000 in penalties for late implementations. They also estimated they left approximately $750,000 of billable work on the table. In other words, they had a customer calling and requesting a change. They couldn’t really prove to the customer it was a change in scope because they didn’t have a scope document. They were feeling guilty because, well, they were running late; therefore, they would say yes.
|