As the saying goes, “history has a way of repeating itself.” That said, a good historian looks back at what has happened previously and avoids the same mistakes. The above-referenced article deals with some of the main reasons why projects fail.
Definition: “A project is considered a failure when it has not delivered what was required, in line with expectations.”
The below are main reasons why projects fail per the referenced article:
- The wrong business requirements have been addressed
- It’s not possible to deliver the business requirements
- Poor governance
- Implementation is poor
- People lose focus on the project’s benefits
- The environment changes
At first glance, the first two failures seem almost too simple to be on the list. However, when you start reading through the article, you may find that these failures are easy to achieve. The news is always scattered with project failures that have addressed the wrong business requirements because the requirements weren’t defined correctly at the beginning. In addition to addressing the wrong business requirements, a poorly defined project has the risk of scope creep (expansion of the project scope) as well, often leading to costly and delayed projects.
Failing to recognize that it’s impossible to deliver business requirements is also an issue in the project definition stage, but it is easy to do. Business requirements may include resource restrictions, time constraints, or budget constraints. I’m currently working on a project that this is a major concern of mine. Often times, projects are started by someone higher up with a rosy picture of how the project will be completed. Unfortunately, these can be tough discussions with managers that are passionate about particular projects. I addressed the situation by seeking references with experience in the same type of project as well as defining the resource and activity requirements up front.
In my experience, poor governance can really be a pain and may lead to additional work and rework. I’ve been working on a project that several of the key stakeholders have not been that active throughout the project. Now that we’re nearing the completion of our RFP process, these stakeholders have essentially said “time-out” in order for them to catch up on the project to ensure we followed all of the required steps that they failed to give us at the project startup.
Lastly, I wanted to quickly discuss the environmental changes that impact projects. I would say that this is the most difficult of the failures to address. The article suggests (i) making timely decisions, (ii) considering smaller projects, and (iii) managing expectations as possible ways to manage environmental changes. However, these solutions aren’t always appropriate or may not apply. I worked on a project last year in which the timeline was based on the FASB/IASB (accounting standards boards) making a determination on a change before year-end. The board’s timeline was pushed out for another year or two which ultimately killed my project.
What projects have you worked on in which the environment changed and what happened?
This is a great topic to write about. Even on small projects at my job when I see people “fail” its always due to one or more of those problems listed above. People need to just stop and address the main prospects of the job if they want to do it correctly. Experience plays a key role in having a project done on time. Changing conditions will be no match with someone with experience. Great topic overall!
I have similar experience in terms of needing to catch up key stakeholders. I’m fortunate enough to work in a company that has pretty solid governance, so I thought I’d share a format that has worked for me. One method that has worked for me is a combination of weekly and monthly updates. Basically, the project team will work a full week based on the deliverables for that week. Then a Monday update is given on a conference call and web meeting, so the entire project team knows where we stand, and key representatives from each affected functional group can provide updates and information to those groups as needed. That does a good job of keeping the affected workers up to date, and we also have monthly meetings for upper management. Each month we have a meeting with all VPs and C-level management (an Executive Steering Committee) to discuss budget, timeline, risks, mitigations, and needs in terms of support. I know that may not be possible in all companies or for every project, but this method keeps everyone well informed. It also eliminates any surprises and leads to quick resolutions if the project begins to get off track, but the key is to not let these meetings run long or consume time that could be dedicated to moving the project forward.