Secret ingredients to quality software


Spec - Do you conduct a Specification Review? (ask for a coffee not a marriage)

Created on 25 Mar 2013 | Last updated by Ulysses Maclaren [SSW] on 05 Apr 2021 11:00 PM (10 days ago)

A client will often ask for a proposal or ballpark for the project. It is very difficult to give them the price for a large project without first conducting a specification review.

The Spec Review is a process that will demonstrate to the client whether you have the commercial sense to understand their *business* and have the technical and management capacity to complete the project.

It is paid work conducted after the initial meeting to determine the overall scope, feasibility, and ballpark costs of the project (i.e. $50k or $500k). E.g. Mr. Northwind learns that the idea he presented at the initial meeting will cost approximately $80K and he has to determine if that is feasible to his business or if he will trim the functionality to better manage the cost.

Figure: A ballpark or proposal should start small and not be a big commitment

"From this initial meeting, the ballpark is 6 months and $200K+GST"

Figure: Bad example - big scary figure

"From this initial meeting, we will first need to conduct a specification review.
This first step is $6K - a 2-day Specification Review"

Figure: Good example - work in small chunks of work with details about what you will do

Spec Review length

The Specification Review is conducted by two experienced developers at the client premises in close consultation with the client. The time allocated for a Spec Review is generally 1 - 5 days depending on initial expectations of the project. The rule of thumb is 1 - 2 days of Spec Review per estimated month of project time.

The purpose is to understand the whole project but, if the project is greater than six months, focus primarily on the first six months.

Talk about business requirements

  • Conduct Workshops: Conduct workshops with different groups of users (e.g. management, back office, customer service) to build the "Product Backlog" which the business wants. This ensures that all users get their say. Some "nice-to-haves" might actually be quite easy to implement. Product Backlog Items can then be prioritized and fleshed out.
  • Review Documentation: Reviewing any documentation the client may already have. Remember clients are mostly looking to software consultants to assist them in solving business problems.
  • Keep Technology discussions short: Unless they have a specific business purpose, detailed discussions about technology with the client are unlikely to be useful. For example, most clients won't be interested in a discussion about whether to use MVC or Angular at this stage.
  • Identify an MVP: Most client can't afford everything they want, so make sure you're keeping track of the minimum we can do to deliver value.

Do something valuable

Most software consulting experts will be able to provide a small improvement to the current system 'on the fly' during the Spec Review. This may be something as simple as adding an index to a table and thereby increasing the performance of a web page.

Use 'Corridor Conversations'

ProjectManagement Suprise
Figure: Use corridor conversations to prevent nasty surprises

The hallway is your friend. It's a place where you can gather a lot of information informally.

While the information collected and the conclusions of the Spec Review are presented formally at the end of the Review, it is important that the consultants convey key points to the client as they emerge through the course of the Review. The formal presentation is NOT the time to be presenting new information to the client. Formal meetings can have a "Us vs Them" feel. Addressing key potential sticking points of budget and technology informally during the course of the Spec Review relieves the potential for unwelcome surprises during the Spec Review presentation. Canvassing the issues beforehand in casual 'corridor conversations' clears the decks for an agreement, rather than increasing the risk of heated discussions if you surprise a client at a formal meeting. For example, ask the client "building the cube will add around two months of development time, shall we leave this out of the current scope, or do you want it in?" Remember, no politician challenging for the leadership ever calls a vote before he or she knows the numbers; you too will avoid presenting a solution at a meeting if you aren't convinced the client is already agreeable. Through the course of the Spec Review the client will be aware of at least the following:

Estimates expressed in round numbers (or exact numbers for fixed price)

Each month for senior software consultants is generally tens of thousands of dollars. Squabbling over $500 here or there in the ballpark phase is a level of detail neither side can be confident of. Clients need to be realistic about what they get for their money.

"Now that we've spent a few days speccing this out, we believe the solution will take approximately 6 months which is $204,000+GST"

Bad Example - Far too firm a price when you don't know any of the detail

"Now that we've spent a few days speccing this out, our projection is the project will take a minimum of 6 man-months (around $200,000+GST) to complete but this may change depending on what is finally agreed in the Specification. The price will vary depending on resources used and the time that elapses over testing.

Good Example - leaves some wriggle room at these initial phases

Read When do you use approximate values for project costs?

Technology options

At this stage, you want to consider the most relevant technologies. For example, SSW will likely pursue recent Microsoft technologies. Some clients might want to do their own research or need some time to think about their options before agreeing to newer technologies.


You should follow Rules to Better Proposals when documenting a Specification Review.

Test Please

The Consultant must run a test please by another developer and your Account Manager before anything is formally presented to the client.

Example Schedule for a 1-day Specification Review

You want to have all the required work for a spec review done within the allocated time, so it’s important you leave time to implement the required changes after you present and before you email the final version.

  • 9 am: Meet with the client and discuss requirements
  • 11 am: Start work on the backlog and the PPT or Word Doc
  • 3 pm: Present to the client and gather feedback for changes
  • 5 pm: Implement changes
  • 6 pm: Send “As per our conversation” with Word or PPT attachment

In a 2 or 3-day spec review, you should assume you’ll need more time to implement changes, so push the presentation time forward to 2 pm.

Adam CoganAdam Cogan
Ulysses MaclarenUlysses Maclaren
Cameron ShawCameron Shaw
Eric PhanEric Phan
Edgar RochaEdgar Rocha

We open source. This page is on GitHub