PM Articles > Kent McDonald > The Project Was a Success, But the Business Went Bankrupt

The Project Was a Success, But the Business Went Bankrupt

by Kent McDonald

The end of the year is usually a time to take a look back at the year that was and then look forward to the upcoming year. I'm going to take a moment and take a look back, but it's going to be longer than one year.

I was searching around in the ProjectConnections archive today to figure out if I had written a specific article, and I ran across an article I wrote back in December 2011: SMART Objectives Aren't Always Project Specific. As I was reading through it to see if it was the article it was looking for (it wasn't) I noticed a couple of comments that had been posted right after the article appeared. I'm embarrassed to admit that I didn't respond to the comments at the time, primarily because I didn't realize they were there. So I'm going to (attempt) to make up for it by addressing the commenter's remarks in this article. After I apologize for not responding sooner.

Alan, thanks for your comments. Sorry I didn't respond sooner.

In the article, I mentioned an ERP project that my friend Niel Nickolaisen was involved with that led to his creation of the Purpose-Based Alignment Model.

In Stand Back and Deliver, my friend and co-author Niel Nickolaisen shared the story of a 14-month, $27 million ERP project that was on time, on budget, delivered all the agreed upon scope, and was considered a complete failure. The project did not add features that helped the organization build and maintain a sustainable competitive advantage. The team and the sponsors thought that budget, cost, and scope were appropriate measures of success, when really they should have focused on whether what they were doing would help them achieve their business objectives.

The comments I mentioned were both from the same person, who took some exception with my perspective on whether the project was successful:

Boy, do I take exception to your premise regarding the example ERP project. The project to install the ERP was a success, as defined. The decision to install an ERP, or that specific ERP, was flawed. Let's separate the project from the part of the strategic plan that it grew from. Don't denigrate the project team for the failure of the strategic planner(s). Someone decided that the strategic plan would be well-served by installing an ERP to provide specific benefits and supports to the current and future needs of the business. This is not a Project Management failure -- this is a strategic/operational planning failure, over which the PMO has absolutely no control.


Reading further into Niel Nikolaisen's Purpose-Based Alignment Model, which essentially identifies the "Differentiating" qualities of a project/product, I'm even more convinced that this is not a Project Management issue, but more of a Business Process Management/Review issue, again, stemming from strategic and operational planning decisions.

The truth is most projects are focused solely on parity activities.

Note: The Purpose-Based Alignment model is not necessarily used to identify the differentiating qualities of a project, but to determine if it is in fact supporting an organization's differentiating activities. The truth is most projects are focused solely on parity activities and therefore should looking for ways to mimic good practices by competitors or simplify processes and solutions. Many people like to think that they are working on a project that supports a differentiating activity and therefore try to be way more innovative than they actually need to be. This results in excess work and overcomplicated solutions which, in the long run, result in more maintenance than is actually necessary.

Alan and I sort of agree on at least one point. The decision to implement a specific ERP may have been a bad decision on behalf of the folks either creating the strategy or deciding how to implement it. It's also distinctly possible that taking on the ERP project to start with was a strategic/operational planning failure. But it may not be.

Implementing an ERP package may have been a perfectly suitable way to enact strategy, but things fell down in the implementation because the project treated the ERP package as differentiating when in reality it primarily supported parity activities. One of the main reasons Niel created the Purpose-Based Alignment model is to help teams determine how to approach projects: should they be innovative and creative, or should they mimic practices that work elsewhere and simplify?

The statements "the project was a success, as defined" and "this is not a Project Management failure -- this is a strategic/operational planning failure" remind me of "the operation was a success, but the patient died." At the end of the day, it doesn't matter a jot if a project is on time, on budget, and delivered agreed upon scope if the scope it delivers does not actually produce the desired business outcomes. In fact, if a project team realizes the project isn't going to solve any problems and they don't raise that concern so that the project can be killed or revised, they are doing their organization a huge disservice.

The mindset that project managers or project teams have no responsibility for making sure their projects are appropriately aligned with business objectives is unfortunately more common than I would like. I've seen several projects where many team members knew that the project was not supporting any business objectives, and did not say anything or make it explicitly clear that the project faced problems. This is often a result of learned helplessness -- teams convince themselves that they can't possibly have a say in the reason why a project is being done.

Project teams should take it upon themselves when starting a project to make sure they are very clear on why the project is being done. They should be able to raise questions about whether the project is the right thing to do, or raise concerns when it seems that the project is no longer heading down the right path. These can be difficult conversations to have, but if they occur as soon as the team members realize something is not right, it's much easier to make the right decision to transform or kill the project. Either result is a success -- much more so than burying your head in the sand and hoping no one notices that your project is building a bridge to nowhere.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.