Custom Software Development Projects: A Complete Overview
Table of Contents – Click Any Title to Jump to Section
Introduction: Custom Software Development Projects:
Commercial consulting, professional services or software development will collectively be discussed here as (“Custom Software Projects“). Generally, they start with a software application package that the Customer believes will address most of their operational needs. 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. Milestones are a series of sequential steps that may start with due-diligence, design, test, implement and support of the Project. Often these Milestones are linked to progress payments, so when you complete the 1st Milestone and it’s accepted, for example a feasibility study, you would earn the fees associated with that Milestone. 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 or perhaps they have learned a lot more about their Project requirements and need to consider a change order to revise the project to meet the new needs that they have become aware of.
This fact finding process generally includes 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 the various functional options available within the packaged software application with the Customer. Milestone 2, might include the review of those options and as well as consideration of certain packaged software modifications required to meet the Customer’s functional requirements. Once the Customer makes all of their design decisions, it is generally referred to as the (“Project 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 are arranged to form a projected timeline for their delivery (or at least the sequence of the delivery tasks) is reflected in both the statement of work, (“SOW”) and then used to update and the associated Project Plan.
At the start of any Consulting Service Project, along with the definition of the Service delivery, it is extremely important to develop and agree upon a clear definition of the respective parties’ duties and obligations. Successful projects require effort and constant communications between the parties throughout the software delivery process. Another important component of good SOW’s 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 but unbalanced 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. 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, the Consultant must add staff as a remedy. This remedy 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 in many cases is that the planning of the SOW steps are minimized or skipped all together. Then one party starts to make assumptions in the absence of a detailed SOW and robust participation by the other party. Often the other parties feedback is delayed, the pressure to complete the project builds and important Project 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….collectively referred to as (“Project Methodology“). As you continue, 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.
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: Custom Software Development Projects
Project Assumptions include items clarifying the requirement of items alike: 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: Custom Software Development Projects
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”.
PROJECT METHODOLOGY: Custom Software Development Projects
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 and 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: Custom Software Development Projects
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 is 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: Custom Software Development Projects
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: Custom Software Development Projects
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.
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.
