November 23, 2015 | Time: 1:00:06 | Subscribe in iTunes
We asked for examples of project failure and we got an earful from participants of the PMIWDC 2015 PM Symposium.
From the realities of Federal Government Health Care and IT systems, to the business environments of regional theatre and Role Playing Games, we had tales of failure and recovery in locales as newsworthy and disparate as New Haven, Afghanistan and Baltimore, on topics from IT, to program management, to event management, curriculum design and organizational change.
Whether it was missteps in stakeholder communications, scope and quality, risk and contingency or flat out leadership failure, our PMs were there…sometimes part of the problem and sometimes part of the fix, but always with a front row seat in the messy project arena that often plays to failure…and later lessons for success!
Listen and learn and snag a PDU, then email us with your topic of failure you might want to record for a part 2!
Listen online or read the full podcast transcript below.
0:00:06 Michael Dobson: We know about constraints. What we sometimes forget in project management, is that some constraints are actually assumptions. You think they're real, but maybe they really are not.
0:00:17 Andy Walker: Risk management was kind of an afterthought. It wasn't a consistently applied priority.
0:00:24 Elisabeth McQueen: Because change needed to start at the top, and the individual at the very top refused to change, there was no way that could possibly have been a successful project.
0:00:35 David Offenkrantz: The government contractor at the time had deliberately low bid in order to win the contract.
0:00:44 Steve Schiffer: There were red flags up and I went past every one of them.
0:00:47 Davin Hattaway: Everybody’s distressed and scared 'cause the riots got within a block of the hotel.
0:00:51 Speaker 7: From the Washington DC chapter of the Project Management Institute, this is PM Point of View. The Podcast that looks at project management from all the angles. Here's your host, Kendall Lott.
0:01:04 Kendall Lott: We learn more from our failures than our successes. And what project manager hasn't stared failure in the face at some point in the their career? So I thought, wouldn't it be great if we could all learn from each other's failures? So, the PM Point of View Podcast set up a table in the bustling lobby of the September Symposium of the Washington DC chapter of PMI. We invited any and all attendees to sit down and tell us about a project that they had been involved with, that had essentially or disastrously failed, as well as any lessons learned they had taken away from their experience. I was amazed at the number of project managers who were eager to tell us their stories, and at the range of experiences. Many of the PMs in these interviews saw failure coming at them, saw it as inevitable. And yet they persisted on, at least for a while. There were many lessons to be learned. Often, it's a matter of poor communication, or not having full stakeholder buy in, poorly defined requirements, lack of charter, or contract, uh-oh. But what about too much in the way of resources? Or a force majeure? We cover it all in this podcast. Andy Walker was working on a project for the Federal Government. A modernization effort that involved technology as well as organizational change. He has some thoughts on why it fell short of the great vision.
0:02:16 AW: I was supporting the project as a service provider supporting their PMO office. And the project was very significant, 100's of millions of dollars, many, many years, looking to drive transformation across this organization. And, fast forward to the results of the project, after many, many years of false starts and re-starts and a lot of hiccups along the way, the project wound up being grossly over budget. It spent over two times the amount of money that was originally budgeted for it. Achieved a fraction of the scope that was originally planned for that, and really got to a point where it's kind of now being marginalized.
0:03:10 AW: How did that happen? Well, there's a number of things, and certainly it was a group effort and there were a lot of mis-steps along the way. The biggest things that I saw, is from the very oust there wasn't a clear buy-in to the vision of what the project was intending to accomplish. You had divisiveness across the organization from various stakeholders who felt in one party that the legacy systems were more than capable of accomplishing what modernization objectives there were. From the very beginning not having proper stakeholder alignment and sponsorship support really, really just served as the critical failure. They tried to course correct, there were some leadership changes along the way, and some of those made marginal improvements. And it's not that nothing was implemented, there was some gain and benefit that came out of that. But at the end of the day it was a fraction of what they'd originally intended. The other thing that was a big thing, is risk management. Risk management was kind of an afterthought, it wasn't a consistently applied priority. And how they managed it and actively engaged leadership and key decision makers, in the identification and mitigation, if not avoidance, of risk.
0:04:29 KL: Okay. So, number one priority, get all the key stakeholders on board. If they're not buying in, they're blocking. And risk, don't be afraid to address it, ugly as it is, you have to deal with it, sooner rather than later.
0:04:49 KL: Michael Dobson went from hosting soirees in his Hollywood mansion, which he later sold to Barbra Streisand, to trying to rev up disastrously, demoralized staff. He used project management as a mechanism to reverse business failure. In this case, it was a matter of untangling scope and quality. Clearly related, but not the same. And it's all about the customer.
0:05:15 MD: Now, failed projects are fascinating and I've been both involved and way too close to them in my career. In particular I was part of the management team of a Wisconsin company called TSR, back in the '80s. TSR was famous for a product called 'Dungeons and Dragons' started by a shoe repair man, a tool and die maker and a hobby shop cashier. They invented the game, put up $1000 to print it, hoped they would make their money back, the game turned into a fad hit, and suddenly these three guys are running the fifth fastest growing privately held company in America. Well, they watched as the sales curve went up, and up, and up, and assumed that it would continue to go up and up and up on the same trajectory. However, that's not how fads work.
0:06:10 MD: Fads peak and then they go down again. But by that time, they had not only spent all the money, but had actually borrowed, based on the sales forecast, and spent that too. And for a while it was touch and go whether the company would survive at all, but our leadership made some promises to them. We were at the time not quite able to produce 40 products a year in the game department, and under the new agreement with the banks, after firing half the people, the load went to 65.
0:06:42 KL: Woah, so more than 50% workload increase with half the staff?
0:06:48 MD: At this point, I'd been head of marketing, and so I got to keep marketing and got game design as a little extra duty, and suddenly found myself wondering what I had really stepped into. I had a fairly demoralized staff. They loved what they were doing, but while it's one thing to be excited about your work, it's another thing when you are convinced that it is utterly futile and there is no opportunity to do anything other than to fail. So I had to figure out what to do about it.
0:07:19 KL: This is beginning to sound a lot like a project management problem, or rather a place for a project management approach to provide a solution.
0:07:28 MD: We laid off 300 people in a 380 person company. We've now got this incredible workload and no company in my industry had ever come anywhere close to that many products a year. So the question is how do we recover?
0:07:45 KL: Wait for it. Wait for it.
0:07:48 MD: What we looked at is the triple constraint. And that is that there is always a hierarchy of those constraints. What do you have to do first? If you can't get it all done, how do you prioritize? And at this point, rather than brainstorm how do we get out of our problem? How do we survive? How do we rise above it? We took the opposite approach and said, "Why are we doomed to fail? Why is there no hope? What are all the things we cannot possibly do?" We know about constraints, what we sometimes forget in project management is that some constraints are actually assumptions. You think they're real, but maybe they really are not. And so as we were getting into it, one of the problems: Why can't we get it done? We don't have enough staff, we don't have enough money, we have too many products, etcetera, all of which were true, but the idea was we had a problem that our products had to meet a certain technical spec in order to come out the door. And that's why we couldn't get it done.
0:08:53 MD: And somebody said, "Didn't our department make up these specs in the first place?" "Why yes." "Does that mean we could change them?" "I don't know, what do you have in mind?" "How about bigger type?" "No."
0:09:08 MD: We'd used to cram every word on the page that we could, as to give people great value for the money, but the stuff was not actually very attractive. Somebody said, "Wow, if we could do that, how about decorative borders?" What we did, ultimately, is we redesigned the product spec. It was more attractive, easier to use, but by the time we did everything to lighten up the page a little bit, it was 40% less content. That is a huge whack to scope, no doubt about it. My question to you is, am I cutting quality? Who defines quality? The customer. And how does the customer register their opinion about our quality? If they like it, they buy it. You see, a lot of times people confuse scope and quality, because they're really not exactly the same thing. Scope is what you do, quality is what they want. And ideally, you want the two to link up, but that's not what naturally, automatically or necessarily turns out to be the case. Turned out our sales went up slightly. Whacked scope, but arguably improved quality, that's what the customer wanted.
0:10:28 KL: Know thy priorities. Sometimes solutions come in unexpected forms. For Joseph Madden the key lies in quantitative measures, including historical data. The more data, the clearer the path, whether you're setting up your project or re-setting it when it goes off the rails.
0:10:50 Joseph Madden: The story I wanna tell you about is a project that was headed for disaster, and it's one of my early opportunities to apply some new techniques to project management, specifically using quantitative measures to estimate the project through monitoring control, and then benchmark and compare with historical projects. The client was the Air Force material command. And basically the project I'm talking about, it was unfortunately a somewhat typical software development project, where the team that bid on the project they bid a six month project. And they were a year into the project when I got the call to rescue the project, figure out how they could get back on track. They'd already doubled their schedule, but worse, they had told their stakeholders seven times in a row that, "Oh, sorry, we slipped the deadline, but we'll deliver next month." And then that day came and went and, "Oh, sorry. We meant two months from now."
0:12:09 JM: So, they slipped their schedule seven different times. And each time it got escalated up higher in the client organization, to the point where they had a three-star general so angry that he was ready to ban the company, the contractor, from all future business in his command. So, not only would that have been the failure of that project, but that would've effectively shut down the regional office of the contractor I worked for at the time. So, very high stakes.
0:12:51 JM: I looked at the project and I applied a quantitative approach to estimating the project. I basically revisited the project estimate, and I used a parametric tool called SLIM.
0:13:05 KL: Okay, a definition, just in case you don't a copy of the PMBOK handy. A parametric tool is a piece of software that helps you do parametric estimating, which the PMBOK tell us, "Uses a statistical relationship between relevant historical data and other variables to calculate a cost estimate for project work." So, you set parameters for estimating the future and you use the input of real data to make the projections. Its power is in it uses real data. Its weakness is that it... Well, without getting into the statistics, that it assumes that all things being equal, which often they aren't.
0:13:43 JM: I used a parametric tool to compare, look at the functionality they were trying to build and the schedule they were trying to meet and the staffing they had applied. And I leveraged some historical trend lines of other projects. And my conclusion was that it was a two-year project. So, when I delivered the news to that senior partner, he slammed his head down on the desk and I said, "Oh, I can change the assumptions." And he said, "No, no, no. We went through that in excruciating detail." So I had to help him explain to a three-star general why a six-month project was gonna take two years.
0:14:33 JM: Pretty much everyone involved thought that that was the end of it. The project would get cancelled, they'd lose all their business. People were really worried about what was gonna happen. But I helped him put together a very painful briefing with metrics and quantitative data, and showing some example, historical projects that, "Hey, for something with this amount of functionality, it's not unusual for it to take two years." And believe it or not, they delivered the briefing and they survived. And even though they weren't happy, everyone pushed their chairs back and said, "Hey, maybe we all under-scoped this project." And so with the facts and data in front of them, they gave the contractor permission to continue the project on the new two-year schedule. They didn't get any more money, they had to eat the cost of their fixed price bid. But they got permission to continue the project, they delivered on time on that two-year schedule, and they were awarded follow-on work. So, since then I helped many projects like that get back on track, or better yet, get planned right upfront so you don't have those issues. But yeah, but to this day I'm just blown away at how powerful facts and data and leveraging historical project data, how powerful that can be.
0:16:18 KL: Cleve Arrington could have used some more data before jumping into this failed project.
0:16:25 Cleve Arrington: Let's go back maybe a year or so, I was working on a very low-scale IT project. And essentially, what we were trying to do is automate a particular process. And what I mean by "automation" is, replace some brick and mortar processes with some more current IT process. Well, the as-is process consisted of folks mailing in documentation to get particular services done. However, it was taking a long time. And not only was the process taking a long time, once the information was received at our organization, then we had to obviously process it and take the manual information and input it into a system. So, the stakeholders had requested an outside group of people, consisting of a project manager and IT folks, take a look at the as-is process, and work with them on improving it through our Kaizen processes. We agreed that it was worthy of doing, so we partnered with this particular group. But what we found out once we got into the project, the needs assessment just wasn't clear, what was actually going on. And the requirements was just all over the place. And it seems to be some more internal, as well as external influences that we wasn't originally aware of. In other words, congress warned our customer about improving the process, and mandating that they do something. So instead of doing a full-blown needs assessment, they just carved something out. And they thought this very small process, or automation, if you will, would fix it. But it didn't.
0:18:38 CA: In fact, once we got into the requirements, we found out that it was more involved. It required a lot more specificity, and we were dealing with personally-identifying information, such as social security number, mailing addresses, where an individual worked. A lot of personal information that we were originally wasn't aware that were gonna be problematic. We had to vet this with other security specialists. And once we proposed to them what we were doing, they were totally against it, indicating that we did not have the proper systems in place. The customer insisted that this was only a patch fix. In other words, that they were encouraging us to do it, realizing that later on, that it would go back and automate the complimentary system that they had in-house. And by the way, their projection was $75,000, which is really no money. We evaluated, not only what the customer wanted, but we took into consideration what the security folks had provided us, and we determined that we couldn't do it. What I learned from this, as I work on other projects, make sure we fully understand not only the requirements, but what the constraints are. Constraints are very important. Make sure you talk to all the right stakeholders, not just a particular stakeholder. They obviously have their own reason why they wanna do something, but we actually have to canvas all the other stakeholders, and make sure you understand everyone's perspective.
0:20:33 KL: Lesson learned. Study thoroughly the scope and requirements of a project before you take it on.
0:20:45 KL: And in order to get a grip on the full scope of a project, it helps to get input from the full range of stakeholders. It couldn't hurt. And it definitely would have helped Susan Schwartz when she embarked on this project.
0:21:00 Susan Schwartz: Well, it was a disastrously failed project, because it was one of those group-think moments. We were going around the table. I worked for a technology training company. And I said, "Well, the federal government is standardizing on gossip." It was supposed to be the ultimate in interoperability. And all of a sudden, my boss said, "Well, that's a huge market. Let's do it." So, I spent time, I created a whole course. I developed a whole course. We marketed the course. And we never delivered the course, because nobody wanted it. And fortunately it was just me, and we didn't lose a whole lot of money on the effort. But whenever I work on a project, the lesson I pulled from that, was to make sure that there was a real need. That there was a pain point, and that it wasn't just a cool idea. And so what I took out of that project, was just the importance of aligning your project with the corporate mission. And it's really important that you know who your audience is, and that you have stakeholders on board, and that your project addresses a crucial mission for the company.
0:22:31 KL: How many of you have experienced this? The project that never ends. Dishant Shetty stuck it out for a long time, as the scope moved further and further to the right.
0:22:42 Dishant Shetty: It was a project that was at one of the larger banks. I won't give the names here. One bank had merged with another large bank, and two global organizations merging. And I had joined them as a project analyst to help them through the merger project. So it was in their treasury department, which they were merging for two banks. And the bank that bought the heritage bank, was actually acquiring the teams and the processes of the bank that they bought. And for the global project, which was a typical workflow project that was being made. And one sign, of which I got the first sign where that project was failing, nobody ever said that it's failing. That's one thing. The project went on forever. That's another sign what qualifies as a failed project. Third sign was, scope kept on moving right. Like, next release we'll do this and next release. And the releases kept on coming after one another, when nobody took up the responsibility of saying, "Okay. Let's shut it down, and say this failed, and let's start again." Nobody did that for several years. For three, or four years it kept on going on. Millions and millions of dollars have been spent. Several developers working, several analysts working, PMs coming and going, but the project went on. I quit after three years, so I don't know what happened after that. From what I heard, it went on for a couple of years after I left as well.
0:24:18 DS: Because of the merger, they could write off a lot of that as a merger cost, so that had some degree of high hopes there. But the reason that I think, because I kind of grew into the project right from the beginning to the end and I saw, was original scope was not realistic that they started with. They would have never achieved that. If somebody tries to make a Taj Mahal, it's probably not gonna get there, and they were not gonna settle for something that's a notch smaller than that.
0:24:58 KL: If the leader of an organization fails to lead, can you hope to implement a project involving organizational change? Elizabeth McQueen says, emphatically, "No."
0:25:11 EM: This was a transformation project. This particular company was a small company, and the owner founded it a number of years before and had run it with sort of an iron fist, and this was the way things were going to be. And he was a nice man, but he had some very specific ideas about what he wanted to do. He also wanted to achieve a certain assessment that would help him win more business, so it was the capability maturity model he was going after. And the only way to successfully be assessed at a certain level of organizational maturity via that model, is to in fact embrace and execute on certain mature methods of running a company. None of which this gentleman [chuckle] was interested in doing. But I was the lead on that project, and I worked with all the different organizations and departments in the company, and I was armed with a very good understanding of the model and training in it and so forth, and we made a lot of great inroads. But what happened was, because change needed to start at the top, and the individual at the very top refused to change, there was no way that could possibly have been a successful project.
0:26:38 EM: I very distinctly remember the day I decided to leave that company was when we were in a meeting and the president was at the head of the table, and those of us who reported to him were all around the table talking about what we were doing. And when it came time for me to say that some things needed to change and I needed his support to make this happen, he pounded his fist on the table and told me, "I would make it happen." I remember thinking, no one could be successful in this position in this project right now. So it taught me a number of things about change management. Unless you have got that commitment from the top and they in fact lead by example, and they are going to set that standard and the precedent that we are all heading down this better path, it's gonna be extremely challenging, if not impossible, for that type of a project to be successful.
0:27:38 KL: Unclear leadership was at the heart of the difficulties plaguing the notoriously fraught implementation of the Affordable Care Act. Actually, according to Jimmy Church, that was just the tip of the iceberg.
0:27:50 Jimmy Church: I joined the project a year into the implementation and so I got to see the final second year, and then the project leading right into October 1, where everything kind of fell apart. But this is not to say that I have the comprehensive understanding of what I think went wrong, but I can just give some glimpses and some snap shots. The first that I noticed was, the note of project authority. It was unclear, and at least in the initial stages of the project, which agency was going to be responsible for this project, and whether that was going to be HHS, Health and Human Services Proper, or whether it was gonna be CMS, Centers of Medicate and Medicare Services. My understanding is that the project authority started off at the HHS level, and then a year into the project there was a political dispute and project authority shifted to CMS. And so I think there was some falling out complications and communications, and project planning that fell apart as a result of that authority shift.
0:28:50 JC: The second one was that funding was entirely complicated, because all the funding went to CMS, and there were several agencies that were involved in this project. There was OPM, SSA, IRS, even Peace Corps was involved. And it was unclear to the other agencies that were participating whether or not they would have the funding or the budget appropriated to them in order to participate in this project, and so because of that we noticed a little pushback from other agency leaders to contribute resources to move the project forward from their agency's perspective and their agency's stand point. Project communications was also very complicated and I think that came through in the project planning phase.
0:29:43 JC: My observations was that this project seemed to be two very distinct and different worlds. The first world was the website side, which was run by a different contracting firm and in support of CMS. And then there was the less talked about second world, which was the IT infrastructure side of the house. And so these two different worlds were being built simultaneously, because this was a project where you had to build the plane while it was flying. And so those two workstreams were working side by side, but were not communicating until the very, very late stages in the project. Which I think really compressed the time of being able to hook up the website to the IT infrastructure, which I think made things fall apart quite a bit. So the project planning, there was little to no communication between the two worlds early on at the onset of the project, and then throughout, at least in the year that I was there.
0:30:37 JC: There was also another communications flaw that I noticed in the project. So on the IT infrastructure side, I was personally responsible for getting and making sure that all the agencies were working along the same project plan. And so when I joined the project a year in, and I went out to all the different agencies, other than CMS, that were participating, many of the other agencies that were participating didn't have a project plan for the implementation of the Affordable Care Act, and were actually confused when I came to them asking the question, "Can I see your project plan?" 'Cause it was my job to consolidate them and make sure that everyone was working on the same. Something went wrong there. It could've been because of the project authority. It could've been because of the project planning, but there was no communication to those other agencies that they were even to be expected to have a project plan of how to do the implementation. And that could've been for all sorts of reasons, communication, funding. If we're not gonna be funded on this, why should we have a project plan? And things like that.
0:31:41 JC: And then the last point I'll make, I noticed generally a lack of a sense of urgency. We are working with some pretty tight deadlines and... This is very anecdotal, but I saw a very clear case of where our team was not able to test the IT infrastructure with all of the states, all of the agencies, all at once, because we were held up by a simple procurement to get an IT security certificate for the Department of Defense. But it was an acquisition that needed to be made by CMS and that was not made. And it took actually three months to spend 200 bucks to go get an IT security certificate so that DOD Tracker could connect. And that delayed testing of the entire system for roughly three months. And there was one point of failure, and that point of failure had absolutely zero communication for three months, and I just kinda scratched my head on it. It's very anecdotal, but generally that situation was not unique. There were pockets of excellence where there was a good sense of urgency in getting things done, but it was certainly more than half of the time that you noticed that there was a lack of sense of urgency.
0:33:00 KL: What if you really wanna get a project done because you believe in it, because it's the right thing to do? Is that enough? John Rothenberg has been there, done that.
0:33:11 John Rothenberg: I was part of the civilian surge and went with USAID to live on a base in a province that I won't mention, in Afghanistan. I was a field program officer and my job was mainly partnering and mentoring with seven provincial line directors, including the Director of Education. So one of the problems I had was that because my province was so dangerous, USAID, even though they sent us there, didn't have any program money for any programs in my province except for one, and that got assigned to somebody else. So anything that I did, I also had to find somebody to give the money for. The Director of Education and I came up with this program, where we were going to use one laptop per child to improve the education outcomes in a high school in the provincial capital, and we needed $200,000. So first, the implementor and I went to USAID and tried to get it funded through other means at USAID. And when we found that we couldn't, we then went to the American Army Brigade in my province and we got what's called Commander's Emergency Relief Program, CERP money, to do the project. So we got the money and we were about to buy these laptops, and the brigade decided, because of information from on high, that they had to more strongly control what was going on.
0:34:55 JR: One of the rules was that only 10% of the money can go out in the first payment. Half the money was going to pay for the laptops. So there was no way that this small company could do this project without laying out the money first, and they didn't have the money to lay out at that point. So it took the company basically a year to accumulate enough funds to buy the laptops. During that time, the brigade that originally paid for this moved out and a new brigade came in. When they came in, I was on my home leave and I didn't create any stakeholder relationship with this brigade. We ordered the laptops, they were coming in, and a side thing happened and some soldiers were killed by a roadside bomb near the high school. And the brigade decided that they were no longer gonna fund the project, even though the laptops were on their way, so it was totally cancelled.
0:36:12 JR: Some of the things that we did wrong, as far as I'm concerned, was that I tried to push the thing without the proper sponsor being the sponsor, okay? I really should have, there was no way I could've done it, but I should've gotten USAID or another donor, rather than getting the CERP funds. And my boss basically had told me that I shouldn't get CERP the funds. The other thing is that I didn't do proper stakeholder relations with the new brigade. The third thing is, is that even though I was the project manager, the way that CERP is funded, the CERP manager is considered to be the project manager, whether somebody else is the project manager or not, so that it created a lot of different problems along the way. The fourth thing is, is that, because this was being done on a provincial reconstruction team, the organizational structure of provincial reconstruction teams were being developed as we were working, so that who was the real boss and who were the real workers was never defined. And so I was reporting to USAID people, State Department people, and US Army people, so that it was never clear who was making decisions.
0:37:43 JR: I'm always over-eager in what I do in Afghanistan, and sometimes I achieve the impossible and sometimes I don't. And this was my worst failure, but I don't think that over-eagerness is a bad thing there, because it's such a challenging situation. You have to be over-eager to get something done.
0:38:07 KL: And by the way, there's an interesting epilogue to this story.
0:38:11 JR: In the end the contractor that I was working with actually came up with a way of putting the software onto smart and not smart phones, and he's got a thriving business doing education projects on phones, because they're cheaper. We could've done it just as a software implementation and gotten everything done properly.
0:38:41 KL: Have you ever been so eager to take on a project that you skip the most important step? The sine qua non of project management, the charter? Mark Tolbert found out the cost of not doing that, the hard way.
0:38:54 Mark Tolbert: More than a decade ago I was managing a project where my part of the organization was gonna provide custom installation services for a large roll out, for one of the main shipbuilders in the United States. And this was 1000s of computers that were being upgraded and we were installing these computers over a weekend, so it was turnkey. The users, the customers could come in on Monday and the network IP addresses had been loaded and new software had been loaded, peripherals were connected. So that was our part of the project that we were bidding on. Another big part of the project or program was of course the sales of the computers themselves, and that was a much, much bigger part of the program. So, our little part, the installation and support services, were not even 10% of the entire sales. The entire product sales side of it was 10's of millions of dollars, and our part of it was 100's of thousands of dollars. So, we couldn't get the customer to agree on signing off on what the pricing should be for just one part of our installation service and our support services. And to be honest with you, the customer was not totally honest with us or playing fair with us, and was stringing us along.
0:40:23 MT: So we did a pilot installation of about 100 computers for them, 100 sites. And that all went perfectly well, proved to them the concept, proved to them this would all work, but the sponsor, the financial officer with the customer side of the company, still wouldn't sign off on the contract for our part of it. We provided the deadline and we said, "If we don't get a signature on the contract, then we can't go forward." And then, this is showing us the problem of not having a charter and not having a contract. So the product sales people, who are really the key sponsors, they are the key drivers in the organization, wanted us to go ahead and proceed with a second pilot phase, a much larger installation phase. And I said, "This is not a good idea. Without having the signed contract we don't know that this is gonna come through. We've proven everything we need to prove about this." And so management on my side agreed that we shouldn't move forward. So the product sales person turned to a subcontractor to do our project management part of the installation thing, and they messed this all up. They didn't file the paperwork properly and it led to an incredible disaster. The customer, they installed several hundred more new computers on their own, they lost the paperwork and the audit trail.
0:41:57 MT: The customer was gonna refuse to pay for that work until they had the signed signatures and all the paperwork that this had been done properly, and they dotted the I's and crossed the T's for what was supposed to be done. And the vendor, the subcontractor, couldn't come up with that paperwork. So they said, "We're not paying for it." Well, that's fine, that's only maybe $10,000 dollars worth of installation work. But we're talking about computers that touched many different orders. This was well over $3 million or $4 million of product sales they weren't gonna pay for either, unless they got the signed paperwork. And it just shows, if you do not have this charter, if you do not have this signed contract, that you are in an incredible risky position. And at the end the bottom line of this was, the CFO, the person that was playing games with us, ended up getting fired over this issue. So be very, very careful. Make sure you do have that paperwork, and the charter, and all the I's dotted on that thing before you proceed.
0:43:11 KL: We've all heard about not enough resources. What happens when you have an over-abundance? Does it happen? Micheal Van Dyke tells us about when too much is not a good thing.
0:43:22 Michael Van Dyke: At one point in my career I was the technical director for the Yale School of Drama. And we looked at each season as a project. Now because it was an educational institution the designers always felt that they didn't have enough time and didn't have enough money to do their best work. So the faculty decided to increase their budgets by $500, it wasn't a lot. The disastrous outcome was because the Yale Repertory Theatre builds multiple shows at the same time, so pieces of scenery at the same time, we ran out of room in the construction shop. We ran out of room in the paint shop. We ran out of room for storage for the props. And it was interesting 'cause it was my first year, well, it's actually my only year, as the technical director for the combined Yale School of Drama and Yale Repertory Theatre. And it wasn't until years later that my boss, the production manager, we ran into each other at a conference and he said, "I didn't believe you, that it is was because they had this extra money. It took two more people rotating through your position for me to see that it was indeed that we didn't have the resources. We didn't have the physical resources to accommodate just a little more money."
0:44:53 MD: To me it's a wonderful example of when we talk about interrelated constraints, we're usually talking about that we don't have enough of. And sometimes just one little change will create a ripple effect throughout the rest of the project.
0:45:16 KL: We project managers are can-do kind of people. But sometimes it helps if we admit that, guess what, we can't. Steve Schiffer bit of more than he could chew and suffered the consequences.
0:45:28 SS: This was about seven years ago, I was leading a project at a manufacturing company. It was about a 1.5 million square foot facility in the automotive industry, and I was asked to lead a project to improve material flows, as the current material flow processes were limiting their capacity. And actually the plant was in financial distress because of poor material flows. I took a look to see what the scope of work should be to hit the goals that they had set, and I outlined my resources, my timeline. Resources in terms of money. Resources in terms of people and the kind of people I needed. They got back to me and they had told me I couldn't have all the resources that I wanted, and that my timeline couldn't be what I'd ask for because the work need to coincide with their summer shut down. So they cut my timeline down from, I think I'd ask for 15 months, down to nine months.
0:46:42 SS: And they cut my money by about a quarter of what I'd asked for. But they said we can't compromise on the scope. So that's like a trifecta for failure. There were red flags up and I went past every one of them. I knew what needed to be done, I've done it before. And I just said, "I gotta do this. I can do this." There were a lot of jobs at stake, actually. It would've been very tough to say, no. And the other thing that happened too, is there where other projects going along in parallel with the material flow improvement. They where making upgrades to the assembly line and some of the machining lines. Within the two months before implementation they also threw some scope changes to us. I look back at it and I say, "Man, how could I have been this big of a fool, to think that, well, I'll just have to work a 100 hours a week and I can make this go through." And I'd really overestimated my capabilities.
0:47:50 SS: So what had happened was, when we finished the summer shut down and started up the assembly line and we started to deliver materials to the line, it did work much better than the old system. But we came way short of what our target was, and this was a cause of great consternation for me, because our chief operating officer, our plant manager, and a lot of other people said, "It wasn't supposed to work this way, it was supposed to be a lot smoother." And I said, "Well, yeah, but you didn't give me the resources I wanted, you decreased my timeline." Nobody wanted to hear about that. And that was not the time for me to bring that up. I was seen as making excuses, where I had really, the way I looked at it, I'd really worked my butt off. It took us about six months later to hit the goals from the original scope. And what I take away from that is, that's what I should have done in the beginning, to say, "Okay, we're going to do this in Phase One and Phase Two."
0:49:00 SS: So if I would have told them up front, "Given the cut in resources, here's what I can get done by the summer shut down, and then I'm gonna have to keep my resources for another six months in order to complete everything." It would have worked out much differently for me. I ended up having severe high blood pressure, because I worked so hard just trying to make that work, because it was my name on the project. So I come away a much wiser man, a little worse for the wear but not too bad.
0:49:41 KL: Now here's a common one we heard. We've all seen it, the low bid. And then you win. David Offenkrantz gives us his version of this tale.
0:49:51 DO: The project that I'm gonna talk about for a few minutes was a government contract we did for a government agency that was trying to put together an offering for their customers to be able to use cloud computing services and market it to their customers inside the government. So there were a couple of problems with this one. One was: The company that I was working for, the government contractor at the time, had deliberately low bid in order to win the contract, knowing that they would not be able to staff it with the quality of people that were gonna be needed to do the work. But they wanted to win the bid, so they were buying the qualification, so to speak. So that was the first problem. Once we won the contract then we had to deliver. And this was when the government, although they said it was best value, it was really lowest price is what they were after. Another problem was that the requirements were never completely nailed down. So too often it was a case of, we would build something, show it to them and they'd say, "We don't like that. We don't know exactly what we want, but that's not it."
0:51:14 DO: So we went through several iterations of that, which was very frustrating because our team had not done a good job of nailing down the requirements to begin with. And the government was very difficult to pin down once we got the contract. Then a third reason it failed was that the program manager, I was the deputy for this, the program manager took the stance with the government that, "We have SLAs, you bought a solution from us, it's a black box, don't worry about it until we deliver." And the government, obviously they were not happy with that. But it did not promote a good communication across between contract and customer, so that it ended up fostering a climate of distrust, where they didn't believe that we could give them what they wanted. Ultimately what happened was that the contract was terminated by the government. They gave a stop-work order.
0:52:31 KL: Even the best laid plans can fall apart. Davin Hattaway piles contingency on top of contingency. Still, when you're doing risk assessment how often do you account for a force majeure? It's in the PMBOK.
0:52:45 DH: Well, a big part of our job is planning major conferences for non-profits in the area. And conferences are interesting as far as projects go, because it is literally years of planning, scheduling, but all the execution happens over the course of three days, long after you're able to do any sort of fixes. 'Cause you can't come back next week and say, "I'll get back to that." And then can't put more resources on it, because the resources, you're in the town and you got what you got. For that reason we always layer contingencies upon contingencies upon contingencies, 'cause you never know when your plan B is gonna fail and you find yourself down in plan E. That's a normal part of the business. Every now and then though we get something that exhausts all of our plans and we have to make it up on the spot. That was the case with one of the conferences we were doing in Baltimore earlier this year, in April, and that date might ring a bell to some people. We'd been planning this for about two years. It was running swimmingly, we're on the second day of the conference the attendees were thrilled.
0:53:35 DH: And we started hearing about some of the riots up north of town. Alarm bells go off. We start making other phone calls, confirm, because we had a big evening planned. We had rented a private box at Oriole Stadium. All sold out there. We had a number of restaurant trips and then down around the town, everything to keep the attendees organized and get them refreshed through the final day of the conference the next day, where we had our big keynotes that were gonna be the center piece of the whole presentation. Called around, we got confirmation from Oriole Stadium, from everybody downtown, from the safety managers in the hotel, the security staff, the police, that the riots are 15 miles away, really nothing. There's no risk. You can proceed as normal, downtown's safe. So we proceed as normal. All the time thinking of, "What if that doesn't pan out as we're expecting?" So we finally get the attendees down to their box, everybody's enjoying their first round of beers at the Orioles game, we're still getting assurances that the game's gonna go forward. And then mayor declares a state of emergency, because the riots had moved closer. And in fact, they are moving towards downtown and would arrive any moment. That leaves us with one, in a crisis situation, we have to get our attendees physically back. That involved figure out where the rioters are moving and plotting routes back for them, getting everyone then.
0:54:40 DH: A simultaneous problem though, is no one had had dinner yet. And it'd been a long time since lunch, and they were gonna be putting the hotel on lock-down. People couldn't get out because a lot of the roads were closed. And the one restaurant in the hotel only had capacity for about 50 people, and we were about to bring 300 hungry mouths their way. So, what we did, we were able to summon up all the appropriate staff. We brought our entire team. Some had already gone off to other sections of the city to handle other business. We summoned everybody back as quickly as possible. We made quick arrangements to design a quick new menu with the hotel, that's something that they could put for enough people in a short enough amount of time, arranged space outside the restaurant to host them. Made an impromptu reception, and that was important, too, because the sponsor had paid quite a bit for that private box sponsorship, and we had to give them some equivalent. And everybody went to bed happy that day. Everybody distressed and scared, 'cause the riots got within about a block of the hotel. But everybody was safe and they had an enjoyable evening.
0:55:33 DH: Then you come onto day two, and because we had primarily high level government speakers, one after the other, we started getting the calls at 6:00 AM. Their security teams would not let them come anywhere near us. So our entire second day agenda was shot. Both of our keynotes were gone. Our big name speaker that was supposed to wrap up the conference and leave everybody on a high note would not come within 50 miles of us. And we still had the whole group of people expecting to be fed and educated. Our mitigation plan was to find alternative speakers. Luckily, when you have a conference full of high level people, high level people also attend to hear their peers speak. And so we found people who could speak within the audience, who'd be willing to do an impromptu panel discussion on interesting topics. And we stretched out parts of the agenda to pad it out a little bit more, a longer Q&A section, which goes very well with panels anyway. And a longer and more lavish closing reception, 'cause we didn't have a keynote, but we could make it an outstanding networking event.
0:56:26 DH: So on the whole, the conference did not go well. People didn't get the sort of things they paid for, and they didn't get the education they wanted, and that's something we just couldn't fix. But we could do our best to make it right afterwards. So it was a long process of negotiating with all of the venues we had contracted with, getting appropriate refunds, negotiating with Oriole Stadium, who was reluctant to give up all the money they had collected from that private box. And of course, making sure our attendees and our sponsors left happy. And so what we ended up doing there, we actually re-did the entire second day of the conference three months later. We were able to get all the speakers back on board, everybody who missed it was invited to come back complimentary, and quite a few sponsors even added additional sponsorships, 'cause they loved the idea so much. So it was a delayed success with a good period of three months of failure in between.
0:57:16 KL: So much failure, and we see it coming in IT, health care, the theater, citizen delivery, conference and manufacturing projects. On an earlier podcast, we had an executive who noted that what was most difficult with project managers and project management, was when they didn't act like project managers. But not so here. I listened to these stories and can only have high respect for the PMs that put their whole effort, their minds and their hearts into saving these projects. I was also struck by how odd it is that organizations and the executives that run them want projects, and then almost forget about them, or forget what it takes to deliver them. Wrestling the requirements, the communications processes, the executive demands, even when we can see and even when we ask, "Why are we doomed to fail?", we still get caught holding the bag sometimes.
0:58:04 KL: But as Steve Schiffer said, the PMs come away the wiser for it. And as we heard, there are sometimes the magical workarounds, the adjustments to scope and design, the jump to yet new contingency plans, that allow the failure to be turned around or mitigated. So this is not just about failure, but how we can achieve success.
0:58:22 KL: Special thanks to all the PMs who shared their stories. Andy Walker, Michael Dobson, Joseph Madden, Cleve Arrington, Susan Schwartz, Dishant Shetty, Elizabeth McQueen, Jimmy Church, John Rothenberg, Mark Tolbert, Michael Van Dyke, Steve Schiffer, David Offenkratz and David Hathaway. Thanks also to guest hosts Uma Hemelagalor and Mary Flannery for their help in getting these stories from our project managers. I would also like to thank all of the PMs who took the time to come and talk to us during the symposium. We weren't able to capture all of the ideas, but guess what, folks? There's a lot of failure out there to learn from. Sounds like a Part Two to me.
0:59:06 S7: Our theme music was composed by Molly Flannery, used with permission. Additional original music by Rich Greenblatt. Post-production performed at Empowered Strategies, and technical and web support provided by Potomac Management Resources.
0:59:24 KL: PMPs who have listened to this complete podcast may submit a PDU claim, one PDU, in the Talent Triangle's Strategic and Business Management, with the Project Management Institute's CCR system. Choose the REP chapter sponsored PDU education category. Search under C046, the Washington DC Chapter, and submit or search code PMPOV0023, entitled Project Failure! Yes, that's with an exclamation point. I'm your host, Kendall Lott, and until next time, keep it in scope and get it done.
0:59:58 S7: This podcast is a Final Milestone production distributed by PMIWDC.
1:00:05 S?: Final Milestone.
About the 'Project Management Point of View' Podcast Series
© PMIWDC and Kendall Lott
This podcast series is a collection of brief and informative conversations between MPS President, Kendall Lott, and a wide variety of practitioners and executives. His guests discuss their unique perspectives on project management, its uses, its challenges, its changes, and its future.