Project & PMO Manager | Research & Enterprise Mentor| GFB HoldingSouth America, Brazil
Every project professional has faced setbacks. Share a time when a project didn't go as planned, and tell us the most crucial lesson you extracted from that experience. More importantly, how did that specific lesson fundamentally change the way you manage or approach projects moving forward?
Consultant| Canarys Automation LtdBangalore, Karnataka, India
One of the most valuable lessons I’ve learned from a project failure is the importance of aligning stakeholder expectations early — and revisiting that alignment frequently.
Few years ago, I was leading a large-scale automation project. We had a well-structured plan, a capable team, and strong technical execution. However, as we moved into delivery, it became evident that some critical stakeholders had interpreted “automation” very differently from how the project was scoped. By the time this gap surfaced, rework was unavoidable — causing delays, cost overruns, and strained relationships.
The core issue wasn’t technical — it was assumption drift. We had assumed that our early conversations were enough to secure a shared understanding, but in reality, priorities had evolved on their side, and we hadn’t created a cadence to surface those changes in time.
That experience reshaped my approach in three ways:
1 - Institutionalizing Continuous Stakeholder Alignment – I now build structured checkpoints into the governance framework, not just to update progress, but to actively confirm that our definition of success still matches theirs.
2 - Translating Technical Goals into Business Outcomes – Instead of assuming stakeholders will interpret technical milestones the same way the team does, I map them explicitly to business objectives and value delivery.
3 - Documenting and Revalidating Agreements – Every key decision or agreement is documented and shared, and at major milestones, I revalidate it with stakeholders to prevent silent expectation shifts.
The result has been a dramatic reduction in late-stage surprises and a much stronger sense of partnership with stakeholders. For me, that failure reinforced the idea that even the most technically sound delivery will stumble if you don’t keep your stakeholders aligned every step of the way. Saving Changes...
Vinay Babu TaralaSenior Agile Coach| AT&THyderabad, Telangana, India
Embracing the project failure is reshaped my approach with one of the setback.
while I was working in Aerospace company, as part of make in India initiative, I have asked to work on a product which is combination of Hardware and software where we failed miserably with design and prototyping because of various reasons.
But when we shared to larger forum about it's approach and failure, many were applauding the approach as we were doing for first time... but we were thinking it was big failure with our perception... sharing is nrw caring is what i have relaised...from next time onward i have tried to check the failure stories a lot Saving Changes...
The most important lesson I've learned from a failed project is to ensure sponsorship from the right people from the start. A project requires support and collaboration from the company's management and strategic branches.
Entering into planning time, cost, scope, etc., without clear support from the sponsors is like jumping into a pool without knowing how to swim and seeing what happens. A sponsor or manager could unexpectedly cancel or completely change the project's approach.
To develop a project, I ensure from the very beginning that I have adequate sponsorship, resources, and, most importantly, proper management of key stakeholder requirements. Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Francisco Matheus Chagas The greatest challenge does not come from technology or methodology — but from people.
In one of the most challenging projects I led, I made the mistake of selecting the team based on availability rather than a clear alignment of skills, roles, and expectations.
Worse still, I skipped formal sessions to confirm each member’s appointment, clarify responsibilities, and build a shared commitment from the start.
The outcome was predictable: unclear decisions, conflicting priorities, and frictions that eroded trust — not only within the team but also with key stakeholders, who perceived misalignment and began questioning deliverables.
That experience reshaped my approach.
Today, I treat team selection and early alignment as non-negotiable.
I invest time upfront in structured sessions where we co-define roles, responsibilities, and shared goals.
This ensures not only a cohesive team dynamic, but also consistent communication and expectation management with stakeholders from day one — creating the clarity, trust, and engagement that sustain a project through its toughest moments.
Head of Cloud Software & Services| Ericsson EMEAVictoria Island, Lagos, Nigeria
The main lesson learned for me in project failure has been insufficient people management (internal and external) irrespective of their levels across the organizations. I have come to realize that some project failure could be prevented when/if the seemingly difficult people are on your side.
It is not about the number of meetings that you have but the quality of engagement you have with people in/out of the meetings. From my experience ICT industries where my portfolio runs across at least 3 different industries per project, the impact of quality engagement has given me wins and helped me in recovering troubled projects.
This has continuously shaped my approach to project execution. When I get on project, I pay attention to the people and influence them to drive the process to achieve the project success. Are there times that things go wrong? Yes, this happens sometimes but it appears as if nothing serious when people feel influenced to see reason with you. Although, there will always be once-in-a-while cases that despite the engagement, it will still turn out to be a bad day. Saving Changes...
I've joined projects that I realized early on are doomed to fail. I could tell that based on the current trajectory, in 2 years time, everyone would be working ridiculously long hours trying to make up for poor planning and decisions occurring here and now. I also knew that the management culture was more interested in claiming success by moving the goal posts than meeting the original objectives, and I wasn't going to have much success changing the Dilbert Zone culture.
Rather than fighting tooth and nail to save a project already doomed to fail with our without me, I chose to expend my limited energy finding a new job where I could produce real value. You can't die defending every hill, so pick your battles wisely. Saving Changes...
You are about done adding details to the execution plan for a project. You thought your scope and list of requirements was complete and you believed you understood the requirements and the work that would take to meet those requirements and complete the deliverables. Suddenly, one of the main stakeholders (a customer or a sponsor) adds one last small item to the scope. Not a big deal you think, you are still planning, and PM is about customer service, lets add that piece.
The biggest learning from adding a small piece to a scope that was believed to be complete is that this "small piece" often is taken for granted, as if it will complete itself. I do not think it is a time problem or a budget problem. If anything, I think it is a psychological problem or a lack-of-experience problem. By the time this last piece gets added, even if time and money are not a problem, the PM and the team are tired and they are psychologically framed by what they believed was a complete scope. They do not unwrap their work to fully understand and plan for the last addition. HUGE mistake. This last addition, if not handled correctly, can drag and make what seemed like a straightforward project a nightmare to finish and close.
The right, yet not psychologically easy, thing to do when the scope gets expanded after planning is complete, is to dedicate time to fully build the addition into the plan. Get the right people involved, determine what it will truly take to get this piece completed, allocate funds for it, and ensure it gets attention from the beginning of the execution phase. Do not leave it for last, and whatever you do, do not trust it will be easy and fast to do without proper planning.
Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Maybe I should write a book about my key learnings.
The importance and relevance of each one was highest at the time and in the situation they occurred, so I see no most important.
#1 budgets are overrated.
I ran a 3-year project with a contractual fixed budget. After year three, when the budget was spent, but we needed to go for another 3 years, we negotiated a budget increase of almost 200%. Nobody was interested in the budget outlook I provided for 2 years, as everybody only looked at their annual targets. Whenthe crash came, lawyers settled the issue easily. The progress we made in 3 years was good towards scope, quality and value, original schedule and budget were deep red but did not set customer satisfaction.
When establishing a program to integrate several projects and several operational tasks, all with their own contracts and budgets, I did not pull budget responsibility from the projects and operations, but let them manage their tasks, not micro-managing. Budgets should not be managed at the program level.
Evaluating the project of the year for the Salt Lake City Olympic Games, I learned how they efficiently planned and ensured budgets: there was a department in charge of raising funds from a variety of stakeholders. Almost no budget existed when the project started, but by the end it was also a financial success.
Hypothesis: The ongoing disaster of failed (mega)projects is caused by the belief that we need a fixed budget and stick to it (investment fallacy).
- What if each program had its own funding department, competing for investors (Olympics are almost there).
- What if we stop seeing programs as investments (and try to achieve an ROI) while most and all the long-term benefits are not financial.
- What if we replaced Western short-termism with Eastern sustainability?
Saving Changes...
Sandeep DamodaranProduction Engineer| Metito Overseas LimitedDubai, DU, United Arab Emirates
One of my most valuable lessons came from a production facility upgrade project where we underestimated the operational risk of running parallel manufacturing lines during the changeover.
We had a strong plan and contingency measures for equipment delivery delays — but what we missed was a structured risk assessment for process disruptions during installation. Midway, an unexpected utility outage caused by the new installation halted our existing line for several days. This not only delayed the upgrade but also impacted customer commitments. That experience reshaped my approach in three ways:
1️⃣ Risk Management as a Living Process – I now build a dynamic risk register that’s updated weekly during execution, not just at the planning stage, so evolving risks are spotted early.
2️⃣ Cross-Functional Failure Mode Analysis – Before major changes, I bring operators, maintenance, safety, and supply chain together to map possible failure points (using tools like FMEA), so risks aren’t seen only through a project manager’s lens.
3️⃣ Contingency Capacity – I ensure alternate capacity or inventory buffers are in place before any intervention that can disrupt core operations.
Since then, I’ve found that even complex, high-risk projects can be delivered smoothly — and with far less stress — when operational risks are treated as actively managed workstreams, not one-time checkboxes
Saving Changes...
Rose GreenProject Management Officer| LJMULiverpool, United Kingdom
Three hard-won lessons spring to mind, that I encourage my PMs to apply to all projects:
- Manage expectations: the use of the word 'vanilla' during a system implementation led to some people thinking the system would be simple, rather than having minimal config
- Don't pay for the whole thing up-front: it took far too long to implement a very small system because the vendor lacked the incentive of the 'final' paycheck
- Don't impose something: senior management wanted to implement a system that was successfully installed but never used Saving Changes...
"We cling to our own point of view, as though everything depended on it. Yet our opinions have no permanence; like autumn and winter, they gradually pass away."
Community Champion
