Home » Team Management » Is It Really OK For Your Project To Fail?

Would you tell your project team that it is OK to not get the product working because real-life experience shows that sometimes things don’t work out?

“‘Real-life experience [for a professor] is important,’ [he] said. He believes the point in this type of class is not to get the product working — because that doesn’t always happen — but to teach students how to work together ….” It’s Not Just About Coding Anymore, Software Development Times, March 2011, page 30.


Breathe. OK, I actually understand the point being made, but I just don’t like it. I’ve seen too many organizations, teams, and projects where a failed effort (e.g., not on time, budget, quality, or functionality) was normal and accepted. It has always worked this way, I would hear, and it is just something we have to live with. The organization gets by, at least for awhile—and sometimes for a long time—with this kind of performance.

Is It OK To Teach That Projects Fail?

Possibly I had an advantage in that I started to do software programming at a fairly young age and worked on my own projects. I wasn’t bound by time and resources and could get it done whenever I wanted to. I also started a lot of projects that I never finished, in large part because I lost interest in them. The point of all of this is that I could see what it took to finish a project and I knew what it was like to finish a project and have it work exactly as I wanted it to work. When I got to college, I did pretty well in the software programming intensive classes. When I turned in my compiler project (i.e., writing a programming language compiler), the professor told me it was the best he had ever seen. Gee, I must have been someone really special!

Nope, I don’t think so (just ask my wife!). I simply had more experience at doing complete projects (and more coding practice) than others had at that time. The key was completed projects. I would finish a project and then spend weeks and even months tweaking it to get it just the way I wanted it. I knew what it looked like from beginning to end to do quality work.

When I got into the professional world, doing computer programming, I quickly came to a depressing conclusion. The conclusion was that the project problems are not technical. Since I knew how to get things done and done fairly well, my own initial inability to get things accomplished was frustrating.

Lets Teach How To Succeed At Project Management

Why did people (e.g., managers, technical leads, etc.) keep getting in the way of just getting the job done? Meetings about things that had nothing to do with what I was doing! Assigning or not assigning people to tasks due to questionable motives (e.g., friends, not friends, promotion opportunities, complaints, control issues, etc.)! Over-controlling who knew certain information and who was involved in key decisions! What the heck was going on here? Wasn’t our purpose to accomplish the mission (we were in a hybrid military-governmental-contractor organization)?

With determined effort and the blind naivete and energy of someone in his twenties, I was able to get the organization to deliver their software intensive system on time and with good quality (for the rest of the story, see Making the Leap). So my second conclusion was that an organization could break out of its malaise and do great work. My career would take me through many organizations where these same patterns were evident and accessible to change (for more on change, see Silver Bullets).

So working together is, in fact, incredibly important and one of the key reasons we were able to break the first pattern (e.g., managerial bad habits) and implement the second (e.g., on time projects with good quality). However, breaking the first pattern was always the biggest challenge, and the ability for people to work well together was always self-evident by their achieving the second (also see self managing teams).

I just would not emphasize to students that since it is often normal for projects to fail, it is OK if they don’t succeed in their assignment. I’d rather our university system teach our students how to complete a successful project by working together and then mention how many teams still struggle to achieve the same.

How do you motivate a team to be successful in an environment where many projects are still not successful?

Thank you for sharing!

6 thoughts on “Is It Really OK For Your Project To Fail?

  1. Bruce Benson says:

    Comments from around the web:

    Shanker Jousula • Now the Original Question “Whether it is OK for projects to fail” ? What is feel is this is a relative concept. We delayed the project by two days. Is it a failure? Requirements are added at the last moment due to a business justification or need, or Business driver. We all accommodate them. Is it a Proj failure? I don’t think so. What I think is Project Management is a framework, which will help the project to success. – from 50 % to 60% and slowly when the team matures to may be 95 % or 99%. It is just a tool, which will help us to track resource usage effectively and reduce – rework, re-engineering, and thus save money for the company. We don’t have to be adamant about 100 % success, but do our best. So to encourage a PM and teams, yes, Projects can fail and most do fail, and our job is to continually see to it the failures are minimized.

    Wil Ferch • My comments are not made as an arm-chair expert….but one made as a bloodied and grizzled veteran of this business.

    I stand firm in my position…..the examples Bruce give are not compelling enough to change my mind. Those are difficulties in an imperfect world most of us face. This does NOT mean , however, that the disciplined methods with the extra steps I propose, should not be used, because the people you interface with act illogically or unreasonably. That makes using such disciplined approaches even more compelling to the project team.

    If there is no contingency planning done, if there is no project “change-control” planning done, no doubt most projects will fail. Most projects I have seen fail …..fail for some of the reasons I outlined.

    * Was there an “honest” original project defintion and execution plan? In other words, is the project “sound” to begin with….with a good chance of succes as planned? Sometimes we enter a “bad” project right from the start with no hope of success. This needs to be wrestled to the ground with input from the stakeholders from the get-go, setting realistic achievable goals, even if they are aggressive. But do-able.

    * Was there a contingency plan in-place ( upfront !) ?

    * Was there a “project-change-control ” plan in-place ( upfront?). I have found this missing element to be particularly “key”. Not many projects get executed on the premise of the “original” plan…and the project changes often occur DURING the execution phase. The core question is how to handle. When pressed….does the project team simply say “We’ll try” when approached with massive scope or resource or money changes? ( should ring a warning bell in our heads….ding/ding)….or….does the team execute the known change-control plan that all agreed upon in the beginning, that allows a greater chance of success?

    It is all a matter of military-style *discipline* that I find lacking in almost all the failed projects I have seen as an outsider. I come from a capital-projects heavy industry background …yet most “projects” I see spoken about today are IT type jobs which( in my view) have one of the worst records of project definition and execution…with many failures ( project ends up “not working as intended”, or massive $$ cost over-runs).

    No doubt, there will ( at SOME point)…..be a particulary difficult person or “work culture” , where some of this “theory” ( as you call it) doesn’t work. My sense is that you reached automatically and quickly to this conclusion as the inevitable situation you will end up facing… without giving due consideration of the intermediate steps and processes I mention to be used…. that can change all this.

    DonnaRenee Cook, MBA, PMP • I would not be ok with a project being a true failure. I would identify a failed project as one that ultimately did not meet the needs and objectives stated in the project charter, or one that did not meet the needs of the stakeholders.

    However, early in my PM career I had a project cancelled and was ok with it. In this situation, the organization was in such rapid flux that it literally outgrew the parameters of the project prior to launch. For this reason the project was cancelled half way through and a new project was developed. This made perfect sense as the original scope of the project no longer meet the needs of the organization. Had we completed the project perfectly as it was defined in the charter, I may have still considered it a failure because the organizations objectives would have gone unmet.

    For me there was definitely a lesson learned.
    1. Work to define a charter that takes significant changes in the organization into account where possible. Focus on scalability and outside forces that might change the needs of the stakeholders.
    2. If the organization is fluctuating so wildly that you cannot predict the needs of the stakeholders accurately, it is probably best to hold the project temporarily.

    Wil Ferch • As was mentioned…agreed…a project that was kicked-off and running….and then gets cancelleed or delayed due to to changing market conditions ( that were NOT seen upfront)….is simply being prudent… and is not a “failed” project in the strict sense of definition.

    Bruce Benson • Wil,

    My examples are to show that everything we do as a project manager has a “context.” If we don’t take into account that context, then often our techniques will not be as effective as we need them to be. This is where we have to get creative and where we really have to know what we are doing why we are doing it (and not just running through a checklist or standard procedure) so that we can get the job done in one way or another.

    I couldn’t get the organization to settle on a reasonable schedule. My proposal got rejected and another schedule, much shorter, was chosen. What do I do? Call all the stakeholders back together and once again explain why my proposal was more realistic? I doubt many would have shown up to decide, again, what they already decided.

    Most PMs, I suspect, would have just buckled down and proceeded the best they could with what they were given (which by the way is often rewarded, even if the project is a failure – the PM tried to meet the stated need).

    What did we do? When the first big emergency came up (and they always come up with aggressive schedules) and we had to replan the project, we “slipped in” our original schedule as the “updated” schedule (for the whole story see http://pmtoolsthatwork.com/project-management-crisis-hurry-but-do-nothing/ ). We delivered on-time (taking no longer than past projects) for the first time in collective memory.

    We could have just settled on one more project that came in late and buggy (which was normal), but we didn’t. One senior engineer said to me at the beginning of the project “we can’t really ever deliver on time, that is just happy talk” and the business manager said to me at the end of the project “hey Bruce, this stuff really works!”

    Using good methodology got us a good schedule. Getting the schedule to be used required understanding the context: personalities, past performance and culture – and then taking some significant personal risk. This last step is hard for many people, because it is a risk to them personally and because they don’t yet have the experience (or conviction) to realize that they really can make a huge difference (for more on this last step, see: http://pmtoolsthatwork.com/disrupt-the-project-to-make-the-big-improvements/).

    Bruce Benson

    Wil Ferch • Say what you will Bruce…the examples you cite simply portray a story of poor-corporate culture ( not one built of trust between stakeholders and project team)…and from that…..the inevitable lack of “OD” that ensues….i.e., the lack of Operational Discipline that is required to get the job done.

    Taking “risk”…..without senior people understanding the “risk” you are taking…and why you felt compelled to take it…. is suicide in the long-view. Why?…because if it works, you are a hero…but, if it fails….no one will *understand* nor condone your actions, and you will be soon “out” based on erroneous pre-suppositions.

    Yes….it may mean cutting your losses and maybe work someplace else, if you can’t sense that reason prevails even after exhasutive efforts are put into play to have everyone see the errors of the current ways.

    Bruce Benson • Wil,

    Yes, I’m rather stubborn and don’t want anything to fail – not on my watch. Absolutely, these organizations were not doing well for a variety of reasons. I’ve always said that I’ve either been blessed or cursed with ending up at so many organizations that were struggling. I then came to realize that I was not being unlucky, but that in fact the state of the practice in project management (IT and software in particular) was just not the best.

    To the extent this is true, then knowing about how to manage change and how to take risks in an organization is essential to finally getting projects to on time, on budget and good quality performance. The good news is that it is possible and not that big a stretch (see http://pmtoolsthatwork.com/leap-to-exceptional-shorter-than-we-think/) . The bad news is that just knowing project management techniques is probably not enough for the successful PM – in too many organizations.

    Bruce Benson

    Wil Ferch • Bruce:

    I sense we’re not that far apart afterall…maybe not far apart *at all*.

    I agree 110% that the best way is to “re-educate” or better said….to “re-culture” a workplace. Inertia is against you on this and you will need mentors and other support…plus for management and CXO levels to acknowledge a “willingness” to see that there *is* a problem to fix….before anything like this can take hold. But in the long run, it is the best way… !!

    If you take on the “lone ranger” approach to use methods that may work but are not sensed by the stakeholders as necessary….I would at least communicate and document my actions along the way in whatever way and as-often as I could, so people will (someday) see the reason “why” something was done…..not just the “what” of what was done.

    Cultural change is the biggest challenge yet reaps the largest rewards.

    Bruce Benson • Wil,

    Agreed. Great discussion.

    Bruce Benson

    Wil Ferch • Bruce:
    Indeed….the biggest challenge is the culture found in the workplace….I’ve found this to be true for the issues surrounding Project Management…and very similarly for the personnel and operational Safety issues….and come to think of it…also various “quality” issues seen by companies. The culture determines the earnestness and seriuousness taken by the enterprise…and also how a “disciplined” approach helps all these things.

    Glen Gage • No, maybe, yes depending on the situation

    No: it’s the project launch. Focus on success, it’s imperative.

    Maybe: after the failure during lessons learned. Ok might be not your fault. If not ok then what do we do next time?

    Yes: the project may be abandoned but not really failed. If management cancels a project at a go/no go decision point then either things have changed or the new info you have brought convinced management it wasn’t such a good idea in the first place. This is actually a win for the pm process.

    Wil Ferch • Glen:
    I think I bring that point up in an earlier response.

    The *key* is if the “findings” that we are now responding to that “cancel” a project….were known ( or not known) at project initiation.

    If the new factors are truly *new* while the project is “in-progress”…sure…a cancellation or delay may be prudent and therefoe the project cannot be seen as a failure. If, however, there was poor due-diligence done upfront, and the “new” news that prompts a cancellation of the project could have been known upfront…then I submit the project *is* a failure due to poor Operational Discipline in the planning-phase. The project team , maybe, shouldn’t take the “hit” for such a failure….but surely the work “process” that led to this… is at fault.

    Kevin Ward • No.

    Glen Gage • Will:

    Why can a cancelation prove the success of the method?

    Scenario: you take a rough idea to mgmt and tell them it will cost x to scope it. They like the idea enough to spend x to get the scope. You deliver the scope and initial cost/benefit and what it will cost to produce requirements and a high level design. Mgmt says ‘go’

    Youcome back with the requirements, etc. and new cost/benefits and the cost of producing adetaileddesign. Mgmt says ‘don’t ‘go’

    The PM process has worked perfectly.

  2. Denis says:

    Completely agree that in a professional world tech problems are not the obstacles instead it’s more than that. Also agree with Claudia that project management tools are best to efficiently complete & manage a project. We use Microsoft Project 2010 in our organization for developing plans, assigning resources to tasks, tracking progress, managing budgets and analyzing workloads.

  3. Dave Gordon says:

    Every project succeeds or fails based on criteria that have far more to do with the expectations of the sponsor and stakeholders than the project team. Delivering a “perfect” solution, too late to be useful, is a failure. Delivering a “good enough” solution a bit earlier likely would have been deemed a success. Even “coming in on time and on budget with exactly what was in the requirements” is only a success if the stakeholders can realize the value postulated in the ROI. I’ve seen more than a few projects deliver excellent products that were never adopted. Whether that’s the “fault” of the project team or the users or the sponsor for approving the project in the first place is immaterial – it’s a failure.

    Failure is very real-world; as Albert Einstein observed, “If we knew what we were doing it wouldn’t be research.” And if all we were doing is unwrapping a package and plugging it in, it wouldn’t be a project. So our mantra should be, “If we’re going to fail, let’s fail quickly, before we waste too much time or money.” You’ll still fail from time to time, but failure is only bad if it’s wasteful, or you don’t learn anything from the experience.

    1. Bruce Benson says:


      Good summary of the basic issues and the range of possibilities and outcomes any project confronts.

      I just like to remind senior leaders that just because “anything is possible” that it doesn’t mean they can’t bring their projects in on time, on budget, and with quality. Too many companies get overwhelmed with everything that is going on and just can’t find a way to get it straightened out. They come to believe that “This is normal. Everyone says projects often fail and ours often fail. We are trying and this is what we can do right now. We work really hard.” When we clean up the bad habits (i.e., management blind spots – such as the notion of aggressive schedules that aim for the 3rd quarter when we really want to be done in the 4th quarter) and they start to deliver on time, the light goes on. I had one senior manager, who didn’t like what we were doing, in the end tell me “OK, I do like it when it comes out this way.” He fought us the entire time, telling us that what we were doing wouldn’t work, had been tried before, etc.

      So because a range of things is possible and situations are driven by circumstances and because there are a lot of unknowns, simply means we have a job to do – one that requires expertise, experience and leadership — and it can be done. I’ve never worked in or worked with an organization where we were not able to finally get our projects to consistently and competitively deliver on time and with good quality. The fact that many organizations can’t achieve this is not a real reason why THIS organization can’t do it. If it was a dud, it was a dud, but it was not held back by poor management of the project or product (“The product looks like management” was a once popular insight that still holds today.)

      Good comment and reminder.



  4. I like project management tools for getting projects done and helping with management. What I don’t like is when a manager uses these tools and automatically assumes he’s a project manager. There’s a lot of knowledge that goes into PM. Tools are a great addition, but you need a knowledgeable project manager leading the project to really get the best.

    1. Bruce Benson says:


      Yes! Part of what I advocate is “You are your best project management tool.” Tools are great, but they don’t make us a project manager nor do they magically make project managers successful (well organized, intuitive, etc.).

      The person is always the active element and is always the key to successful project management.


      P.S. An article on how tools can get in the way: http://pmtoolsthatwork.com/project-management-on-steroids-kick-the-habit/

Comments are closed.