What is the top reason for unsuccessful Projects?
Posted: 12/11/2013 Filed under: Article | Tags: Aerospace, Agile, Coaching, Command chain, Communication, Construction, HR, Information Technology, Leadership, LinkedIn, Management Systems, Organization, Profession, Project Governance, Project Management, Project scope, Project sponsorship, Projects, Requirements, ROI, Roles and responsibilities, Stakeholders, Steering Committee
Image source: LinkedIn
Some time ago, Babak Golparian, Project Management Consultant & Coach, posted this question in the PM Link Group on LinkedIn.
There were 242 votes in the poll.
You can notice Unclear Scope won for just one vote: it’s mine.
This debate appears periodically, or maybe it is always open in differently stated questions, in the Groups concerning Project Management.
Communication vs Unclear Scope is always the Big Match. The results are related, normally, to the field and hierarchical level of contributors.
In example, those who operate in Information Technology will privilege communication easily, because they live in an environment where, too often, the marketplace sets clear scope requirements out of their control and so best practices, sadly enough. The worst thing is when they start to think, and this is wrong, that scope definition is not of primary importance and it is regular to set objectives along the way, and this mistake is very serious in Project Management. The so-called Agile methodology is in this line of thought, but is not a good Project Management for other fields in the opinion of many. I agree and can’t imagine an Aerospace or Construction project starting without a given configuration. This is why these methodologies are a minority in P.M. application. Let alone when you use P.M., as it is perfectly correct, for any organized and well defined in scope and time set of activities (the same definition of project), like restructuring a company, implementing a public service and so on.
Usually, the same kind of answer comes, in the environment, from technical levels in the Project Management command chain. Clearly, the operative resources delegated to controls, incorrectly named PM in many entities, have not the Scope in sight but it is more important for them to benefit of an appropriate flow of communication in order to complete their tasks.
Instead, for sure at Project Governance level people know very well that without a very neat and well defended scope you don’t go anywhere.
Anyway I agree that Project Management is made by people first, so I declare that communication, like HR skills for the person in charge, is vital. But given that everybody knows where to go and why, in definite detail before the game starts.
That’s why my Project Management courses are focused on Leadership and Communication in their basic edition. Nobody can play this role just with procedures, SW tools, manuals, certifications and even a long operative-level experience. And while a sound skill in relational topics is a must, let’s remember that “competence” is ability to keep our role (leadership), and this is impossible without a clear charge and scope.
There has been also a brief exchange, of great interest, about the idea of P. M. as a profession, that is not, of course.
I report here a selection of comments in the conversation because they are interesting to understand the recurrent points in this topic, and my comments as well. The selection is focused on the two main players, Scope and Communication, but as you can see, the most remained posts are relative to the good management of Scope. This means something, I think. And we can see, ironically enough, that half of the contributors in the Communication field voted but, … well, they did not bother to comment…!
Joe Donahue / I voted for communications because you did not include a category for effective leadership which I believe is the major problem.
John Warrick / Unclear scope (agreed requirements) includes errors and unrealized assumptions embedded in the initial project estimate. This is why the project performance demonstrated during the first 15% of project execution is typically the performance acheived during the balance of project execution as well.
Azham Zainal / I would like to vote for poor stakeholder management, in terms of inadequate engagement with key stakeholders and expectation management. Some of the key contributing factors leading to this situation is due to internal politics and power play – which could be beyond the direct influence of the PM…
In the absence of the above option, I go for poor communications..
Timothy Flanigan / I voted for poor communications, primarily because a majority of other identified problems can be solved with improved/effective communication, whether internal among the team or with the external stakeholders.
Jed Simms / Of the options given, i vote for poor requirements because if you don’t know where you’re going, you can do everything else immaculately and end up delivering no value . But […] fundamental to success is, what we would call, the organization’s Value Delivery Capability – its capability to deliver value from project investments. This is measurable and our research found directly correlates to the ROI delivered from project investments . Add the two together – not knowing what you’re doing and not having the capability to deliver and you can see why so many projects miss, lose or destroy more value than they deliver.
Guangcheng He / I vote poor communication. Firstly, if there is unclear scope, the project MUST be unsuccessful. However, clear scope can be gotten via PM’s active communication with stakeholders. Even if the scope is clear, the project will also be fail if the PM’s communication skill is poor. So, if the TOP reason, I prefer to vote poor communication.
Locke Hassrick / While all of the above can lead to failure, I would add poor executive sponsorship. With poor executive sponsorship poor communication, unclear scope, and etc. typically follow.
Priscilla Walker / My top reason would be unclear scope. You can be the most effective communicator, cost-effective person that has a PMI-RMP certification, but if you lack clear agreed requirements, you will not be able manage the project efficiently. Simply put, if your agreements are unclear you will be starting off on the “wrong foot.”
Ugo Micoli / […] In the end, if I should say it all in four lines, as Priscilla did, her comment could have been written by myself. Scope is everything, including all technical, financial and managerial specifications as in contract.
Jed Simms / To take the discussion in a slightly different direction for a moment. Everyone has views on the causes of project failure and we see failures every week all around us. When I became accountable for all projects in a bank nearly 30 years ago I realized that “project failure” was the norm. Most projects fail on one or more criteria. And this is still the case today. Lesson learned – there is something fundamentally wrong with how we approach and deliver projects. What other ‘profession’ would tolerate such a high level of failure. Yes, I know projects are challenging etc etc – but that is what we’re set up to manage – so that can’t be held up as an excuse. Maybe, we are just going about projects the wrong way…
Ugo Micoli / @Jed – I agree. That happens, as you said, just because PM is not a ‘profession’, but a management discipline, as stated by Russell Archibald himself. In example, in a bank one has a given charge, where he can use, for better results, this management discipline. Results depends on best practises, expertise and ability in this discipline while making his job… Other is the case of a qualified/licensed Master’s D. engineer or a surgeon. A surgeon does not apply a management discipline, he can’t fail at all as a norm. Projects fail if the scope of the project is badly defined, in example. Projects are created and P. mgmt is implemented just to avoid to miss the goals, what else?
Jed Simms / I define failure as not delivering the agreed BUSINESS outcomes. Success is delivering the agreed, specific, measurable desired business outcomes, associated business benefits and value in full. Clear and easy to measure. If I as the business exec don’t get the outcomes I wanted and their benefits then the project investment has been a failure to one degree or another. Time and cost become factors impacting the net value. These outcomes need to be agreed and finalised at the business case stage and protected by the Sponsor and Steering Committee so as to get the best business result.
These are not the outcomes of the project but the business outcomes to be achieved by and in the business as a result of the project. The project delivers a subset of these business outcomes – again clear, specific and measurable…
Oolan Zimmer / All of my project experience is in software, and that colors my results. If I had to vote for just one of the options, I’d have to say poor communication, mostly because most of a PM’s job is communication and many of those other processes require good communication to work. … Most of the projects I’ve seen get in trouble have had scope problems. Either the requirements were unclear or not signed off, or the customer/sponsor kept changing their mind. I’ve seen projects where different stakeholders wanted mutually exclusive things, and someone was gonna be unhappy no matter what. Most of the time, cost and schedule problems were secondary to scope and stakeholder issues unless the overrun was really severe.
Babak Golparian / … I don’t think the Organization in apart from project, I mean it’s not gonna be easy having successful projects in organizations with wrong approaches and assets, Organization has very big influence in the project outcome…
Oolan Zimmer / The glib and naive PMI-ism is that if the PM had this magical communications ability, then they could just communicate with the customer/sponsor and get them to agree on well-defined objectives. The contradiction is between this theory and the reality. […] Sometimes the customer knows what they want (or thinks they know what they want), but are unwilling for one reason or another to commit to hard requirements. Most of the time, they don’t know what they want and half the battle is getting them to discover what they want. Sometimes it’s a balance between what the customer thinks they want and what’s technically possible. This is how agile came into being, where a sequence of prototypes helped the customer discover and refine their requirements. Aerospace companies have been using sequences of prototypes for decades.
I’m particularly wary of projects that have no clear business need at the sponsor’s level driving the project. Many of those “danger” projects go something like: our current solution works just fine, but we really should be using Technology X because someone highly placed read an article about how great it is. If a customer can’t even determine what’s missing from existing capabilities, there’s no way they’ll be able to agree on new capabilities, even using a prototype as a discovery aid.
Ugo Micoli / @Oolan – From your comments I get you are in the IT. It’s not an oddity IT operators are the worst in applying best practices, because of their particular marketplace more than of their fault, and of the fact that the acronym or function “PM” is too loosely meant and assigned. I agree with your concerns. But, and I say this to everyone in the “communication” party in this discussion, COMMUNICATING WHAT? In example, as a coach I always teach to stay silent if the role and responsibilities are not clear and the person is tempted to jump in communication out of her/his competencies. Period. I am an aerospace MD and QPE engineer, came from and still operate in aerospace as a PM consultant. I seriusly disagree that “agile” way of thinking is fit for the field. Least of all, that using “sequences of prototypes” is the way to define the scope. That is absurd. Prototypes are used as part of product development process as usual in the field and in many engineering marketplace areas where ne repetitive specs are in action. The SCOPE MUST be VERY well defined at the beginning, EXPECIALLY in aerospace and military. There are strict standards about that. I think many in the “communication” party simply suffer for being in a field that usually operates in ambiguity of scope, and are forced to activate communication not as a logical secondary consequence, but as a survival kit in progress expecially.
Monique McLendon-McGhee / My choice was unclear scope was the closest answer to my reason. I believe managing scope is the reason. You can have agreed upon written requirements and then have those requirements changed by higher up manager request changes even if you have a change control process. Changes to any project far enough along can make a project unsuccessful.
John Benfield / … [Agile Project Management] is about continual customer engagement and involvement. It’s about responding to evolving requirements and being willing to continually test and adjust assumptions as needed (with good change and scope management). It’s about delivering incremental value and being willing to abandon the things that don’t add value to the deliverables or desired outcomes. …The problem is that some people assume that adopting Agile methodologies will somehow imbue a team with the ability to think and magically grant them common sense. … They ignore the fact that you need the underlying understanding of “why” things are done that way and the maturity and experience to adapt when needed…
Ugo Micoli / John, you cannot make virtue out of necessity, given necessity comes from bad business practises. Please see my comment about IT environments, where you seem to belong.
Gilles Debout / Hi – I have voted “Unclear Scope” as I think the key success is to define clear “Roles & Responsibilities” prior to start the project.
Stephen Daniels / Something like 70% of all projects fail to deliver one or more of their core projected benefits. The brain doesn’t process negative information so perhaps it’s better consider what you would expect to see if things were going to go well!
I generally want to check the clarity of the Job Description and Personal Specification for the role of PM and see a clear project brief and mandate: I look to resolve any initially unseen issues around this straight away. I also look to complete a gap analysis in the first 2 weeks to support or inform a view as to whether the solution or product specified as a project outcome matches a problem or specification previously identified or whether there are other risk issues around the mandate. My approach may include, for example, a staff survey and certainly a number of meetings with all stakeholders.
The top four risks in my mind are not specific to either public or private sector, nor to an employer type, but are to do with organisation environment. The first is the project sponsors authority within the business, along with their time and commitment to support the change; the second in whether the PM has the perquisite delegated authority and evident support by senior managers, with or without the sponsor, to perform the task; and the third is any practical issues governing stakeholder engagement e.g. time, budget, conflicting or competing priorities. Finally, how well is the projects purpose, aims and need for support communicated by the businesses Executive team initially, and ongoing through Senior Managers?
If there are insurmountable obstacles in these areas at outset, it would not matter whether you followed the process my the first paragraph, or for that matter any other skill, process or methodology. You will struggle to overcome what amounts to a lack of resources and therefore commitment by the organisation to deliver the change. The only way round this is to be very direct about these issues up front with all stakeholders at all levels and agree a process or course of action that will be followed if there are every any shortfalls.
Ugo Micoli / @Stephen – I agree completely. Your experience is self evident.
Pete Nathan / There has been about 20 years of research into this topic. We never stop trying to figure it out and we keep repeating the same fundamental mistakes. …
One of the issues is that there are risk factors that are internal (or under the project team’s control) and an even wider number of factors that are external to the project team.
One of these external factors is how the project management system is set up and supported in the organization. In all too many cases, projects are unknowingly set up to fail even before the initial project kickoff meeting takes place. A common complaint I have heard repeated during interviews with PMs is that the project was “set up” to fail. One of Deming’s principles from his System of Profound Knowledge fits PM. The performance of projects is governed largely by the system that we work in, which is the responsibility of management.