Guerilla Project Management. Interview with Matt Karlyn. Topic: Writing Statements of Work That Keep Your Projects on Track

Size: px
Start display at page:

Download "Guerilla Project Management. Interview with Matt Karlyn. Topic: Writing Statements of Work That Keep Your Projects on Track"

Transcription

1 Guerilla Project Management Interview with Matt Karlyn Topic: Writing Statements of Work That Keep Your Projects on Track Matt Karlyn, a partner with the law firm of Foley & Lardner LLP, on writing contract Statements of Work that keep IT projects on Track. Matt, welcome. Thank you. How is current economy affecting vendor management landscape? It s interesting. I think that over the course of the past three or four years, we ve seen ups and downs. And I think that for the most part, I didn t really see any discernible differences in the way that vendors or suppliers really interfaced with customers. And the terms of contracts that vendors and suppliers are willing to give, certainly there was a change in 2008 and 2009 with respect to pricing. And a lot of vendors and suppliers became much more aggressive when it came to pricing transactions to try to win more business and make up some of the shortfalls as IT spending decreased. So what we re seeing now, we re kind of seeing the trend shifting back up. As the economy stabilizes and IT spending begins to free up again, we re shifting back towards that period of time where we were in 2006, 2007 before the current economic crisis began. You say in an article, How to Protect Your Company From Vendors Who Don t Deliver, that: At the beginning of a relationship scenario such as the supplier going out of business or failing to perform, or your company deciding to change direction seems so unlikely that many organizations fail to plan for them. However, economic volatility coupled with recent high profile cases are focusing CIOs and vendors to focus more on protecting themselves through their contracts. What are some of the key lessons learned from some of the recent high profile cases such as British Sky Broadcasting and Satayam Computer Services? Well, the cases are very different. British Sky Broadcasting is a case where the two parties litigated to the extent which a supplier, in that case, EDS, failed to perform in accordance with a contract. Page 1 of 12

2 In outsourcing in particular, very few disagreements between customers and suppliers ever make it to court, a lot of them being settled outside of court or through an arbitration process. Perhaps a more informal mediation or dispute resolution process. But British Sky Broadcasting was one of the first cases in my memory that actually was litigated. Granted, it wasn t in the United States. But that being said, it gave us quite a lot of insight into the importance of setting expectations between the parties. And the importance of dispute resolution. And the importance of a governance structure that really supports an ongoing relationship even during times of dispute. Satayam is a different scenario altogether in that at the time I believe that Satayam found itself in a bit of a crisis. I believe it was the third largest Indian outsourcing provider. And they very abruptly ran into a financial crisis, a fiscal problem, and ultimately suffered significantly. And as a result, a lot of the customers that they had fled or found that they no longer had a provider who could provide the services that they were receiving. And so British Sky Broadcasting on the one hand tells us a lot about governance structures, and vendor management, and ensuring that your transaction contains an extended amount of oversight and you're really diligent in drafting how the two parties interact with one another. And Satayam really tells us a lot about what can we do in that albeit rare chance that the vendor we ve chosen ultimately either goes out of business or can t rebound from a corporate issue. So in the article that you're quoting from, these are scenarios that a lot of companies don t want to contemplate. And our advice always is, sometimes we have to unfortunately contemplate the bad and then provide for how we re going to get out of those situations in the event that they become realities. In another article you say, Courts have made it clear that the vendor is responsible only for delivering items expressly identified in the Statement of Work. Vendors don t have to do anything you did not ask for in the contract. What's the importance of the Statement of Work or what is referred to as the SOW and how does it fit in the context of the overall vendor contract? The importance really can t be understated. Anything that you want the vendor to provide, and anything that the vendor will ultimately be responsible for providing, really needs to be within the four corners of the contract. And particularly with respect to IT, that is frequently memorialized in a Statement of Work. We frequently caution clients against side understandings between business folks on what the vendor is going to provide. And we really work hard with customers of IT services to make sure that anything that they think they're getting for anything that they think they're paying for is really set forth in black and white in a Statement of Work that is incorporated as a critical element to the negotiated contract. Page 2 of 12

3 Matt, what are some of the difference between a Statement of Work for a project as opposed to one that is for a service agreement such as providing ongoing maintenance and support for an IT system, for example? I don t think there is any difference. A Statement of Work really contains the who, what, when, where and all the details. The pricing details, the delivery details, all of the details with respect to what the vendor s going to be providing. Whether that s a project, or ongoing services, or whatever it is. So I m not sure I see a distinction between those. And what do project managers need to know about working under badly written Statements of Work? [Laughter] They need to understand that of course we hope to prevent as much as possible Statements of Work being written poorly or badly. What do they need to know about that? They need to understand that first and foremost, if it s not written in the Statement of Work it s unlikely that it is ultimately an enforceable obligation of the provider. And that being said, certainly we can in many scenarios trust the goodwill of the provider to nonetheless provide those services, but when push comes to shove and there s an issue, there's a dispute, something goes wrong, you can really count on the folks on both sides going back to that Statement of Work to determine whether or not the service provider ultimately needed to provide those services. How they needed to provide the services, what the price of those services were. And if it s not in the Statement of Work, it s definitely an easier argument for the service provider to make that they didn t ultimately need to provide them. You advise companies to resist sales pressure and take time to draft Statements of Work before the contract with the vendor is signed. Why is this important and what are the potential risks of signing a contract without a finalized Statement of Work? Certainly we do hope that companies include Statements of Work with the contract when it s signed. And there's a lot of sales pressure. Statements of Work take time to draft, and they take time to draft well. And the unfortunate thing is that that means that they do potentially and sometimes frequently delay getting a deal done. So, companies will frequently say, Well, why don t we put a requirement in the contract that says that the parties will mutually agree to the Statement of Work within some specified period of time after the contract is signed? And the unfortunate thing is that sometimes that never happens, and sometimes the parties can t agree on the Statement of Work. And when parties put together a Statement of Work and they really go through, line by line, all of the services that are expected, that are required, a lot of problems are ironed out before they become problems. So if there s a disagreement between the vendor and Page 3 of 12

4 the customer about whether the customer thinks that a particular service is included in the price, before the contract is signed it s probably best to figure that out. And the parties will figure that out when they start putting a Statement of Work together. Or at least they ll have a better chance of figuring that out as they put the Statement of Work together. But after the deal is signed, that dispute could become far more significant and far more disruptive to the relationship than if the parties had just put their heads together and figured out the Statement of Work before it was signed. So there s a lot of risk there, and the Statement of Work on many IT deals really drives the deal. And without it, it s very difficult for the parties to perform, and perform consistent with each party s expectations. Those are the things that we want to avoid. Another piece of advice you have for project managers is not to use the vendor s proposal as a Statement of Work or use the vendor s template to draft a project s Statement of Work, and instead to really think about their requirements and define them very clearly. What's the risk or danger of using a vendor-provided Statement of Work or a vendor-provided template? It might be somewhat overstated to say that customers should never use a vendorprovided template. But I think that when you are using one, you just want to proceed with an abundance of caution. You want to make sure that you have in your Statement of Work like we ve been saying previously all of the very specific details, all of your requirements. All of your expectations. What are the services to be provided? When are they going to be provided? How much do they cost? All in excruciating details. Sometimes when you use a vendor form there are some kind of tricks of the trade. And a lot of times vendors tend to put a lot of the obligations onto the customer. And they tend to have some assumptions built into the Statement of Work that really render their responsibilities, in frequent times, unenforceable. Or they just really weaken the responsibility of the vendor to provide the services consistent with the customer s expectations and requirements. So you just want to be cautious of that. I think it might be overblown to say that you should never use a vendor form. But at the same time if you do use a vendor form, a big yellow light should be going off and you ll proceed with caution. And don t forget even though you're using a vendor form, you should really go through it with a fine-toothed comb and make sure that all of the key issues and guiding principles with respect to drafting Statements of Work that hopefully customers are familiar with that you ve covered off on all of those. Vendors frequently insert legal language into Statements of Work that conflict with and sometimes make unenforceable the terms of the service agreement. And you command project managers to avoid or make sure to remove such language. Can you give us some examples so project managers can make sure to watch for these types of terms? Page 4 of 12

5 Yes, sure. So a lot of times you ll see in a Statement of Work a lot of terms. Perhaps there's a warranty, or there s acceptance testing criteria, and acceptance testing terms. Or there's an indemnity, or maybe there s a limitation of liability in the Statement of Work. There really can be any number of things in a Statement of Work. And what is frequently the case is that those terms contradict the same or similar terms in the underlying contract. And so the question becomes, are those terms enforceable? Do they take precedence over the same or similar terms of the underlying contract? And how should they be enforced? And so what we want to do for the most part, we want to make sure that all of your legal terms are really included in the underlying contract. That s where you're negotiating them, that s really where they belong. And you want to ensure that your underlying contract has a very clear, what we would call an order of precedence clause, making it very clear that the contract governs if there's any contradiction in any Statement of Work or any other exhibit, or any purchase order perhaps, or any changed authorization or whatnot, that the first place we go to resolve the conflict between those terms is the contract. And then if we can t resolve it by using the contract, the order of precedence clause would spell out how we would go about resolving the conflict. So just give caution. Be cautious. And understand that it s frequently the case that Statements of Work will contain legal terms. And we just want to make sure that those legal terms don t have a negative impact on the negotiated legal terms and the governing legal terms that are in the underlying contract. I want to talk more about detailed best practices for well-written Statements of Work. Based on your experience, Matt, what are some of the key characteristics of a wellwritten Statement of Work? Who, what, when, where, and how much [Laughs]. Who s going to be providing the services, when are they going to be provided? Where are they going to be provided, what are they, and how much do they cost? So that s really what I want to know. And I want to know it in as much detail as it can possibly be broken down into. Really that s what it comes down to. It s all of the nitty-gritty with respect to what the supplier is going to be providing. Well thought-out, really explained in a lot of detail, task by task. When each of those services is going to be provided, who s going to be doing the work if that s applicable and then how much each item is going to cost broken down into as much detail as possible. Are there some key terms that you recommend project managers include in their Statements of Work regardless of the project they're working on? Yeah. I would definitely say that it s frequently the case we ll include a project plan with a clear project schedule. Making sure that we avoid estimated dates. We generally include a very clear explanation of what the vendor is expected to do and what Page 5 of 12

6 the vendor is expected to deliver. You know, use language that s clear, that s written so that someone unrelated to the project who is generally familiar with technology could really understand the services and the deliverables to be provided. Functional and technical specifications should be included if they're applicable. And if they are applicable, they re really essential. And again, similar to the Statements of work, we want to avoid deferring including technical specifications to a later date. It s really important that they get included up front. An implementation plan could be included if that s applicable. There's many, many, many things [Laughs] that certainly we would want to add to Statements of Work. Matt, you recommend to add an overview section at the beginning of the Statement of Work that provides a brief and in plain English explanation of what the vendor is expected to deliver. So anyone who is not involved in the project but who is generally familiar with the technology can understand. Why do you think this is very important for project managers to keep in mind? Because it really just sets out the essence of what we re doing. And I think it s really important that all the parties really baseline what services are going to be provided. Look: we ve got two parties. We ve got a vendor, and we ve got a customer. Let s put our heads together and articulate precisely what the requirements are, really on both sides. I mean certainly from the customer and the customer s requirements are very important. But there also might be some vendor requirements that are equally important. And we want it to be very clear. We want to avoid legal jargon, we want to avoid acronyms that aren t defined. We want to just make it very clear so that everything that follows that in the Statement of Work will build off of those business requirements, and we can always come back, and we can always say, Are we putting together a Statement of Work that appropriately reflects what the parties business requirements are with respect to this transaction? It sets the whole thing up very nicely. Matt, you alluded to this next item before. Often Statements of Work will refer to deadlines as estimates and calculate dates from the beginning of the project without clearly defining the date of that beginning. What do you see in your practice as consequences of this approach? The vendor and the customer don t have a clear understanding of what the actual dates are. And we run into an expectation gap where the vendor s expectations with respect to when they need to deliver something are not the same as the customer s expectations with respect to when they thought the something was going to be delivered. And we need to avoid that. That leads to pretty serious disputes. And what we really want to do is, we want the when we were talking about in an earlier question, the when. When is each item Page 6 of 12

7 going to be delivered? And we want a specific date or, if we can t come up with a specific date. For example if there s a transition plan, a transition period. And for the sake of argument the effective date is January 1st, and the transition period is 90 days, we can come up with a date certain that the transition has to be done. If there s a delay in the transition which is frequently the case in some projects three s the next critical element. For example, the date certain might be X deliverable must be delivered within 15 days after the transition, the implementation (whatever it is) is completed. And the contract would spell out what it means to have a transition completed. So that s not an estimate, that s a date that we can actually determine but we just can t determine it until we know when the transition or the implementation is done. Versus something along the lines of, The vendor (who is going to provide X deliverable) the estimated date of completion is April 15th. Well that doesn t give us anything. Because the customer might expect the deliverable to be delivered on April 15th, or no later than April 15th. But the vendor s view of that might be that it s just a goal. It s just, We expect it to be done but, look wee don t know. It could be May 15th, it could be April 16th. Whether April 16th or May 15th creates a problem, I don t know. But what I do know is that there s an expectation gap between the customer and the vendor. And those types of gaps with respect to expectations, requirements, etcetera really do create disputes. You also mentioned this one before but I would like you to cover it again: Vendors like to insert a list of contingencies on the vendor s performance and assumptions about the client s company performance. What type of clauses should project managers avoid in a Statement of Work? It s not so much that you want to avoid assumptions. I think it s probably fair to say that Statements of Work, no matter the size of the project, no matter the parties or the size of the transaction, will ultimately contain some assumptions. And certainly in any Statement of Work there will be some things that a customer has to do and some responsibility and obligations on the customer. That being said, what you want to avoid are those laundry lists of assumptions that are so broad-based that when you sit back and read them it really could completely render the vendor s obligations somewhat illusory. Because if you sit back and say, One of the assumptions is the customer must fill in the blank, then you look at all the responsibilities of the vendor and you say, Well what if the vendor comes back and says they couldn t perform X because the customer didn t fulfill the assumption that the customer was going to perform X, the customer never performed it. And you want to sit back and go through the assumptions and say, Can the vendor do that? Can the vendor go through that exercise, and do all of these assumptions that we as a customer are going to provide X, Y, and Z, do they enable the vendor to really not perform? Or to have an out in the event that they miss a critical date, or any date for that matter? Where they fail to provide a deliverable in accordance with the Statement of Work. Page 7 of 12

8 And it s frequently the case that they do. and that s not to say that you just simply need to delete that assumptions paragraph but it is to say that you really need to take a critical look at those assumptions and say, Are these fair assumptions, can we as the customer perform in order to not enable the vendor to rely on these assumptions to get out of doing their own work, etcetera, etcetera. It s a really critical step in the process. And by working together with the vendor you can come up with a solution to that problem.but it does just take a critical look and some critical thinking. Another practice that you recommend against is Statements of Work that refer to sections in an RFP for example, or other sales documents such as the initial vendor proposal. How does this type of reference to external documents impact the Statement of Work, and what should project managers watch for? The problem with RFP and with external documents one is reference to external documents is frequently advised against. Those external documents should be brought forward and should be included in the contract or in the Statement of Work if that s applicable. What we really want to avoid is any reference or any reliance on marketing materials. We want to bring all of the vendor s responsibilities and obligations forward into the contract, into the Statement of Work, in black and white. In excruciating detail and very, very precisely. and we want to avoid that broad-based reference to marketing materials, to RFPs unless we re bringing the RFP into the contract, particularly the RFP response and any other documents that really aren t contained within the four corners of the contract. You recommend using terms consistently in all the contract documents because using different ones obviously creates confusion and may dilute a vendor s obligations. Which sounds common sense, but it s not a usually common practice. Can you give us some examples you see in your daily practice that project managers should avoid? Yeah. That s a great question. And it s not probably in terms of the most important things to cover, that might not be the most important. But there s a simple solution to it. What we don t want to have is the Statement of Work conflicting with any of the other documents. And Statements of Work are frequently drafted by businesspeople who speak a different language. And that s perfectly okay, we just want to reconcile that with the meanings, with the use of the terms in the underlying contract and other contract documents, and the meanings of those terms. We frequently see a lot of acronyms used that aren t defined and that the meaning of which are very hard to decipher. And so we like to define the acronyms. Or include a glossary of terms, and include a list of all the acronyms. The meaning and then a brief explanation of how they're used and what the context is for use of the acronyms. We want to ensure that any terms that we ve defined in the underlying contract are used throughout all of the contract documents. Not just the Statement of Work absolutely the Statement of Work but also all of the other exhibits and attachments. The project Page 8 of 12

9 plan, the implementation plan, the transition plan. If there are those documents we want to make sure that all of the terms that we defined in the contracts really flow through all of those other documents. Ultimately we want a really precise document. We don t want little disputes to arise over the meaning of terms. We want to try to avoid those disputes as much as we can, to avoid confusion. Because confusion leads to disputes. Confusion leads to the breakdown of deals. And our goal is not to have deals break down. Our goal is to work with customers, work with vendors to come up with deals that will stand the test of time. So, it s a bad day when I ve represented a side of a deal a vendor or a customer and that deal ultimately doesn t work. We want to draft documents that work and that make it possible for the two parties to really have a great working relationship together. And we don t want little disputes that could ve been avoided to spring up as a result of, for example, the parties not understanding the terms that are used, so the parties are having a disagreement over the meaning of terms that are used without definition and whatnot. You recommend breaking complex Statements of Work into several small or discreet ones. When necessary, a Limited Scoping SOW may be used to better define the requirements for a later SOW. Can you explain this concept to us and give us some examples that show how project managers can implement this concept in their project? Yeah. I think that it s sometimes the case that it s easier to work with smaller Statements of Work that really focus in on discreet projects than it is to and this is really a question that s geared towards larger transaction. In some large transactions it frequently is the case that you go in with one enormous Statement of Work. And sometimes we advise that in order to efficiently get the deal done, in order to efficiently manage the deal from a governance structure moving forward, in order to do all that and make sure that the deal works and doesn t break down, we would advise that you try to parcel all of the different discreet projects out and then have Statements of Work for each. And then have a Scoping SOW which would define requirements for future statements of Work that the parties would enter into. And in this way really putting into place a structure so that it s real clear to the parties how you're going to go about crafting the Statements of Work over time, over the life of the transaction. We just thought of this as a very efficient approach. Customers and vendors both love it because it makes the deal much more manageable to them, and less of a behemoth. Less of a daunting task to get all this work done. It just makes it much more manageable and quite a bit more efficient for them. Especially when you can t define your requirements until you do some form of analysis. Right. So I can see how a Statement of Work could be the deliverable from a previous Statement of Work. Page 9 of 12

10 Right, absolutely. Yeah. Matt, any final thoughts for project managers on writing effective Statements of Work? Absolutely. I think that [Laughs] my biggest piece of advice I guess is don t be afraid of lawyers who practice in this area. They can really help you. [Laughs] And don t be afraid of your legal team if you have a legal team in your company they can really help you articulate the language and articulate the requirements, and the specifications, and all the good stuff that we ve been talking about. They can really help. So my advice is really to partner with all of the stakeholders. In other words, Legal, Finance, Operations, IT, HR, whoever it is. Bring all the stakeholders into building this thing if you're the customer so that all of your requirements are really spelled out really neatly and precisely. And so that you can really avoid those gaps which do tend to lead to problems down the line. What we ve seen is it s the Statements of Work that include those gaps that don t work and that s not to say that if you follow all this advice and draft the world s best Statement of Work, it s not to say that it will never break down. There's so many different variables and factors that go into that. But it is to say that you ll have a lot more luck with respect to the services and the vendor. And I think you ll have a much better relationship with the vendor down the line. Matt, I think you're right. I think we as project managers, [Laughs] typically we re afraid of lawyers and afraid of our legal department. [Laughs] But my experience has showed me that I d much rather have them involved with me in the drafting phase of the statement of Work. That way they feel a sense of ownership and they will be there when that first sign of trouble shows up. They will be there with me and they ll feel that they are committed and they're part owners of solving the problem. What they don t like is when I only call them, and they only know [Laughs] that we have a Statement of Work after that first sign of trouble. Yeah. That s not good. [Laughs] I absolutely agree with you that they should be involved as early in the process as possible. Matt, what are some of the legal trends in vendor management that you are keeping an eye on for 2011? Page 10 of 12

11 I don t know if there's any trends in vendor management. I think that we re keeping our eye on a lot of shifts in IT. You know, certainly cloud computing is a hot topic right now and a lot of moment into that space. And a lot of working with the vendors in that space and getting familiar with how they work, and how they approach transactions. I know certainly one of the legal trends in the last several years and will certainly be in the next several if not well into the future is the focus on privacy and data security. And how vendors are handling that, and how customers are handling that. I think those are some of the key trends that we re watching very closely for 2011 and well beyond. And how do you keep up with new trends in technology so you stay on top of their legal implications for your clients? A couple things. I talk to my clients a lot. My clients are a great source of information. I work with IT departments all over the world for clients big, small, and anywhere in between, and I talk to them a lot. As a lawyer in private practice, I m in the business of client service. And I learn so much from my clients and from CIOs, and senior IT executives, from in-house lawyers at the companies I work with, and through the transactions that they do, and just through relationship-building and talking with them. We stay connected and I just learn a great deal. I also read a lot. There s [Laughs] a lot of information out there. and I have my sources of where I got, but my advice to anyone who actually wants to stay on top of it is just get on a couple of the key lists for information. And there's plenty of information out there that will help to keep you on top of trends for the future. Can you tell us about some interesting projects you're involved in these days? We continue to have a very vibrant outsourcing practice. [Laughs] And every election cycle, outsourcing seems to get a whole lot of publicity these days, certainly with the case in 04, 06, 08, and now, But we continue to have a very vibrant IT outsourcing and business process outsourcing practice helping companies with their outsourcing needs. And we continue to do a lot of cloud computing transactions these days, and really focusing in on one of my specialties, Internet privacy and computer crimes. And certainly tons of [Laughs] work there as well, unfortunately as the case may be that there s a lot of work there. But that tends to be and continues to be a very exciting area. The law s changing quite a bit in that area. And the unfortunate reality is that I don t think that a focus in the area is going away any time soon. And what's next for you? I continue to do both things. This year, 2010, I will have given 20 presentations on IT and outsourcing in corporations. I continue to write quite a bit. I m at the early stages of writing a book on IT contracting. And just continue to keep my head down and hopefully continue to distribute very useful information to the business community. Page 11 of 12

12 And where can people find out more about you and contact you? So, the easiest way, as you said in the introduction I believe, I m an attorney at Foley and Lardner. Foley and Lardner is a law firm of roughly 1,000 lawyers in 21 offices around the world. I m in Boston, in our Boston office. Where we have a group of about 70 lawyers. And my address is m_karlyn@foley.com. Everyone is always welcome to me, write me, correspond with me, and I m happy to work with anyone who wants to work with me. Well Matt, I want to thank you so much for taking the time to talk to us about your valuable insights on writing Statements of Work that keep our projects on track. Thank you very much. Well, I really learned a lot from our conversation, Matt. And I look forward to having you come back and talk to us in the future. I am particularly interested in talking to you about your upcoming book about contracting in IT. That is going to be very, very interesting to me and to a lot of project managers. [Last Question] Page 12 of 12