Recently I got this question from a leading software development team manager about how to price development services:
“I wanted to ask you a business question, …when you are consulting for web development firms, how do they structure their pricing? Were most projects done on an estimated price and the clients just pay that and the company eats any overtime? Was it by hour? Was there some kind of mix of the two. I’m interested because the way we do it seems sub optimal to me and leads to real pressure to turn things in at the minimum price. I’d be interested to know what you feel the optimal strategy is when your selling a full ‘from the ground up’ website build.”
Many Developers can relate to this question about how to price software development services. Developers struggle to manage scope, achieve target margins, and ultimately keep their clients happy. And many Developers end up doing everything a client asks with the goal to keep them happy. Often during this pursuit of happiness, Developers give away considerable time, skilled effort, and ultimately cut margins or lose money. If you’re a Developer who faces, or has questions about, pricing challenges read-on.
The Problem
Clients want awesome software delivered on-time, and at a price that meets their budget. Developers want to get paid for the time they spend designing, developing, and maintaining the awesome software they build. These two descriptions of the respective wants of Clients and Developers describes the development services environment. To clarify, the term “software” as used here refers to coded systems that power computer applications, websites, and mobile apps.
As simple as it sounds, it is extremely challenging for Developers to get paid for all the time they spend creating awesome software. A typical software development project is features these key issues:
- New Requirements – New features and functionality that arise during the project (also affectionately called “scope creep”),
- Schedule Delays – Delays caused by developing new requirements that add time to the delivery schedule,
- Cost Overruns – Additional money paid (but not without a fight) by the Client for developing new requirements.
In my experience, there are three main causes of these project management issues that the Developer can control:
- Poor Management Of Expectations
- Poor Documentation
- Poor Change Management
It Starts With Setting & Managing Expectations
Whenever a Developer has pricing questions or issues I have found the root cause lies way back up the chain of events to how expectations were set with the Client at the start of the project. The common Developer approach to getting hired is to underbid their competition to win business. Pricing issues show-up when the price bid does not cover the costs or deliver the target profit margin — you know that. The real question is, why does this happen? It happens because typically, during the bidding and confirmation process, Developers do not effectively educate the client and set clear expectations around the need for definition consultation before a price can be proposed.
Right from the start of a development project a critical requirements gap exists between the availability of clear and specific functional requirements, and the clients desire to get a quote for development based upon the information they provide. Simply put, development of the system cannot be priced accurately using the information the Client provides. This is the root cause for software development project cost overages, schedule delays, and a general failure to achieve favorable outcomes for the Client or the Developer.
Most development projects start with a Client making a Request For Proposal (RFP) or otherwise communicating their request for a quote via email or in a conversation. A typical development project request from a Client looks something like this:
“Seeking an estimate to design, develop, host, and maintain an online registration form to collect contact information. The form will appear on the company website. Form data must be exported to an Excel file.”
While this initial request does describe what the client is looking for, it does not feature the level of detail needed to accurately define specifically what will be developed, how it will be developed, and who will be needed to develop it. In almost all cases, the information the client provides in their initial request does not contain the details required to produce and accurate estimate. In this example some key questions that require further definition to define are:
- How will the form “appear” on the company website? Options include: direct on-site development, iFrame placement, or via a sub-domain.
- What are the maintenance requirements? Options include: daily/weekly/monthly status checks, manual data downloads, generate usage reports, etc.
- What data specifically must appear in an Excel export? Options include: just the forms field data, each users IP address, user geo location data, etc.
The answers to these questions about what some may describe as “a simple webform request” have a direct affect on the time, effort, and cost of developing that webform. Answering these questions requires consultation by the Developer and the Client before the Developer can provide an accurate quote. I call this critical consultation needed before an accurate quote can be provided Definition Consultation.
Two Estimate Approaches
There are two effective ways to address this requirements gap to the benefit of both the Client and the Developer.
For simple systems, agree to an estimated price based upon a) a set of Functional User Stories; and b) a set of Assumptions; both prepared by the Developer, and with the agreement that any changes to the User Stories and/or the Assumptions will require changes to the scope, quote, and schedule. This approach enables the Developer to provide a quote with the clear expectation being set with the Client that the scope, quote, and schedule will change as new information and understandings are discovered while working on the project.
For complex systems, agree to Definition Consultation. The Developer will produce an estimate for Definition Consultation to define specific functional requirements and specifications for the project, and produce the following deliverables that the client will own: Functional User Stories, User Acceptance Tests, Systems Design & Specifications, User Experience (UX) Design Wireframes and Specifications, User Interface (UI) Design and Specifications.
Definition Consultation is like hiring an architect to design a house the Client wants to build. The client could go directly to the contractor (Developer) and say “Build me a modern 3 bedroom house with stone trim on the exterior.” But the chances are really high that the Client will not be pleased with a house the contractor builds based only on that request. There is simply not enough detail in that request to build the house the Client wants. Exactly how big (or small) are the kitchen, bedrooms and the bathrooms? What kind of doors and windows does the Client want? How many cars must the garage hold? Will the house have a water filtration system? What kind of flooring will the rooms have? What kind of “stone?” Etc. The Client hires an architect to design the house they want by consulting to define the specifics. Then the architect develops blueprints and materials specifications (functional user stories, user acceptance tests, UX design, and UI design) which the builder (Developer) uses to estimate construction (development).
Note that the construction estimate is based upon the details provided in the deliverables that the architect develops during the consultation with the client. A Definition Consultation is the same thing. The Developer consults with the Client to review the details of the clients requirements, present pros and cons of solution options for requested features, and produces detailed specifications and designs that are used to develop the system and provide an accurate estimate for development.
The Client may use the specifications and designs produced during Definition Consultation to get quotes from a number of developers. To put it another way, the Client now has blueprints and specifications for their system that they can use to get a quote from any developer they choose. Another key benefit of the specifications and design documents produced during Definition Consultation is that they serve as clear definition of “scope” for the development project. The basic rule here is “if it’s not in the specs, then it’s not in scope.” This documentation also serves as a clear basis for approval of deliverables that is not subjective.
Recent Comments