I’m sure you have all seen these types of lists on various websites or in your twitter feed (or maybe you haven’t because you subscribe to more interesting types of content than I do), because there are many of them out there. In fact, they write books and publish reports about this sort of thing. Why? Because projects keep failing and we keep trying to figure out what we can do to ensure that OUR projects don’t fail. (Editorial note – I realize that even the term ‘failure’ can be quite subjective and they write books about that sort of thing too).
So, why DO projects fail? Good question, right? Here are a few reasons, from my experience.
1) Unrealistic schedule and/or budget
Ok, this was an easy one so I won’t spend too much time on it. It is worth noting, of course, since it often happens that project schedules and/or budgets that are put forward to ‘win the business’ are often challenging to deliver on by the project team. That said, seeing these sorts of gaps – between what the client is dictating, or what a proposal team thinks is necessary to win a bid, and what a delivery team thinks is realistic – should be thought of as a trigger to review and ensure that delivery processes are as efficient as possible so as to close this gap. Do we REALLY need 3 months to deliver this feature that the client or proposal team thinks we should be able to deliver in 2 months? Maybe the answer is yes, but maybe it’s not. Is there a better way?
2) Poorly Defined Requirements
Ok, this is a bit like shooting fish in a barrel but no list of this sort would be complete if there wasn’t at least a mention of what seems to be everyone’s favorite reason for project failure. As anyone who has ever worked on a project can attest to, there are varying degrees of requirements and an infinite number of ways things can be interpreted. (This cartoon does a nice job of summing that up, I think). Depending on the methodology you favour (i.e. ‘Waterfall’, RUP, Agile etc.) you may have different views on how best to capture and manage requirements but regardless of methodology, common sense should tell you that there must be some level of agreement between the delivery team and client as to how the schedule and budget are going to be spent. (You wouldn’t ask a contractor to build you a “house” without ensuring there were a set of blueprints that you have reviewed and signed off on, would you?)
That said, far too often we find ourselves on projects where budgets (sometimes unrealistic ones – see #1 above) can’t support the creation of requirements that will help to ensure there is a ‘shared vision’ of the solution before it is developed, or with project schedules (sometimes unrealistic ones – see #1 above) that are created such that development must be expedited! in order to meet an externally imposed milestone date. Is it any wonder that projects end up over budget, behind schedule or with clients that are unsatisfied with the results?
There is no, one right answer, however when it comes to requirements, like many things, it’s about communication (see # 4 below). Communication between the client, stakeholders and team to figure out how best to come to agreement on getting the delivery team a CLEAR road map to deliver against, AND ensuring that there is adequate* (see last section of #1 above) time and budget allocated in order to do so.
3) Poor Role Definition
While budgets and schedules can sometimes be imposed on project teams, defining the “who’s doing what” is something that should be completely within our control. Even though this should be the case, quite often projects find themselves over budget, or behind schedule, or with sub-par levels of quality because, quite simply, people didn’t know what EXACTLY they were responsible for. The result? Well, there can be many. 1) People don’t get invested in the project 2) ‘Something’ doesn’t get done. 3) ‘Something’ gets done by a combination of people which results in a) more time spent on a task than budgeted b) no true owner, accountable for the result.
Defining roles sounds like a bit of a no-brainer, right? Designers, design. Developers, develop. QA testers, test. Easy. Well, while this is true to a certain degree, it’s all the little bits in between that can mean the difference between project success and project failure. When defining roles and the various nuances that can exist within and across them it’s CRITICAL that clear ownership is established so that when there is a task that needs to be completed or there is a decision that needs to be made, everyone knows who is responsible. As a result: 1) People get invested in the project because they know what they are responsible for and they (more often than not) get excited about delivering it; 2) Things get done.
As such, taking the time prior to the project kicking off to clearly establish who is responsible for the various aspects of the project and how their role may intersect or overlap with other roles on the project is, in my view, time very well spent.
4) Poor Communication
This one in particular could be a blog post, or even a book on its own, but I’ll touch on a few, of what I feel, are important points on the subject. Communication, as it relates to project delivery, doesn’t mean having a trillion word vocabulary, or the ability to deliver the opening keynote at a TED conference, or even an understanding of the proper use of a dash versus a hyphen (though these would be considered assets, I suppose). It’s firstly, about the understanding of the NEED FOR communication. Communication between the team; communication with the client; and communication with management and other stakeholders.
Secondly, it’s about understanding that communication is EVERYONE’S job. Project managers are typically the owners of the project status report and its delivery, but ensuring that it has all of the necessary inputs – from current and planned tasks, to risks and issues, to current status of scope, budget and schedule – should be a process where all team members are expected to contribute. As such, all team members should – in addition to their roles to design, develop, test etc. – EXPECT to have to (and hopefully also WANT to, as this is THEIR project too) communicate such things as: 1) Status – planned vs. actual; 2) Issues/Risks; 3) Anything else they think might be relevant for discussion (your Project Manager is here to listen!)
This isn’t to say that every team member needs to be present in every status meeting and copied on every email; quite the opposite, in fact. It IS to say that every project, in some form or another, (level of detail and rigour will depend on things like scope, budget etc.) should have a communication plan that will define things like 1) who needs to be in the status meetings and 2) who needs to be copied on emails. (See # 3 Role Definitions above. See how this is all coming together?).
5) Scope Control & Change Management
Closely related to #2 (Requirements), Scope Control and its close relative Change Management really HAVE to be included in any ‘Project Management Top 10’ type of list like the one you have almost finished enjoying.
As this one is probably the most obvious one of those listed, I’ll keep my points brief since, in my view (though it is certainly easier said than done), mitigation strategies for preventing failures in this area should be equally brief and simple. Scope. Define it. How to deal with changes (and YES, there WILL be changes). Define that too. Remember, the process shouldn’t be about locking things down so tight that change can’t happen; it’s just about having a process).
So, this is obviously not an exhaustive list but just a few ‘reasons projects fail’ that I have seen, along with a few ideas for how to mitigate failures in the future.