7.5 Prepare for critical claims and disputes - Video Tutorials & Practice Problems

<v ->Some of the other issues</v> that we have to concern ourselves with. For many of you, this is not the case. For some of you, in your organizations, because you're dealing with clients and you're dealing with contracts, you have to become a little bit conversant in contract language. That's somewhat scary. And obviously, this is not a course in learning contract law. That's not my intent. What I want to do is to make you aware of some of the critical issues as they relate to these ideas. So one of the things that happens upon project transition, turning it over to the customer, is we immediately analyze are there any outstanding claims or disputes that exist between us and the customer? So for example, one type of claim are what are called ex-gratia claims. Ex-gratia claims means sort of out of the goodness of my heart. This is where a customer may say, "You are not personally responsible for this. Something else occurred that caused this to happen. However, this is really upsetting." And so what we might do is we might say, "All right, look, here's what we will do. We will sweeten our deal because we realize even though we didn't cause the railroad company to delay delivering this to your site, we will take $20,000 off the overall price here just to maintain good relationships." So are we required to do it? No, but we may go ahead and decide to do it, again, just as a relationship builder. So out of the goodness of our hearts or out of our benefit, we're going to engage in those kinds of claims and settle them. Other claims, of course, the classic or default. Default claims are the serious ones because these are situations where we did not deliver as contracted. Now, our cost may have blown up out of contract, our schedule may have blown up outside of the contract, or the technical performance may not live up to what was contracted initially. Any one of those are sufficient grounds for legal dispute. And we have to recognize, claims can be made against us by these contracting organizations, and the customer may say, "We want money back. What you did is, or what you've created here is not sufficient." So if we know this in advance, we need to prepare for these kind of claims coming from the customer organization. We can resolve these in a lot of different ways. And again, it's not my goal to go into any kinds of legalese here, just recognizing that there are certain things that can be done, such as arbitration. We can get binding arbitration that will work on both sides. We can get non-binding arbitration. That's where we bring in an arbitrator, they listen to both arguments, and they say, basically, "You're at fault, but so are you. My best take is that you should resolve it in such and such a way." We may agree to that. We may agree, they may disagree, and so it may go beyond that. But the point is that you may have binding or you may have non-binding arbitration that can resolve this. Hopefully we don't get to the next point, which is litigation. Litigation is used when one or the other party wants to recover costs, when they feel that the other person has not lived up to the contract terms. And so therefore, what they're gonna do is they're gonna go after you by suing you. And like I said, we hate for things to get to that point for a variety of reasons, not simply because this could potentially cost us money, but it could cost us a customer and it could cost us that customer's customers. Because one thing we know, folks, and we all know this, is that when I'm dissatisfied with a service, I don't just tell the person I'm dissatisfied with, I tell all the people I know. So I am a billboard for my dissatisfaction. That's why we wanna avoid these kinds of things happening as much as possible. So how do we do this? Again, protecting against claims, there's a lot of different things to consider. So just a couple things to sort of keep in the back of your mind. Part of your project plan, part of that planning process, going back to your scope management plan, should consider these issues. Is there a chance for claims being made against us? If yes, how can we start protecting ourselves upfront? What kinds of agreements, what kind of contract language do we want to get from the customer before we're willing to sign to do this project? Because if there is something we can protect ourselves with early in the process, of course we wanna do that. Alternatively, make sure that the stakeholders understand their risks as well. This isn't just about us. This is also about the stakeholder as well and the risks involved in this. There are story after story after story of projects that have blown up that have been absolute disasters. Sometimes the stakeholders understood the risks, sometimes they simply didn't. We need to make sure that they do understand as much as we possibly can. Obviously, not to the point of scaring them off, but at least in terms of due diligence. Because if we do get to the claims point at the end of the project, one question that's gonna come out is to what degree did they understand these risks going in? And we have to make sure we have some basis for documenting that they understand the nature of the different types of risks. Your best weapon against claims is record keeping. I can't emphasize this point enough. For some of you, maybe you're kind of silently groaning when you hear me say that because you're just not record keeping kind of people. For others of you, you're silently cheering when you hear me say that because you're naturally good at keeping records and maintaining all this information. Folks, whether you're good at it or bad at it, become good at it. Recognize that keeping good records, the first thing your company's lawyer is going to ask is "Give me your paper trail. We are getting sued or we're having a claim against us for this or that. I need the paper trail." And if you don't have it, if you say something like to the effect of, "Well, I thought they were, I thought he was a gentleman, so this was just his word." So what you're saying, basically, it's his word against yours. Yes, okay, that's not helpful. We need to make sure that we have as much record keeping as we do to keep clear details of change orders. If the customer wanted this, then we say, "We can do that for you, and here's the change order, here's what you signed off on, and by the way, it's gonna cost X amount of money." Get that all clarified upfront. The last thing you want is downstream for the customer to say, "Well, I had no idea what was gonna cost that much. I'm not gonna pay it." Make sure that every step of the way you have clear details of the change orders, of the cost of the change orders, because that will save you a lot of grief on the back end if necessary. Archive all correspondence. Again, that's the record keeping, folks. Any emails you get, print off a copy or put them into a folder on your machine, back it up. Make sure that you've got all correspondence retrievable when you need it, and you've got it in some order so that you can call this stuff up at a later point if you absolutely need to do so. The elements of the final report that you're gonna create are gonna vary depending upon the organization. For some of you, you're probably looking at this now and saying, "I don't do final reports." Good for you. For others, your final reports are massive, comprehensive, and almost debilitating. They're just huge, enormous sorts of things. There's no simple formula for what a final report should contain. I'm going to offer a few suggested elements that should go in final reports. You have to parse through these yourself and decide, okay, to what degree are these the elements that I need to pay attention to given the kinds of projects I run? The first is project performance. How did the project go? Earned value is wonderfully helpful here. If I can chart not just the progress of the project in terms of the money we spent or in terms of the milestones we hit, but if I can set up the earned value and I can show over time how this project has performed, it's a wonderful device to identify these sorts of things. Administrative performance. How did the way we set up the project team go? Was there sufficient oversight? Did we need another person there that we didn't have? Did we have enough programmers or enough builders on site or enough brick layers? Did we have the right people? Did we plan correctly? Did we have the right paperwork? So that when you developed your scope documents at the beginning of this project, unfortunately, you left out whatever. For future projects, we need to make sure that we include these kinds of documents in the initial scope development because they're gonna come in handy later on. Organizational structure. What did the project team look like? Who was in charge? How many people were involved? How many people were direct reports? How many were dotted line reports? How did this structure work? Was it clunky and way too top heavy? Was it a structure that didn't allow the project manager to be able to even do project reviews on all the people on the project team? Is it a project where there was more than one cook all giving orders to the project manager? So constantly, he was having to balance this person with this person with this person, trying to find a middle ground. What did the project's organizational structure resemble? Did it help or did it hinder the project team? Way back, ancient history, when Steven Jobs was at Apple still, they were trying to come up with the next big thing. This, and again, years and years and years ago. When they first developed the Macintosh, they were a one-trick pony at that time. They had the Apple II, basically, was their computer and it was what we would now call a desktop. Of course, it was relatively small so they would use the term personal computer. They were trying to come up with the next big thing. And when they did that, they created the Macintosh project team and they created it as an entirely separate organization. They rented space in a building, a warehouse, and they created office space over there. They moved them completely out of the Apple office space into their own. They gave them a mandate to be creative, to go nuts, to just think the sky's the limit. They gave them the freedom to do what they needed to do without excessive organizational structure or oversight. Google does this all the time as well. Fast companies, companies that are quick to market, quick creative, constantly changing and doing things create organizational structures that allow the project team the maximum flexibility to make it happen. Does your organization reward flexibility and freedom? Or does your organization try and layer levels of oversight over your project teams? That's going to matter. How did your team do? You should do an evaluation on members of your team, performance evaluations on how they did. Even if they're informal, you should have some kind of documentation because you need this if for no other reason for future times when you're gonna be asked to run a project, you need to know who the stars are, the ones that you want to bring back to your project team. So team performance is critical. What project management techniques did you make use of? What kind of scheduling techniques? Did you use MS Project or Primavera or Scheduler or one of the other software packages? How did it work? Did you develop your scope management well? Did you create that responsibility assignment matrix? Yes, we did, it worked really well, we're gonna do it again. Did you have earned value in place? We forgot to do earned value. That was a mistake, we're gonna do that for next time. What project management techniques did you use? What worked? What didn't work? And what modifications would you suggest for that? Finally, the benefits to the overall organization. The project plan here should include the benefits, what you came up with. Because ultimately, isn't that what the whole point is? The termination stage of the project is one of the toughest ones to talk about to an audience because just like your project teams, by this point, you're tired, you've sort of felt like you've been buffeted by the winds for as long as the project has been going and it's been a rocky ride. It's hopefully been a profitable ride. It's hopefully been a productive and a successful ride, but it's been a long one. And so for you, getting to this final stage where the project is in its completion, it's in its final kick to the finish line, it's just like a marathon runner, isn't it? I've been around this track so many times, I don't know if I can muster the energy for that final half mile to the finish line. And yet, it's in that final half mile that a lot of times, the final success of the project is measured, that the final work to be done is completed, that the final emotional and intellectual activities are accomplished successfully, that the final contractual documentation is resolved. And so even though we're tired, we're tired in a good way because we're tired as we're moving toward a successful conclusion. So by all means, let's make sure that we take advantage of this opportunity to finish the project with the same level of enthusiasm, energy, and foresight that we started it, lo, those many days or weeks or years ago. Thank you.