In Part 1 of How to Work with Software Development Companies, we covered 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.

Project Estimate Efforts – Time & Money

One way or another, when your only real costs are personnel, the adage time is money certainly applies. As does the Theory of Constraints. There’s a number of variations on this theme, but basically it’s along these lines: For any project, you have time, money and features. (Some add quality.) You can pick any two. In other words, you can spend more to buy less time, (though not always), or you can cut features for time, etc. etc. There are some that claim in the Age of Agile or for other reasons that this isn’t as true as it once was. They’re wrong. Common Sense doesn’t always hold up under careful scrutiny, but in this case, it does.

So what’s the point? The point is when we’re done with all the back and forth discussion, an estimate will be based on anticipated time to do something and the costs. So you will likely face potentially wide ranges of estimates depending on how easy/hard it is to estimate the tasks at hand. And software development is notoriously challenging to estimate. Discussions as to why are out of scope of this article, but suffice it to say, it’s a challenge. You will most likely get an early rough estimate. But for any project with deep complexity, chances are good some form of deep discovery will be required to get rational estimates.

Project Management Methodology as Related to Price

Regardless of specific project methodology, you’re going to need some kind of work plan. Even when using Agile techniques, you can and should develop as concrete a plan as you can for getting to where you need to go. In the case of Agile, there will be a lot more flex in that plan. But you’ll still need some kind of general framework. Otherwise, what are you buying?

When the Dinosaurs first started to use outsourced software, things were pretty easy. You could pay/charge by the hour. Or you could pay/charge by result. It was pretty much the same as how you could pay the service that does your gardening, by time or job. There were – and remain – variations on these themes. But then, along came Agile. So we now often have a situation where we really must take into account project management methodology as a component to pricing negotiation. This may have always been true. The difference is that way back when, the discussion was fairly simple. It was either “Assuming you have a quality worker, how much is the cost per hour and how long to get Job X done.” Or… “How much and how long for Job X; I don’t care about the hourly cost, that’s on you internally. Just deliver at this rate.” Now, with Agile – if you want to do Agile and you probably do – we have to account for the reality that the main point of Agile was and remains in dealing with messy realities of software creation. Namely, 1) We’re not sure what will happen along the way with the project itself and 2) We’re not sure how the world will change.

So, we ned to consider project methodology as it relates to costs.

Waterfall

Waterfall Project Management is a well known project methodology with a deep body of knowledge, available toolsets and experienced practitioners. While it is often seen as archaic in light of more modern Agile frameworks, it is a perfectly fine method to use. Just as with any tool, whether it’s best or not depends on the tasks at hand. And in any case, for a great deal of outsourced work, at least some form of Waterfall is often used, regardless of how often the word Agile is used to talk about project work. After all, minimally, (typically during the Discovery process), at least a general idea of outputs must be defined in order to scope and price out a project. This is not always the case, but as a practical matter is most often true.

Waterfall based projects need to be strictly managed so as to allow for adherence to budget and specific milestone delivery. As a result, if delivery date is emphasized, there may be pressure to sacrifice some degree of functionality to make dates. And if there are changes in scope, such changes will require the overhead of documentation and agreement, and likely adjusted payment schedules. The bottom line here is that when projects are outsourced with Fixed Price, Fixed Scope, much or all of the risk is on the supplier’s side, so projects must be tightly managed by the supplier. And this may be perfectly fine for some projects, and not so much for others. Even in a world where Agile, (with all its own attendant challenges), generally seems to work best for modern software development, there are projects with clear and well understood deliverables that can be run perfectly fine using Waterfall methods.

Agile

Agile Software Development is so well known at this point, to attempt to describe it given the many resources out there which already do would be pointless. For the purposes of hiring external contractors, however, it bears noting that Agile as a work method requires much more flexibility – and likely management effort – on the part of the Client; at least for outsourced project type work. Alternatively, if an individual or team is hired as part of Staff Augmentation, Agile methods may be applied as purely or as imperfectly as desired, because such team members will be delivering value over time according to a client’s internal team Sprint Planning, as opposed to project milestones – and their associated user stories – generated by the external project team.

In the case of Agile development, contracts will likely specify payment based on timeline according to team members assigned for given work periods. In some cases, contracts may define and account for “Story Points.” Though this can be a challenging structure. When Story Points are used as a basis for billable units, it’s critical to structure incentives to as to be a win-win for Client and Contractor, otherwise you risk a perverse incentive situation. Way back in 2008, one of the co-creators of Scrum, Jeff Sutherland, offered recommendations for such a structure, called Agile Contracts: Money for Nothing and Your Change for Free. This creative method is workable. However, it requires a fair amount of maturity on the part of both client and contractor. And as well, the client should really have a fully trained Agile practitioner on their team in order to participate in stand ups. In this situation, if estimating story points devolves into trying to equate story points to hours, (which they’re not), and manage them thusly,  that could spell trouble.

Regardless of the form of the pricing contract, purely Agile development really cannot be a fixed priced contract. Such a thing is antithetical to the Agile framework right on the face of it. Which leads us to a more simple Time & Materials type billable. However, this too may be unsatisfactory for project work as it’s simply the other side of the coin going from too highly structured to wholly unstructured. This also may be unsatisfactory to a contractor who may be challenged to assign personnel for unclear intervals of work. That is, the contractor could easily end up with excess slack time for some personnel, which can’t easily be assigned to another project given the need to dedicate committed people to the client’s deliverables.

So it’s likely the best way pure T&M billables relationships work is with true Agile, and clearly assigned work hours of team members. When there are date and cost constraints on milestones, even in the form of “Epics” in order to name them in Agilistic fashion, we’re really no longer talking about pure Agile. Maybe a Hybrid model, which again, Agile purists might scoff at. Nevertheless, this is often seen in SOWs to offer at least some structure so clients can envision the value stage gates over time. This will be true whether those involved choose to call it a hybrid model or Scrummerfall or not. That is, teams may work in a generally Agile fashion, with stand-up meetings and all the usual tools, but these constraints are – strictly speaking – not Agile. In a fully trusted relationship, a more purist Agile approach can take place.

Hybrid Project Management

As a practical matter, many contracted projects are some form of Hybrid Project Management as already somewhat alluded. Typically, at the very least, large scale milestones will be defined. Costs or Dates, (or both), will be defined either as hard deliverables with attendant billing events attached. Achievement of a milestone can result in contracted payment becoming due, possibly with bonus for on time or early delivery. Now, this sort of project definition is decidedly anything but Agile. The key here is that the Epics/Milestones themselves are understood to have some flexibility in terms of delivery time.

So what is the “Hybrid” aspect? Generally speaking, in the Hybrid model, broad strokes milestones are defined, however, a Work Breakdown Structure is not defined to the same rigor as would be typically done with traditional Waterfall. Instead, the milestones become more like Epics. And features – which may not be fully defined as yet – become Stories as part of Sprint backlogs. In these cases, projects may still have billable milestones, but the deliverable dates float a bit to allow for team driven delivery choices. (Or billables may be based on Sprints or simple monthly time.) As well, it’s understood that scope may very well change along the way. This methodology allows for project contracts to be written that allow for the contractor to remain healthy with clear billable events, while at the same time making sure the client’s project remains flexible so as to address learnings along the project timeline, whether they come from the doing of the project or from needs to adjusting to a changing marketplace. Alternatively, the team assigned to an Agile project may be billed out at some set rate, (typically monthly), as if the effort were Staff Augmentation, however, team members work as part of a specific project team accountable for clear project deliverables. (If this seems similar to just pure staff augmentation, that’s understandable as the difference is subtle, but exists in that a project team is still chartered towards an understood goal set, whereas staff augmentation deliverables may vary widely at any given time based on work at hand from the client.)

The challenge with a Hybrid model is getting mutual buy-in as to the high level milestones. And if using a more complex story point model, agreement as to team rates for Sprints or monthly commitment breakdowns.

Negotiation

Whole books and courses exist to discuss this topic. Going in depth here would be far beyond the intended scope of this article. The elements discussed here are intended to offer you the generalized concerns that parties to software development contracts may have.

If there’s one key understanding to successful negotiation, it is probably that if there is a clear winner and a loser then probably everyone is a loser. If a final agreement is reached where after all is said and done there is a serious imbalance in value capture, (whatever that may mean among the parties), then there is serious potential for trouble ahead in the relationship. There will often be a power imbalance in a relationship. And it is not always on the client side. (E.g., a small client engaging with a much larger vendor.) There may be times when a strategic relationship is worth some financial consideration. Such as a marquee client contracting with a smaller vendor and offering marketing rights. When these non-economic elements are used properly and strategically among all parties, the end result may turn out just fine. If overly weaponized, in the best case, parties walk away having just wasted time. In the worst case, the honeymoon is over before it’s even started and some degree of adversarial relationship may result instead of a productive partnership.

Business is not usually a one time game. It may be a good operating principle that “the client is always right,” while at the same time, not everyone is your client. If, as negotiations progress, it’s not clear that all parties can garner the economic value they respectively need from the relationship, it’s likely best for either or both to end the process and seek a healthier fit for the project in question.

About MSAs and SOWs

Master Services Agreement (MSA)

A Master Services Agreement (MSA) is a master contract that covers the overall relationship between the client and contractor. Much of the content in an MSA is boilerplate and you would see the same provisions across just about any contractor relationship, with special provisions as related to software. (Such as use of Open Source or similar.) Nonetheless, every situation is different and your legal team will clearly want to review such documents. Often, redline versions will go back and forth a few times to make sure everyone’s lawyers have their favorite clauses properly addressed.

The MSA is most often general in order to cover the relationship, and may cover multiple Statements of Work, (SOWs), which will be described below. Some MSAs have the SOW work items as part of them, possibly in the Appendix. It may be better to avoid this so that SOWs can stand on their own and reference the MSA. This way, there’s flexibility in changing the SOW or adding new ones, without having to re-open a master document that will ideally be somewhat evergreen.

Typical provisions in an an MSA will include:

• Non-compete clauses.
• Non-solicitation clauses. (So a client can’t simply hire away contractor employees. Though sometimes MSAs or SOWs provide for this possibility with appropriate agreement and consideration.)
• Intellectual Property ownership. Typically, this will ensure a client owns any resulting “work product.”
• Payment terms. This should include when payments are due, incentives for early payment, penalties for late payment, and so on.
• Liability issues: Who is responsible for what in the case of malfeasance by a party to the contract. For example, a patent infringement or limitations of Open Source software.

Statement of Work (SOW)

The SOW is what specifically defines the project. It may have varying levels of specificity for work product. Here are some typical components you’ll find in an SOW.

• Basic header information such as SOW version, project name and date.
• Introduction. Basic background of project.
• Assumptions. Any agreed upon issues related to the project. For example, what constitutes an out of scope item, client availability, etc.
• Tasks/Activities: This section may be high level bullet points only, or up to a fully detailed project plan.
• Non-goals: It’s a good idea to have such a section if there have been discussions that clearly limit the scope of the project. This will make clear what – if any – aspects that have been discussed are explicitly not part of the current project.
• Effort: The effort section may take on different names, but includes things like Personnel, Duration, possibly Milestones, and Pricing.
• Terms: This will specify things like payment terms, (typically ‘net 30), discounts or penalties for early/late payment, expiration of the SOW being offered, and similar.
• Authorization: The signature page for both parties to execute the contract.
• Time Frame: Even if an SOW is ‘evergreen’ in terms of duration, there should be some endpoint at which it needs to be renewed; typically a year. If for nothing else, pricing may change over time.
• Danger Point: The level of specificity within an SOW can determine the risk level for challenging conversations to come later. A high level description of a basic feature may imply inclusion of various sub-components to one party, but not to another. At the same time, to get overly specific may require much larger time and effort in discovery, and be overly constraining in a world where we collectively attempt to be more agile in responsiveness to changing needs over time. It is likely wise – for both parties – to have some general provisions regarding a basic framework for what might be considered “in scope” for various requirements, vs. what might trigger a more formal Change Order.

Navigating Procurement & Payment Terms

Payment Terms

Payment terms may vary across vendors and projects. In many industries, ‘net 30 is the standard payment period upon being invoiced. But when might invoices occur? There may be project initiation fees ahead of work on a large project, there may be monthly fees billed forward of the work month or in arrears. For milestone based projects, there will often be some form of project initiation or inception payment, thence payment upon milestone delivery and finally a project closeout cost. There may also be bonuses tied to early delivery or other criteria. And when it comes to payment terms, possibly discounts for early payment or penalties for late payment.

Part of how or why payment terms are formed has to do with trust. For firms that know each other well, or large well-known firms, terms can be fairly generous either way. For example, a vendor might not balk at a ‘net 60 payment arrangement as they can be highly confident a large corporation can and will pay its bills. Similarly, a client may want to structure milestone projects with relatively low initiation fees, fair milestone fees, but with a ‘kicker’ type payment at the end to insure final project delivery before a larger final payment is made. For the vendor’s part, just as always it’s important to manage receivables. It is a worst case scenario if receivables age to a point where a vendor must consider a client in breech and stop work. It’s important to have these terms sorted out clearly and adhere to them along the way.

Procurement

When larger firms are involved in negotiation, a Procurement Department on the client side may come into play when it comes to finalizing deals. Or much earlier upon vendor search and selection. Where and how Procurement gets involved will be up to that company’s policy. Whereas a Purchasing department might go on about the typical tasks of managing acquisition of supplies and such, and perhaps some price negotiation, procurement will go more deeply into vendor selection, negotiation and approval. The challenges in working with procurement for both managers on the client side and sales management on the client side is the time and effort to manage through this layer. Procurement is potentially a two edged sword. The department may be incredibly helpful based on their experience in managing the contract process… or they can kill a deal dead after a lot of work has been done by both parties. Procurement may be a strategic asset to a company, managing costs and finding a good fit with strategically sound vendors, or an innovation killer if focused overly on the cost side and scaring away potential partners, or even killing internal funding for innovation projects.

For both client operational staff responsible for sponsoring a project and for vendors, it’s best to know if a project will be required to run through a formal procurement process. For smaller vendors, they may not fit an acceptable capital or general firm risk profile of a procurement department at a large company. There is no point in wasting the time of client and vendor personnel if there is a high likelihood procurement would kill a deal. From the vendor perspective, as amazing as the dollars and prestige of working for Super Large Corp. may be, it might not be worth the beating on price procurement may be looking to inflict. It might be ironic that a sensibly valid concern for procurement is small vendor solvency, however at the same time they may use their heft for price pressure harsh enough to do non-trivial damage to an overly eager vendor. So again, whether you’re the IT manager in need of external skills or the vendor, it may make sense to get procurement involved early if that’s potentially a factor in negotiations.

The Tiered Project Execution Model

There is a pattern that can be quite effective for both clients and contractors when getting to know one another. This involves separating a large project into early initial phases that allow for the client to confirm quality of execution before making a long term commitment. (Or just use a wholly separate small project as a trial evaluation.) For small projects, (for our purposes here we’ll call those under $250K), this is likely overkill. However, for larger engagements among parties new to each other, this can provide some validation for both parties that a successful long term partnership can be formed. Large projects would typically be those that climb into the seven figures and have a duration extending well past a year. Clearly, the value judgment as to what is large or small in terms of project size will vary by firm, however, for the purposes of this discussion, anything less than several tens of thousands of dollars likely does not warrant this approach. That is, the overhead of breaking down smaller duration projects might not be worth the benefit of a test period. Remember that this trial run should course produce value in and of itself, but it’s also about more than project delivery. It’s about whether team members can see themselves working together reasonably seamlessly and long term. There are very real costs in partner seeking and in switching costs once deeply engaged in long term work. Questions here are less about the dollars and value; the answer to that should have been judged as yes before getting to this point. What you’re trying to answer here is “Is this the team I want to go into battle/go to market with?” Creating anything is usually challenging. Everyone is going to bounce off guard rails on occasion. Business, personal lives, earthquakes, market crashes, etc. etc. are all part of the obstacle course. Is this who you want to run it with? Is this the team with whom you can negotiate through the hard times when they come during a longer term engagement? Does it sound a bit like a marriage? Well, it kind of is of sorts; with all the attendant legal aspects. And all of this is something both vendor and client need to evaluate.

The way this works is as follows:

• Discovery Contract
  • The depth of requirement here will obviously depend on overall scope. However, for a smaller project, Discovery will ideally last no more than a few weeks. And for a larger project, no more than a few months. This may take the form of the contractor assisting the client with everything from requirements definition and analysis though high level design, if the client does not already have such things in place. Where the client does have a reasonably sophisticated requirements set defined, Discovery will likely include high level technical architecture and an in depth project plan definition. Such contracts may run as little as several thousand dollars though perhaps as much as $250,000+, depending on resources involved.
• Fixed Price – Early Milestone(s) Only
  • In this phase, the contractor will deliver code elements or other artifacts for the first phase of the project. The contractor will assign minimum personnel in order to demonstrate to the client the capacity to make the dream a reality; to delivery quality work product, (ideally code), sufficient to show the client the contractor is reliable. However, the contractor will not spool up what might be a large team in order to fully execute what is likely a long term relationship for both.
• Agile All In – Full Project Engagement
  • During execution of the early milestone project, contracts may be negotiated for the full project engagement. The time and effort to navigate through project approvals, procurement, possibly board approval, and so on, can take place during the early project. Assuming successful execution of the early project, these contracts may be finalized and work would continue past the initial milestone. At this point, contractor will work towards spooling up full team for project.

There are both benefits and shared risks of this model. The benefits to both parties here is in the worst case, they discover as early as possible that there is not a good fit for an ongoing working relationship. On the part of the client, assuming we’re past the Discovery phase, the worst case is they have actionable artifacts from Discovery that may be used by either an internal team or another contractor. Though the client will also suffer the need to implement another partner search. It could be argued that there’s no point to the Early Milestone phase as any contract will always allow for some form of termination for cause. However, the point of this structure is to recognize the goal of a long term shared relationship. Few contractors will fully dedicate large teams, (much less hire if necessary), outside of a clear commitment. This structure can offer both parties confidence that the mutually desired outcomes are feasible. It’s important to note again that we are talking about software development here. It may be the case that early Discovery involves Product Management and high level design, either or both from a application architecture or UI/UX/IA perspective. It may certainly be possible to make a value judgment on a firm based on how it delivers these items. However, these types of project deliverables don’t necessarily come with any working code. At minimum, delivery of some basic working prototype can at least show some prowesses in this area. However, if there are other technical projects that can be carved out, these may be better indicators of skill. For example, if you’re a large retailer, is there some kind of ETL project that’s part of a logistical flow that the external provider can handle? What about something involving analytics extraction from micro services and subsequent processing? For AI/ML, perhaps a basic image recognition or smaller scale demonstration of a reinforcement learning approach to a small problem? The point is to have some kind of trial project that is at least somewhere in the same area of the intended work types and frameworks as the larger deal.

The In Work Project

Change Oders

Pay attention to this section. The basic mechanics of the provisions for change orders are usually fairly simple. And it’s maybe just another boring piece of boilerplate. And yet, it’s this potentially small piece that can be a project killer.

Change orders will be a component of most SOWs involving fixed fee or clearly scoped milestone projects. At least, they had better be. When and how the need for them may be triggered should be specified in either the Master Services Agreement (MSA) or Statement of Work (SOW). A Change Order may be acceptable with a quick email negotiation or require its own executed document. Anything in a Change Order will supersede or extend the associated SOW. Ideally, there is a formal process for Change Orders. They will usually have an associated cost and may require some negotiation of their own. Change Orders do not necessarily involve costs, however it’s in the interest of both parties for significant changes to be adequately documented – in writing – to make sure there’s a clear understanding as to what aspect of scope is changing. For example, it’s possible there’s a change to an upcoming milestone which hasn’t generated any costs at all as yet. If the new effort is anticipated as being similar, there may be no need for any type of cost consideration at all. However, there will remain a need for contractual clarity as to the deliverable to be produced.

Unless this is your very first software project, you know that change happens. Waterfall, Agile, Scrummerfall, SummerScrum, KanScrumbanFall… the method doesn’t matter. During just about any software project of any significant duration, SOMEthing(s) will change. And just using Agile methods won’t help the fact that something is going to take longer and cost more than originally thought. Or some work already done is now worthless. Your market may demand something new, you may learn things as the team designs, builds or deploys, the new boss has to have the thing that scrolls down instead of right, there’s a new integration partner, etc. etc. etc. etc. etc. (add some more Etc’s.) You need to understand this, budget for it, (insofar as this is possible), and be mature about it. But don’t ignore the reality. Who knows, maybe you’ll get lucky and your change management provisions will work similarly to bringing an umbrella so it doesn’t rain. But don’t bet on it. And you are betting here. The client is betting their success and a project sponsor in particular may be betting their job. And the vendor is betting their reputation, which is among their most important assets. One of the biggest risks to projects, relationships and successful delivery is tense conversations around change management. Or runaway scope, which is a generally similar kind of potential problem. Failures here can blow budgets. And in extreme cases, can potentially fully fail a project and maybe even kill a company in the most extreme cases.

Change management is possibly one of the most challenging aspects of any project. The need occurs for many potential reasons; the world changed, a business relationship changed, a new competitor has emerged, we learned something new along the way, something just can’t be made to work as intended, the list goes on.

Delivery, Ongoing Support & Closeout

At some point, your project will launch. Whatever your Definition of Done may be, you’re essentially done. It’s an exciting time. If your project requires ongoing support in the form of DevOps, your relationship with your contractor will of course remain intact as per the support aspects of your contract. When there’s a successful project, there is often follow on work for additional features/functions/benefits. In these cases, it’s important to have worked on potential new SOWs prior to project completion. The reason for this is the contractor now has staff that is deeply familiar with your company and product, and has built effective working relationships with your team. However, unlike your own internal team, once the vendor’s project team is done, they’ll be re-assigned to other projects. If there were any sub-contractors involved, those relationships will close and everyone moves on. Essentially, you lose any subject matter expertise or cultural alignment you had built. This is a challenging to define, but non-trivial value that can impact effectiveness and efficiency. For larger projects, it can take weeks or even months for teams to really hit their stride. So if there is to be ongoing support or project extension, you want to do that paperwork early, or you may risk losing team members to other projects. When a project ends, some folks may end up on the bench or an internal project for a little while, but usually not for long.

In the cases where a project is being handed off to an internal team for ongoing maintenance and management, you – perhaps obviously – need to make sure provision has been made for a fully acceptable handoff. Even when requirements don’t change, platforms do, security flaws are discovered, frameworks face updates. Your internal team must be comfortable enough with the codebase to pick this up.

Conclusion

There are thousands of software development firms of widely varying size and capability. Just for fun, assume just 5 projects each per year. That’s tens of thousands of projects per year being implemented by contract developers. And that’s just firms, not including thousands more solo consultants. Every single project may follow a general pattern, and yet all will be subtly different. With all the books and articles on processes and so on, our reality is that no one has yet found that magic all encompassing right way to do anything in particular at all. Patterns? Yes. Some Best Practices? Sure. One size fits all? No. We’re just not there yet. And maybe we’ll never be. However, ideally some of the options presented here make you a more informed buyer or vendor of such services. Please go ahead and offer any feedback you think appropriate if you’ve find anything discussed should get more attention.