How to Work with Software Development Companies - Part 1

If you've been doing outsourcing for awhile, this article may not be for you. But if you're new to it or feel like you may be missing something, maybe there's some useful ideas in here for you. When working with any contract service, whether it's a physical re-model of your corporate lobby or a multi-million dollar system that will change the world, many of the same considerations apply.

In this first part of How to Work with Software Development Companies, we'll look at the beginning of the engagement process though the proposal and negotiation phase. In Part 2, we'll get more into estimates, SOWs and MSAs, and dealing with change orders followed by project delivery.

The Engagement Process

When you first contact a prospective partner firm, there will be a typical flow. These will include the usual introductions, high level explanations of project needs and likely some very preliminary discussion of available budget. While detailed budget discussions are premature too early in the process, it does make sense to level set if this is a $50K project, a $250K project or something potentially running into the seven figures. If a large corporation is involved on the client side, and there is a formal Procurement Department, the process involved may also be discussed as this is a potential gating factor for all involved.

As discussion moves past the getting to know you stage, it's likely that you could be dealing with a variety of personnel from the contractor firm. This may include the CEO of small to medium or even somewhat large firms. There may or may not be a dedicated business development lead. Besides Business Development, you may encounter titles such as "Pre-Sales Engineer," "Delivery Manager," or "Product Manager." The people in these roles will work with you to get an idea of general scope of the project; and this will be true regardless of if you have detailed specifications already or if you have the proverbial paper napkin sketches for a startup. The goal of this round of discussions is to determine what level of Discovery Process is needed and if there's even a general sense of a good fit or not among potential partners.

In the cases where you have offered a formal Request for Proposal, it's more likely than not you've put a lot of effort into trying to offer enough clarity upfront to allow a potential partner to bid on your project. Nonetheless, it's still possible that a fair amount of back and forth Q&A could be required to iron out any possible ambiguities or perceived incompleteness in the RFP. Responses may include rather large range estimates, which will still be based on only the highest level considerations of the components in your RFP. Chances are if you're dong formal RFPs, you're no stranger to outsourcing and dealing with vendor selection. If not, you should understand that an RFP response takes some effort, and it's likely some smaller firms won't necessarily have resources to do so if it's a complicated effort. They know that they'll be competing with multiple firms if you're shopping around such a document, so be aware that for smaller projects, you may be sending a signal causing what could be an ideal smaller partner to self-select out of the process. For larger projects, this might of course make perfect sense as you don't want to waste time with prospective partners who couldn't handle the work anyway.

Initial Legal Docs - Non Disclosures

Even at early stages of initial discussions both client and contractor will likely wish to formally execute non-disclosure documents.

Non-disclosure documents are most often simple boilerplate documents. They will usually take the form of NDA or MNDA, meaning "Non-Disclosure Agreement" or "Mutual Non-Disclosure Agreement." The purpose of non-disclosures is to protect intellectual property rights, and at this stage, more likely Trade Secrets, as ideas may be early stage and not yet have had protectable IP filings made to various patent offices, domestic or international. Other aspects considered proprietary may include, (but not be limited to), customer names or even types of customers, (whatever types may mean in your category), business plans and cases, or any other information considered proprietary and confidential. The reason for Mutual NDAs is that disclosure may go both ways. Just a a client doesn't want their proprietary information exposed, a contractor may also have tools and methods - or other information - considered proprietary.

NDAs will describe the nature of that which is considered confidential. And also, if necessary, what level of disclosure may be allowed for additional third parties. For example, a client or prospective vendor may need to work with additional vendors or sub-contractors, and some limited amount of information disclosure is likely required to accomplish efforts involving those third parties. Those third parties should be bound by non-disclosure with the contractor anyway, but in areas with particularly great concern, additional NDAs may be needed directly between the client and any third parties. It's possible that a prospective contractor may even need some limited disclosure capability before even bidding on a project and their discovery process may entail understanding more about integration of potential third party technologies or data sources.

There are potentially other initial legal documents that should be disclosed or traded, even at this early stage. Finance, Government or Healthcare work may involve various types of clearances or certifications and if this is known to be the case at the outset, it makes sense to have that discussion early so as not waste each other's time. For example, a healthcare project may require, (most often does require), HIPAA compliance on the part of a vendor. The vendor will likely need to sign a Business Associates Agreement (BAA) specific to healthcare privacy compliance. If the vendor cannot attest to such compliance and execute such a document, there may be little point in continuing. An exception may be if for whatever reason this is the perfect vendor, at which point there may be a need to allow for time to get into compliance. This is just one example. The point is, if there are clearly known early compliance requirements, they should be discussed early in order to get past them or move on to other opportunities.

Discovery - Basic and Beyond

Any project work will require some degree of discovery. The possible exception to this is when the relationship will be that of simple Staff Augmentation, where you are engaging with an external firm primarily to supply talent - essentially as a staffing agency - to backfill your own team. Discovery can run from simple to complex, and the method and cost for this - if any - will vary accordingly.

Simple Discovery

Often at no cost to the client, simple Discovery will be a couple of meetings worth of back and forth questions and answers. This works perfectly well for small to mid-sized projects where requirements can be fairly clear; either because they are already professionally specified or the apparent tasks at hand are well understood. If there is enough clarity with such projects, the vendor firm should be able to offer preliminary ideas on effort level in terms of both project duration and cost. If this is the nature of your project, after Simple Discovery, you may be moving quickly on to project proposal stages in the form of a Statement of Work (SOW) and other associated legal documents.

Deep Dive Discovery

Deep Dive Discovery is required in cases where a project has complexities making it all but impossible to come up with valid effort estimates in terms of duration or costs without much more information and knowledge transfer. This level of Discovery often will require some degree of financial commitment. In this phase, the contractor will work with the client to reduce ambiguity as to what is to be created. What happens here will depend on how fully defined the existing requirements from the client may be. There will typically be at least a Business Requirements document of some sort. After all, why hire anyone if you're unsure as to what you want done at all? Then again, there's even an exception to this. If the client is a startup company, the nature of the partnership may include basic, core product management and product definition support. In any case, the output from Discovery is likely some subset - or all - of the following artifacts; whether they come from the client or the contractor. The following is a general template. Most engagements will flow along a similar path, though of course may have minor deviations depending on firm methodology and project type. You may notice that this level of product definition may seem to fly in the face of the ideas expressed in Agile methods for software development. This may or may not be true. It's possible to have broad roadmaps vs. detailed specifications; that nonetheless require at least some understanding of the level of backlog items that may be generated. As well, there are hybrid models for product and project management involving some degree of requirements prior to using Agile methods over time. (Agile purists may argue this, but this writeup is about practical working relationships with software vendors; not philosophical arguments regarding production methodologies. There are plenty of places to find such discussions.) Finally, there are projects that are perfectly amenable to traditional Waterfall methods.

Regardless of methodology, at some point the goal is for value, (likely in the form of simple payment), to change hands. Everyone, (client and vendor), will need to have some expectation of what is to be created. To that end, deep discovery may typically include the following:

High Level Requirements

• General Feature List - at least at the "Epic" level if Agile is contemplated.

Designs

• High Level - Sitemaps
• Low Level - Wireframes
• High Fidelity Design - Comps
• Prototype - Regardless of screen fidelity level... clickable prototype (Fidelity level as negotiated.)

High Level Technical Architecture

Project/Development Plan

• Project Plan execution style; general Sprint Planning.
• Personnel Plan

Anticipated Software Components

• Platform/Stack proposed choices

Anticipated DevOps needs

General Support Plan

High Level Budget as related to Project Plan

Proposal Process & Negotiation

General

Once Discovery is done, the mutual goal is to get to some kind of Statement of Work (SOW). (Which will be described later.) On the way there, we've got the work at hand - which is our target outcome - and the effort level to get it done. Sorting that out can range from the fairly simple to the astoundingly complicated. There's a variety of factors that come into play and there's a few different ways to look at how to drive through this process.

General Pricing Models

Very generally speaking, there are typically two types of pricing models.

• Fixed Price.
• Time & Materials.

Cost Plus, Retainer and Hybrid models are variations on these themes.

Fixed Price Contracts

On the face of it, this seems a fairly simple model. You're going to pay for certain features to be built over some specified amount of time for a set cost. Easy, right? After all, you have a budget and you know what you need and when you want to have it. There's just one problem. OK, maybe there's a dozen problems. Your ideas about what it is you need may change over time, your estimates, (and perhaps the vendor estimates), of what it will take in terms of time and resources may be far off, what you've defined may be poorly defined, etc. etc. And this, by the way, is for known quantity type projects. Alternatively, you may have a project involving some sort of Machine Learning or other research where there's actual science involved. That is, if there are serious unknowns along a a project creation effort, fixed price can be challenging and simply not be a sensible option given the unknowns inherent in the project execution. Of course, some of these issues are exactly what have led to ideas like Agile development. Nevertheless, for projects that are believed to be well understood, the fixed price model is alive and well, with all its associated challenges. In a fixed price project, you are - practically by definition - going to be in a more traditional Waterfall project methodology for getting things done, even if Agile-like methods are used during execution. Such approaches are sometimes referred to as Scrummerfall or Waterscrum or similar; usually in a derisive way by Agile purists. (While again, this article is not really about methodology, it will need to be discussed at least at a high level further in this article.)

Fixed Price Model Benefits

• You know what you're getting and the price/timeline involved. (At least generally. Even in these cases there will often be estimates and ranges.)
• Easy to budget. Here's what I've got to get this done, and here's what it will cost. (Or at least, this is the intended range. Budget accordingly.)
• You may be able to breakdown multiple SOWs to spread product execution risk over time.

Fixed Price Model Challenges

In projects like this, the contractor - by necessity - needs to manage scope very closely. There will unquestionably be provisions for Change Management in the contract. And the core challenge will typically be the classic discussions, (alright, let's call them what they can often devolve into... arguments), as to what constitutes "in scope" vs not. In most projects, there will be some kind of scope change along the way. Perhaps not. But there's usually something. Just what that something is, how many something(s) there are, and how disruptive these changes may be are the questions. Some degree of flexibility may be in the initial contract. Still, things will come up that most likely will result in a change order. So whatever your budget may be, you have to allow for some contingency here. How much? Well, here's a fun Contingency Estimation Model for Software Projects model. And for large projects, your finance people may want to run that math. Note that this sort of thing can certainly occur regardless of what development methodology you're using. Even software professionals who are used to visualizing concepts at very early stages will find that the learning is in the doing. And as architectures come together, as database schemas are formed, as sitemaps turn into wires turn into prototypes, ideas emerge and change orders happen. This is natural and should be taken into account.

On a more practical basis, let's just say you should try to come up with some reasonable contingency as a percentage of total anticipated cost. Note that there are two general ways project scope can be impacted and these include known, identifiable risks and then things that are wholly unknown. For example, your project may involve toolsets for your own clients, and were you to add a few more clients, there may be additional integration costs. That's a reasonably foreseeable event that could cause an incremental increased cost if you wanted to bake it into an existing project. On the other hand, during project execution you could find an existing or new competitor impacts your market with features you must respond to with your product. This latter unanticipated event, (sometimes referred to as an "known unknown"), might more radically impact your budget if you believe you must include such features in your project. So you may wish to have what is called a "Contingency Reserve" for potential known risks and an additional "Management Reserve" for wholly unanticipated events. Here is a model for Contingency Reserve vs Management Reserve with another perspective on how to plan for such potential costs from a Project Management perspective.

Remember, software development has little to no Cost of Goods Sold (COGS) or Bill of Materials (BOM). That is, it's really going to be all about personnel time. So fixed price or otherwise, the cost derived by the contractor will always end up backing into hours. The estimates for those hours may be based on expert opinion from experience, estimates based on having done similar work, or other parametric methods. And obviously, besides the contractor's target gross and net profit margins, there has to be some sensible buffer for "known unknowns." That is, those items which experience tells them will be the occasional project blockers which take time for the kind of project at hand. (Note that of course for IoT projects, there very well may be materials costs and traditional manufacturing operational costs. For now this text is focused on more 'pure play' digital only projects.)

The summary here is that fixed price projects seem to make sense for the client a lot of the time. However, they do represent an increased risk profile for a contractor. So expect that scope will be managed tightly for such projects. It will be especially important in these types of contracts to have solid clarity in the Scope of Work. And clarity as to how Change Management will be handled from a project management and cost estimation for changes perspective. You should expect that projects of this type likely require more in depth Discovery, (possibly a billable effort in itself), to come up with a rational Scope of Work and milestone based project plan. Perhaps the greatest tension that occurs in client/vendor relationships is related to the ideas of "what's included" in various features. (Or more accurately, what is perceived as what specific items should be included as part of what may have been a high level description of a feature.)

One other risk to consider for fixed price contracts is overly low bids. If a contractor bids too low, it may be that they truly want a client for strategic reasons, but it could also be that they simply plan to make up for it through overly tight scope management and billable change orders. Another possibility is that particular contractor has not fully understood the work at hand. Or worse, they could find they've put themselves into a drastically unprofitable project and seek to break a contract, (or possibly go out of business), mid-way through a project. This type of extreme risk is unlikely with generally competent providers and due diligence on the part of the client, but it's something to pay special attention to if you're attempting to bargain shop.

Time & Materials Contracts

Time & Materials is about as simple as you can get in terms of a contract. Here's your rate for these roles. If there's other agreed to expenses, from Travel to Software, add those in too. Simple. You're done. The only question that remains is how long will things take? And this is where the challenges lie with this model. Typically, there will be an estimated range for duration. Remember that as usual, rates are somewhat challenging to value. As a benchmark, there may be little else to go by, but as has been said many times, you're not just paying for the hours on your behalf; you're paying for your practitioners' university, their 10 years experience, etc. There's a reason a junior front end programmer's rates are different than a senior enterprise architect, etc. With T&M contracts, it will be important to value the roles for which you're hiring similarly to how it would be if this was an internal hire. You may want to see the full resume of team members to be assigned. Or if the contractor is hiring on your behalf, you will likely want to be involved in the actual interview process. Remember as well, that even if personnel are technically working for another firm, they'll still have paid time off for vacations, holidays, sick leave, the usual. Be sure to understand if your contract rates are inclusive of such time or not. One way or another, you are of course paying for all of it. The only question is if the contractor bakes that into overhead and overall rates or such things are explicitly carved out. That is, you may be paying based on hourly line items or a more simple monthly rate. Either way, understand what's included and if backup is to be provided - or not - when personnel have time off.

T&M Model Benefits

• Simplicity.
• Change Management is irrelevant. You're got a plan of course, but if things change, you don't have the complexities or contention of change management with your contractor. This - by the way - doesn't always mean increased costs because some task may take more time. It can also mean you're choosing to descope requirements; either because you determine they're not needed or to get some other feature(s) to market faster.
• Cadence or Story Point Assessment: You could put value upon Story Points when using something like Scrum. You'll learn over time just how much value you can build per unit time. Estimates for value creation will become better as your team spools up. (And likely will accelerate as the economic benefits of efficiencies through learnings show up; though when this starts to occur will vary widely.) Using Story Points as a proxy for hours or dollars can be challenging. This should only really be considered if you are at a fairly sophisticated maturity level with Scrum methods. And even then, it is essentially not possible until there's a good lot of Sprint experience with team members. There are several huge warnings here though. The best, most experienced and competent developers will get time and point estimates wrong for all but the simplest and most easily understood tasks. It's just the nature of this kind of work. And more importantly, different team members will estimate differently. (You should find better accuracy over time, but expectations for extreme precision is really not sensible.) If Story Points/Value is used to 'beat up on' team members, you are headed for trouble. (Whether they're your own employees or a contractor, this is a pretty fast way to de-motivate people and have them quit on you.) So yes, using story points in Agile can be and very often is an amazing way to gauge and try to forecast velocity. That's what they're for after all. But used improperly, can also wreck teams. Take care.
• With T&M, you might be able to avoid in depth Discovery and move more quickly to releasable product.
• For basic Staff Augmentation only projects, this is likely the only sensible model.

T&M Model Challenges

It's been said that work, like a gas, expands to fill the space allotted to it. This may be referred to as Parkinson's Lawand serves to remind us that with flexibility comes the risk of lack of focus. For T&M software development projects, there is both a trust level and collaboration level that arguably must be tighter between the client and contractor in order to achieve project success. It will usually be the case - at least in the software development realm - that time and materials will involve use of Agile software development methods. In this case, flexibility will not mean random wanderings down low value paths, but rather still drives hard towards goals at hand. However, it's critical in this kind of model to maintain frequent communication and clarity on tasks. While it's still wrong - in the case of fixed projects - to just "throw requirements over the wall" and expect an outcome one day, you also - as a Client - do not necessarily need to have your hand on the tiller every day. With T&M based software development, however, using Agile methods implies clients need to be much closer to the action in terms of production.

Note that with T&M contracts, you will still be defining a team, albeit with looser goals than with fixed milestone projects. And while the time component should be understood given some kind of rate card will be negotiated for the skills required, that which falls under the category of materials will need clear definition. For example, what travel/hotel costs - if any - are anticipated? Are Cloud Services for processors/database servers required? Will you be handling this via your own accounts as a client or do you expect vendor to estimate and bill for these as they occur? If so, is there some clarity as to budget for this? A project with a known anticipated user load may be relatively easy to estimate. But a machine learning project can quickly generate an expensive bill in processor cycles burned.

Cost Plus

Cost Plus, also sometimes referred to as Open Book, is similar to Time & Materials. However, it's based on a vendor's actual cost plus a clear percentage to allow for profit margin. That margin, from the vendor's perspective, is not only 'profit' per se, but must cover both gross and net profit needs; that is, overhead plus actual profit. This seems to be a relatively rare model in software development, if only because it's a very challenging model to implement. Often, vendors will use blended rates for certain role levels because it's generally not worthwhile going to this level of detail on a project basis. There will be increased overhead on the part of both client and contractor to track projects to this level of detail. As well, it would represent a snapshot in time in terms of sorting out a company's net margin due to changing overhead over time. Also, employee salaries will change over time and at this point, a client becomes intrinsic to negotiating employee salary and raises, which may be somewhat odd. This model can work for long term project engagements, however requires a high level of trust between partners. Cost Plus may be more appropriate for projects with physical goods as any cost savings that can be had along the way - for example with a construction project - get passed along. But when the resources consist primarily of people and their time, there's not likely to be this kind of potential benefit.

Retainer

Retainer contracts are interesting in that they likely have wildly different scope over time. These can be challenging to implement given that a vendor must commit to some level of availability, and yet personnel may or may not be needed during a given time period. Usually, a retainer takes the form of some kind of payment over a set period to guarantee the availability of some defined service. The contracts may be a simple cost per period or have a reservation/availability guarantee cost with additional fees based on usage. These may be used for some level of software or general DevOps support.

Hybrid Contracts

As the name implies, Hybrid Contracts may include multiple pricing methodologies. Just by way of example, a model like this could involve a tightly scoped fixed cost discovery phase, followed by a longer term SOW based on T&M. The idea here is to reduce risk for all parties by making sure - inasmuch as possible - that scope and effort are as well understood as possible. Or it could be a client and vendor have multiple projects occurring at once, however with differing success models. For example, one team may be working on a well understood fixed milestone development schedule, while another does exploratory research on a T&M basis.

Check out Part 2 on estimates, SOWs and MSAs, and dealing with change orders followed by project delivery.