New Jersey Software Licensing Attorney
Commercial consulting, professional services, consulting, software development will collectively be discussed here as (“Services or Projects“) generally they start with a software application package that the Customer believes will address most of their operational needs. The Customer then carefully considers various consulting vendors (“Consultant“) that have a demonstrated competency with that application package, and then the customer starts the process of defining which consultant they would like to implement that software to address their specific requirements. Consultants typically construct an outline of the high level Project tasks they envision for that delivery (“Project Plan“).
Of course the exact tasks and sequence of those tasks vary from one Project and one customer to another. Typically, a consulting Project starts out with some sort of fact finding process (due diligence or feasibility study) as Milestone 1. For the purposes of this paper, Milestones are a series of sequential steps that may start with due-diligence, design, test, implement and support the Project. Often these milestones are linked to progress payments, so when you complete, and the 1st Milestone is accepted, perhaps a feasibility study, you would earn the fees associated with Milestone 1. Generally the Customer retains the right to suspend or terminate a project without cause or liability at the end of each Milestone; basically they consider the deliverable from the prior Milestone and their current and projected needs and then make the determination if it is worth proceeding with the Project.
This fact finding process may include discussions with the customer’s team members, this detailed information is intended to define the Customer’s requirements (due diligence). Often this fact finding process is followed by having the Consultant review with the Customer the various functional options available within the packaged software application. Milestone 2, might include the review of those options and as well as consideration of certain modifications required to meet the Customer’s functional requirements. Once the Customer makes all of their design decisions that is generally referred to as the “Design Specifications” (or perhaps just “Specifications“). The results of the Design Specifications, are then organized by the Consultant into a logical sequence of service steps and software deliverables and those deliverables together with a projected timeline for their delivery (or at least the sequence of the delivery tasks) is reflected in both the (“Statement of Work” or “SOW”) and then used to update and the associated Project Plan.
Software Licensing Attorney John P. O’Brien
Serving Businesses of all size with technology related contracts and business services
Duties and Obligations - Technology Consulting Projects
At the start of any Consulting Service Project it is extremely important to develop and agree upon a clear definition of the respective parties’ duties and obligations. Another important component of a good SOW are project assumptions that each party can rely upon, i.e. valid licenses, office space etc.. Often Customers make the mistake of thinking that the preferred contract positions (like those found in many corporate authored Master Service Agreements, “MSA“) are the object of the Project negotiation, perhaps shifting duties and responsibilities to the other party, or adding penalty provisions for late fees etc.; however in reality your goal whether you are the Customer or Consultant should be to construct a fair agreement with reasonable detail, and a defined process specified within, so that agreement that helps to avoid unpleasant surprises. If you want to use your energies in a productive manner build contract remedies (see Contract Remedies) into the SOW rather than penalties. For instance if the Project is behind schedule in the Consultant must add staff as a remedy that is far more productive than charging the Consultant a late fee. More often than not when one party to a Consulting Project pushes for “more-than-fair” that push is counterproductive to the success of the Project. It may sound quite simple but the problem is in many cases, is that steps are minimized or skipped all together; one party or the other start to make assumptions in the absence of robust participation by the other party, feedback is delayed or not provided and issues are not addressed; the real issue is that effective Consulting Service Project delivery requires organization, proper skill-sets, appropriate industry background and dedication to the delivery process….”Delivery Discipline“. As you continue on we will mention a number of terms that you may have heard (Scope, Project Assumptions, Status Reporting, Change Control, Acceptance and Contract Remedies) and help provide a definition and the context of their role in a Consulting Service Project.
Considerations with Technology Agreements
With a fair Consulting Agreement as our stated goal, let’s look at some of the elements that we expect to see in that agreement, and make a brief mention of a few other provisions that may also be included to help ensure that result.
Project Assumptions include items clarifying the requirement of items like: proper software licenses, appropriate configurations, access to personnel and any other resources that may be required; these are the things each party expects from the other. For instance the Consultant might expect that the Customer has proper licenses to certain software featured in the Project that the Consultant is being asked to modify, install or integrate. In addition the Consultant might further expect that those software application packages are subject to a software maintenance agreement from the manufacturer 1) to support that software and 2) to keep the software current with later releases (i.e. that updating is not a duty that the Consultant assumes simply because he is doing other Project work). The Consultant might also clarify that the Customer’s computer platform is properly configured and remains subject to a maintenance agreement, etc. The parties may agree to schedule maintenance after hours or on weekends, etc. Both parties must assume that each party has a duty to have all necessary pre-defined resources, equipment, records and people ready in accordance with the stated assumptions so that the Project work can proceed in a timely and efficient manner. The failure of either party to meet their obligations as agreed upon in the Assumptions section of the SOW becomes the basis for a change order. Assumptions may also incorporate the Customer facility’s workplace rules, hours of operation, holiday schedule, security policies, etc.
SCOPE of the Service delivery obligation must be an adequately defined deliverable; specifically, if you need to explain what you have documented, then your documentation is insufficient (this is your litmus test for the Project’s scope definition). The Consultant will help discuss alternatives, however even well run customer environments will inevitably learn much more about their requirements as well as the software’s capabilities over the course of the Project’s delivery, they will come to appreciate more completely the trade-offs in design alternatives, and the delivery obligations will evolve, shift and grow; this phenomena is commonly referred to as “Scope Creep“.
It is essential to the success of a consulting services Project that the parties agree upon a set of rules that they can rely upon to ensure the Project stays on track, both the Consultant and the Customer have a formal centralized process for keeping each other informed and holding each other accountable. This set of consulting service delivery rules is commonly referred to as “Project Methodology” and the rules might include (Status Reporting, Change Control Process, Issue Resolution; and Acceptance Testing etc.) Sometimes the rules may have slightly different names, some professionals might have slightly different lists, however they are functionally identical and the essential requirement is that they are clearly understood and carefully followed during the Project service delivery process.
Status Reporting defines the parties’ joint obligation and duty to participate in regularly scheduled (weekly or bi-weekly) formal status meetings to review of the progress of the Project delivery to date; review and respond on the appropriateness of the service deliverables. Remember, the Customer will always know their environment better than any 3rd party and therefore the Consultant must rely upon the Customer’s ongoing feedback throughout the Project delivery process. If the Customer i s late or inattentive the Consultant will presume the information provided thus far is accurate and complete. If the software requires a feature or function that is not in the SOW, or if the Customer’s operation dictates that some process flow work differently from the standard software package process flow, the Customer has the duty to speak up promptly. There is no adequate substitute for the voice of the Customer.
Change Control addresses the fact that the Customers’ needs will change over time, often the business will undergo new challenges, and these will drive the need to change the consulting service deliverable. Even with the very best definition of the delivery environment some change is inevitable, often the change could come as a result of a more detailed and accurate understating of the Customer’s environment and business requirements as the Project delivery proceeds. Frequently, early Project assumptions regarding the number of records, or the quality of the Customer’s data is severely mistaken. Changes should be mutually agreed upon; and not all changes affect the Project’s price or the Project’s estimated delivery date for the Service Deliverables. However all changes, even zero dollar changes, should be formally reported in the Status Meetings and documented in the associated Status Report in order to gain a clear picture of the overall cumulative Project delivery process. A Change Request should require mutual written consent before it alters the delivery obligation. All open Change Requests should be tracked and reported upon during the Project’s weekly Status Meetings and associated Status Reports.
Acceptance sounds simple enough, but you should establish a default period for acceptance and where a particular Service Deliverable (or milestone) warrants you may override and extend the acceptance period for a longer period, you would generally stipulate that extension in the Statement Of Work (“SOW”) where you define that Service Deliverable (Milestone). The acceptance criteria should also be clearly defined within the SOW, this defines what functionality will be tested. Customers often resist the need to define the acceptance criteria inside the SOW, but frankly this is the best way for any Customer to ensure the Service Deliverable (Milestone) functions in accordance with their expectations. Candidly, it is the effort of going through the process of defining meaningful acceptance criteria that forces a deep and thorough Customer understanding of the required functionality. Every Customer thinks they understand what they require, but that never truly happens unless they are forced to define the functionality in the SOW acceptance test criteria for the Consultant. Many of the better acceptance tests define the sample data and a test script that will be used to rigorously test the Service Deliverable; again it’s the process of defining that test script that is so valuable. That process inherently forces the detailed planning and careful communication very early in the Project delivery process when the SOW is being developed, that clarity of purpose is invaluable to the success of the consulting service delivery process. Remember, an acceptance test should not be viewed as a trial drive, it should reflect peak workloads and demanding transactions as well as normal transactions, it is intended to be much more rigorous than a few days meandering through unplanned user testing; but it’s like exercise, if you put no effort into it, the value of the acceptance test dramatically diminishes. The Acceptance Test provision should address a cure period and re-testing in the event the Service Deliverable/Milestone fails to function in accordance with the SOW. The length of the cure period, whether a 2nd cure period is provided in the event of another failed delivery, and what other remedies might be appropriate is dependent upon many Project specific details.
Software Licensing Attorney John P. O’Brien
Serving Businesses of all size with technology related contracts and business services
Service Delivery Agreements are Fundamentally Different
Service delivery agreements are fundamentally different from most other agreements in one very simple but profound way…..in a Service Delivery Agreement; regardless of what remedies are provided in the contract, if the Project fails, both parties fail. In most cases the Customer is just left starting over the Project very late, fresh on the heels of a bad experience and making it even more difficult for the next Consultant to successfully complete the Project. Now think about a failing Project from the Consultant’s perspective, if the Customer doesn’t know what they want (no clearly defined deliverables) or at least has not bothered to define what they want and keeps changing their direction, how can the consultant avoid failure?. The Consultant, no matter however qualified, cannot make up for the tasks that the Customer has not done, or refuses to do, on their own behalf. Successful Projects are well planned and carefully monitored joint efforts, in this way that potential problem issues are spotted and resolved quickly before they become big issues.
What do you do when a Project Delivery starts to veer off course? Customers are sometimes tempted to focus on ensuring that the Consultant’s failures are proven and acknowledged; just as Consultants are tempted to demonstrate how missing or inaccurate data, along with lax customer participation (reviews and such), combined with a series of changes from the initial SOW helped cause the Project delivery problem. In every failed Project there are generally plenty of things each party could have done much better and much sooner to help prevent that failure. Whatever you do, don’t ask the party’s that failed to analyze why the project failed, their judgment is skewed (they will always feel it was the other party’s fault). Neither party wins when they engage in a finger-pointing process; that process alienates the other party and just defers and meaningful efforts to actually resolve the problem. If you agree with this requirement for a “win-win” Project philosophy Contract Remedies can represent an excellent vehicle to accelerate the cure process and by-passing fault assignment and litigation sink holes. However, this approach requires more work by both parties to: 1) contemplate meaning contract remedies as you construct the Project delivery plan; and 2) more work in careful monitoring of the Project delivery process so you can initiate the cure before the deliver gets too far off track, (for this the parties must rely upon following the Project Methodology). It’s much easier to get the other party to consider and agree upon appropriate cure measures, when they are clear-headed and still in a logical planning; if you do not bother to do this up front and raise the subject after the Project starts to falter, you will get finger pointing rather than a meaningful cooperation in an effort to cure the problem; for example rather than argue why a Project is 2 weeks behind schedule, it might be more useful to have an additional Consultant and/or Customer resource assigned to help catch up…that is a potential contract remedy that might be stipulated in the SOW.
With a wide range of powerful applications for so many business information requirements there is a greater need than ever before for appropriate professional services to help you implement, leverage and support those applications within your operations (we have more bricks but fewer skilled masons). However, every a Consulting Project is unique, your needs, the Customer’s staff, the Consultant’s capabilities all factor into the makeup of and appropriate Project SOW and Project Plan. This wide range of topics together with many others noted, but not discussed above must be considered as you develop your SOW, your Project Plan and your Consulting Service Agreement.
More About Technology Consulting & Agreements
Warranty – once your acceptance test is successful does your project include a warranty, if so how long does that warranty last, does it extend to 3rd party products, etc.. Learn more about Warranty.
Warranty vs. SLA – what makes sense for your project requirements, do you understand the differences and can you receive both? Learn more about Warranty vs. SLA.
IP Ownership – who owns what? Can the Consultant use pre-existing work, how about open source? Learn more about IP Ownership.
Dispute Resolution – alternate dispute resolution does it make sense, and is your management willing? Learn more about Dispute Resolution.
SOWs – what items are best addressed in the Agreement and what at the transaction level? Learn more about SOWs.
Contract Remedies –what remedies put the parties in the best position to succeed? Learn more about Contract Remedies.
Flow-Thru Obligations (background checks, security policies, and privacy laws) – what duties should be flowed thru to the Consultant? Learn more about Flow-Thru Obligations.
Acceptance – why is acceptance so important to both parties, do you understand its impact your duties, obligations and rights? Learn more about Acceptance.
FAQs – the top 5 questions to ask from both the consumer’s perspective as well as the developer’s perspective. See top 10 SaaS questions to ask here.
Technology Consulting Attorney John P. O'Brien
I would be pleased to help review your requirements and discuss your specific requirements. I have helped consultants and hi-tech customers successfully implement Projects of all sizes. Please contact me for a free 30 minute consultation to help determine if my legal support services are right for your business.
John O’Brien has focused on evolutions within the tech industry and has worked for large manufacturers and software developers. As a professional services counsel for Digital Equipment in the early 1990s he worked closely with Project managers and their team in support of customized software development and deployment projects in their NYC Area practice, the largest PS practice in the country at the time. Later as an Area Counsel in Sun Microsystems he witnessed the amazing client server/open systems shift that is often referred to as the .com. More recently he has been immersed in support of software developers and SaaS providers. Change is the only constant, but you need to be able to discern the implications of the change on your operation and adapt. Let him help put that experience to use for you.
I am a legal professional specialized in helping companies of all sizes develop, negotiate and/or modify consulting contracts, licenses (in-bound or out-both), SOWs, HR agreements and other business related financial transactions.