The key ingredient: discipline

While performance-based contracting is hardly a new tool for agencies, the Veterans Affairs Department is one of the few having success.Acting CIO Ed Meagher's IT shop, for instance, modified a contract with Sprint Corp. to make it performance-based. VA asked the telecommunications firm to meet a series of requirements and did not tell them how they should meet the performance goals.'We told Sprint to be accountable for the end-to-end performance of our network,' Meagher said. 'We negotiated performance metrics with them that were within our enterprise architecture parameters and they could do what they want.'Nearly two years later, Meagher said VA's costs have decreased significantly and performance has been solid.Meagher talked recently about what it takes to make this methodology more prevalent in government. GCN staff writer Jason Miller interviewed Meagher in his Washington office.The reason it has taken so long to take off [is that] performance-based contracting requires a great discipline on the part of the government to understand the requirements, to describe its requirements and, probably most importantly, to derive meaningful metrics to measure that performance.It is very difficult to do well and that is why we tend to shy away from it a little bit. It is easier to ballpark things and then correct as you go along. That is an easier methodology. Performance contracting is a superior methodology.I would probably lean toward the culture issues. We all tend to find the path of least resistance, and that is the more generic time-and-materials contracts where you require vendors to give best effort and you eventually get where you wanted to. It is probably easier on everyone to take that path. It's human nature for departments to do more time-and-materials or other types of contracts because you don't have to be as precise or as strict in the management disciplines as you do with performance-based contracting.It is a set of disciplines. They start with requirements definitions, and that takes a skill set, it takes a significant involvement of the business community in the department and the end user and the end-user manager.The business element of the agency must be very involved and, sometimes, educated. It's a very difficult process to get a good set of requirements. There are not a ton of folks who are really good at that and you have to apply that very early in the process. That is the first discipline.Then you have to convert those requirements into outputs and you have to determine performance metrics for those outputs.Then there is a program management piece, which again is a very tough discipline, so you can manage these contracts to successful completion.These all are hard, long-term disciplines that need to be instituted from the top down. Or what happens, folks take the path of least resistance. If you don't have a specific destination, any road will get you there.The disciplines I'm talking about are the end-to-end programmatic disciplines that have to be extended throughout the department to put that in place and sustain it over a period of time.Where does money come from to support those disciplines? It is not a project. Where does the money come from to have those experts and take business people out of doing business into work to form those requirements and outcomes metrics? You have to pay that price. There is a significant up-front cost for success with performance-based contracting. Typically it is easier to let that piece go by and work from a statement of objectives.This gets to what we are doing with enterprise architecture and using it as a governance model. If IT folks are designing and creating outcomes and performance measures in a vacuum, I think they're almost doomed to failure. When you talk about requirements, you need to sit down with end users, end-user management and several other layers of management and ask what they require from this system or process. Give them the chance to review the process. You don't want to pave the cow path.As you get more complex in terms of IT descriptions, those requirements get formulated and decide on outcomes, which are the specification based on performance. You convey these performance specifications to the bidders. That whole discipline that needs to take place needs to be structured and made replicable to a high degree of confidence.We tend to get too many feel-good contracts, where the end user will be happy with the output. If you just have a statement of objectives, the outputs are much easier to get to and if they are wrong they can be fixed. But that is not performance-based contracting. That gets into time and materials or some other type of contract.It is the recognition that this is what it takes to do performance-based contracting. It is expensive, it's tedious and like any good discipline it is hard to explain it at first and you have to be repetitive. You have to make sure people across the board accept the discipline, get better at it and train for it. Some of this stuff we have done as a matter of course over many years.One of the things we did is [required] all project managers to be Project Management Institute Certified to Level 3, the highest level. We will institute a very intensive certification program to get everyone there. When dozens of requests for exceptions came in, we said no. We just said we will require professional certification for everyone who touches a contract. We will pay that price. It is one of those disciplines.Those are the system analysis folks, and that is something we are putting in place down the road. We will not let someone go out and work at that level until they have done a certain amount of system analysis training. We are going to professionalize everything we do here. That is not to say we weren't doing it professionally before. But we are adding discipline, consistency and certification and accreditation to it.Performance-based contracting is very difficult in areas where you don't know or where you are in a process of discovery. If the risk is too high for the private sector to step in, then you're acknowledging you are learning as you go along. Any place where this hasn't been done before, this is not appropriate. But where we have built accounting systems or pharmacy systems, we should know how to do this with performance-based contracting.If the risk is understood, it can be mitigated. If risk is mitigated, you can do performance-based contracting.Then there needs to be this whole notion of people living up to contracts and a willingness not to pay a contractor for substandard work. There is always a temptation to throw a few more million dollars at the problem if they miss their expected results.If you do up-front work, the temptation is less because then all the risks and agreements were properly understood. If the vendor misses it, it is a failure of their process. And we need to be willing to say we will not pay them. We have to be willing to do our job well enough up front so we will be confident when performance isn't met we can take a principled stand and there will be penalties for being late and not meeting specifications.It is a matter of sophistication. We have been doing firm-fixed-price contracts for a long time. The difference between a firm-fixed-price contract and a performance-based contract is the degree of specificity that is involved in terms of outcomes and metrics. It is not a great leap, but it is a matter of greater sophistication.It really is culture that says we are going to pay some costs up front for the training and require folks to be certified and accredited. It is that understanding that folks need a whole group of skill sets and processes that need to be instituted in a department. It doesn't just happen on the back end. So much of this is front-end loaded and folks have to be willing to spend this money and divert this resource because it will result in better contracting further down the road.You get perspective contracts when people don't trust that you can get what you want by simply requiring certain performance goals and metrics. People will say that, but get overly prescriptive. You want a solution provider within the context of enterprise architecture, standards and open systems to bring the best technologies to bear. Within those general guidelines, you want the vendor to bring you the best that is out there. You want clear guidance and allow the dynamics of the private sector to do what they are good at, which is innovate and mitigate risk.