One of the tasks facing firms and CIOs/CTOs, IT directors, and managers is vendor selection and management. For many, this is new and unfamiliar territory. Assuming you must use external services, how do you pick a qualified vendor for your project? How do you draft a solid statement of work (SOW)? How do you properly manage a vendor and hold them accountable? In this article, I provide a few tips I've used that you may find useful for your environment. In summary, the five tips I offer are:
DISCLAIMER: This and all Legal Notes columns should not be construed as specific legal advice. Although I'm a lawyer, I'm not your lawyer. The column presented here is for informational purposes only. Whenever you're seeking legal advice, your best course of action is to always seek advice from an experienced attorney licensed in your jurisdiction.
Tip 1: Have a Clearly Articulated Project Scope
Although you may have a definite opinion of what you want your project to accomplish, does anybody else? Are your project's goals and objectives documented? In short, do you have a plan? If you embrace agile principles, having a plan may seem antithetical. In reviewing the Agile Manifesto, specifically item #4 that reads “Responding to change over following a plan,” I find that agile doesn't forestall having a plan. Rather, change and responding to change has to be part of your plan.
The components of a good plan consist of two broad categories:
- A budget
- The why, what, when, how, and who of your project
Have a Budget
For any software project to be cost-justifiable, there needs to be a positive value proposition between what the project costs and what it earns. It's absolutely critical that these two numbers exist. The trick, of course, is that only one number is 100% under your control: the costs. You can absolutely control what you spend on a project. That's not to say that there isn't some allowance for variance.
What remains an estimate is what a project will be directly or indirectly responsible for earning. It's critical that the earnings budget be objective and reasonable. The same goes for the cost budget. Once you have these two numbers, only then can you derive a return on investment (ROI).
These numbers are not static and shouldn't be visited only once, at the beginning of your project. Every decision you make with respect to whether a feature should be added will have an impact on these numbers. The primary question is whether the contemplated feature is a positive value proposition.
Not to diminish the qualitative value that may be derived, business is about the bottom line. Without a positive bottom line, all of the good things you hope to accomplish won't be feasible. Project budgets and the review thereof should be a continual discipline for your project. To derive your budget, you will want to tackle the questions of why, what, when, how and who, your project will be delivered.
Your Project's Why, What, When, How, and Who
Until you answer these questions, you can never hope to answer the question of whether you have a chance at accomplishing your project's goals. If you can't adequately address and answer any of these questions, you should immediately stop your efforts. There's no reason to continue if you don't know why you're undertaking your project, what features have to be delivered, when you need the features, how and by whom will delivery be made; without these answers, there's no rational business reason to undertake the project. Once you answer these questions, only then can you address how much your project is going to cost to deliver and thus determine whether a positive ROI is feasible. Again, if the answer is negative, there's no reason to continue with the project as specified.
The first question of why is the most basic question you need to confront for any endeavor that your organization undertakes. The next three questions, what, when, and how are the predicates you need to address before you can address whether you will use in-house resources or hire an external vendor. Too often, organizations rush to vendor selection before these and other questions are confronted.
It's important to note that this isn't a re-hash of the five Ws and one H questions that journalists use for gathering information. There are two important distinctions. First, I don't regard the question of Where to be all that important in this situation. In a stretch, I suppose I could have asked where in the business will the application be deployed. As I see it, that question is essentially answered when you ask what it is you are trying to build. Second, the five Ws and one H looks back at history. What happened, why did it happen, how did it happen, etc. Here, I take a forward-looking approach, which is what you need before you embark on a software project - or any kind of project for that matter.
Why?
Presumably, you're entertaining a project to address some business need. It seems like a basic, common-sense question to ask. And yet, all too often, many businesses embark on a project without asking why they're embarking on such a project in the first place. Implied in this question are important elements like business requirements, which, in the Agile world, form the basis of user stories (product backlog items in scrum).
What?
After you've answered why, you can begin to chart out what the delivered solution will look like. This isn't about the technology stack. It's much too early to think about that question. Rather, this is about your feature set that's codified by your user stories to support your business requirements. A good feature is something that does one thing very well. That's also a hallmark of a good user story; it's something that describes one thing well, including acceptance criteria and a definition of completion. With your solution is decomposed to smaller feature subsets, you can then prioritize their importance and relative effort to deliver each feature.
A good feature is something that does one thing very well.
When?
When will you need these features in order to deliver value? Ideally, you don't need every feature 100% complete on Day One in order to deliver the required value. If you're set up for that, time is your enemy, but not for the reasons you think. You might think the issue is that the problem is too complicated to get done in your required time frame. That's not the issue. The real issue is that you got started too late.
It's almost never the case that you need everything right away. Instead, and what's more likely, you need some features sooner than other features so that delivery can be incremental. Your task is to prioritize those feature deliveries accordingly.
How?
In answering how the features will be delivered, you begin to confront the technical stack, cloud versus on-premise, in-house custom solution or a third-party solution. If you need something quickly and perhaps you don't want to invest in support, you may opt for a third-party solution. For some problem domains, like Customer Relationship Management (CRM) or Enterprise Resource Planning (ERP) solutions, there's almost no reason why you would ever opt for a custom in-house solution. Sometimes, how you wish to incur costs drives part of this decision. For example, if you want a pay-as-you-go model (OpEx), you may choose a cloud-based approach. On the other hand, you may prefer a capitalized cost approach (CapEx) or have some other constraint that makes the cloud not feasible.
Who? (And the Ultimate Cost)
At this point, you know what you need, when you need it, why you need it, and how the solution will be built and delivered. The question is: Who's going to deliver your project. Are you going to use in-house talent or will you contract with an external vendor? Do you have the necessary talent in-house? The required talent level may be fluid, depending on when you need your solution. The shorter the time frame, the better your talent level needs to be.
If your internal staff doesn't have the right skill set or the bandwidth, you may need to use a third-party vendor to deliver your project. If you find yourself needing to hire a vendor, it's absolutely critical that you have requirements clearly defined. In the event that you have poorly defined requirements, you run the risk of choosing an unqualified vendor. You also run the risk of significant cost overruns.
Cost overruns and unqualified vendors are not the problem. Rather, they are symptoms of a bigger underlying issue with your project. In such a case, it's helpful to consult the three primary constraints of scope, time, and cost. Together, these three constraints define quality and the value derived therefrom, as illustrated in Figure 1.
Cost overruns and unqualified vendors are not the problem.
Every project is subject to constraints:
- Cost: Every project has a finite budget.
- Scope: Only projects with clearly defined requirements can be well managed.
- Time: Delivery is the most important feature - dates matter.
Cost, scope, and time can also be expressed as the choices of good, cheap, and fast. It goes like this:
- If you want it cheap and good, delivery will not be fast.
- If you want it good and fast, delivery will not be cheap.
- If you want it fast and cheap, delivery will not be good.
Accordingly, if you are faced with a situation that requires your project or a feature to be good, cheap, and fast, you first need to look at the scope and decide if it is possible. If not, you need to endeavor to reduce the scope until it is possible. If that can't happen, then either the time (fast) or cost (cheap) constraint must give way. In no case can the quality (good) constraint be compromised because if something isn't good, it isn't useable and therefore, can't deliver value. Something that can't deliver value isn't worthy of being built in the first place.
Without a plan that's composed of a budget and your project's vital statistics, you're flying blind, and so is your vendor.
Tip 2: Decide If Your Project Will Be Staff Augmentation or Project-Based
One of the biggest unforced errors in information technology today is thinking and acting on the misperception that staff augmentation and project-based work are the same. Although the intended endpoint may be the same, how that end is reached is quite different. In either case, your goal is a new or enhanced software application that delivers value to your organization.
A big error is thinking that staff augmentation and project-based work are the same.
With a firm plan in place, you've decided that you will need to enlist the assistance of a vendor. The next question is whether you'll use your own resources to manage the project or have your prospective vendor provide those services. If you're going to use internal resources to manage your project, your vendor selection process is easier because you can evaluate vendor personnel on basic technical skills. In this case, you can interview technical talent just as you would any other employee. If, on the other hand, you're going to rely on a vendor to manage your project, you should view your project as being composed of two primary parts:
- Operations and Management
- Development
If you defer to a vendor to manage your project, among other things, it means that you're assigning the task of skills evaluation and team composition to the vendor. Don't fall into the trap of requiring a one-stop-shop vendor. Although your candidate vendors may have good technical talent, being able to manage a project is a different skill altogether. You may want to consider bifurcating your requirements between operations and management and development. It may be that you'll use multiple vendors for management and development respectively. Above all, have clarity on who'll manage and take stock of the fact that management and development are very different things.
Tip 3: Create a Request for Quote (RFQ)
An RFQ is the standard yardstick by which you can compare your candidate vendors. Without a standard yardstick, you run the risk of employing different criteria for different vendors. The consequence of that is picking an unqualified vendor. Just like not having a plan, if you don't have an RFQ, you're flying blind.
The RFQ creation process should be a by-product of the work to create the project scope. An RFQ also allows you to get a head start on your master services agreement (MSA) and statement of work (SOW). If you're not sure how to create one, there are many examples online. Just inject the details germane to your project.
The following items are contained in a robust RFQ:
- Patterns and practices
- Testing methodology
- Competency and past experiences with the relevant problem domain and industry
- References
- Risks the candidate vendor sees that you don't see
- Payment terms
- Project management experience (in the case of project-based scenarios)
Don't Let Hourly Rates and Quoted Costs Be Your Primary Selection Driver
The old saying goes: You get what you pay for. Of course, there's never a bottomless well of money. Nevertheless, if you only look at cost, why bother looking at competency? Take a few moments to review the quality triangle in Figure 1. You may find a vendor with a higher hourly rate that might be offset by better competency. That allows you to possibly get your project delivered faster. For the right vendor, in order to fit within your budget constraints, you may be able to pare back your initial scope. Finally, there's always room to negotiate, within reason. If you low-ball your vendor significantly and they accept it, that should be pause for caution. The vendor you want, assuming they meet all your main criteria, is the one that is just as willing to walk away from the table. For any project to succeed, every party must derive value from the relationship. As soon as one party feels disadvantaged or aggrieved, that's when bad things begin to happen. Giving your candidate vendors room to respond with their position and terms in an RFQ is a great way avoid those traps.
Tip 4: Create a Clear and Workable SOW
Your statement of work (SOW), along with the master services agreement (MSA) is the primary legal document that governs the relationship between you and your vendor. Typically, one MSA is executed and a separate SOW is executed for each project. The SOW should flow directly from the RFQ. If there's something completely new that arises, it shouldn't be a surprise to either party. In other words, this is not the time to slipstream in new scope by the client or the vendor in order to meet some new demand.
A good SOW contains among other things, the following:
- Clear acceptance criteria: This also includes having a definition of completion. There's no better place to have this documented.
- Clear and realistic dates or have a provision that such dates will be determined by a specific date
- Code escrow provisions
- Clear language that the vendor manages their own people (regarding HR related items, time off, etc.)
- Clear representations and warranties over:
- How the project will be staffed (accuracy of CVs, availability, such as on-site versus remote)
- Expertise required to deliver the project
- Clear language on what constitutes a change and the requirements thereof (scope creep without requisite budget and time modifications is death).
If you see the vendor unwittingly making a mistake, help them.
- Create a partnership.
- Don't unreasonably withhold payment.
- Don't hold out the promise of future work if….
- Business must be mutually beneficial to all parties.
- Knowing that a vendor is not aware they are making a mistake doesn't help anybody.
Tip 5: Be Mindful of the Pitfalls with Multi-Vendor Scenarios
You may need to use multiple vendors. For example, you may use one firm to manage the project, another firm for your user experience work, and a third firm to write your application. These vendors must work and cooperate for the benefit of your application and organization. Accordingly, you'll want to avoid warring factions. Although you may have separate SOWs, you'll want terms that are common to all vendors:
- Outlines the need for cooperation with other vendors
- Underscores that all have a joint and several duty to you, the client
- Vests responsibility for vendor coordination with one person.
Without a plan that's composed of a budget and your project's vital statistics, you're flying blind, and so is your vendor.
Conclusion
As you can see, there's a good deal of preparation that's required before you begin to confront the question of whether you should use a vendor. These are the why, what, when and how questions. Once you've decided that you need to hire an external vendor, you need to decide whether you'll manage the project in house or rely on a vendor. If you manage the project in house, your scenario is staff augmentation. If you rely on a vendor to manage the project, your scenario is project-based.
It's important to define a bright line between these two alternatives because the two are quite different. A common mistake is to treat something structured as staff augmentation as project-based. In these cases, there's no project management. Once you've decided that you need one or more vendors, creating an RFQ aids you in selecting the right vendor. Once you select your vendor, your SOW should flow from the RFQ response by that vendor. Finally, if you have a multi-vendor scenario, make sure that somebody is accountable for vendor coordination and collaboration.
