Rules to Better Specification Reviews

You would never build a house without getting an architect to create a plan first. Usually, a specification process is done with the client before beginning work on a project.

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.

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

Formal meetings can have a "Us vs Them" feel - 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.

The most important part of being in a Spec Review is adding value to the conversations. Your insights and feedback should contribute to improving the specifications, identifying potential issues, and suggesting enhancements. By actively engaging and sharing your expertise, you help ensure that the final product meets high standards of quality and functionality.

How do you make sure that your presence is adding value to the discussion and the product?

Even the most seasoned analysts might occasionally overlook certain details in a Specification Review. Leveraging technology, especially AI, not only augments our capabilities but also acts as a safety net for those unintentional oversights.

Estimates contain 2 main classes of work:

• Relating to the particular product (e.g. create page 'customers.aspx')
• Relating to the project as a whole (e.g. management, administration, testing, software audit etc.).

PBIs may only make up about 60% of the total project time. Project Managers and developers should not think that the only work being charged on a project are coding tasks.

How to create an estimate for a Spec Review (Summary)

This process can take up to a few days, so if you're just after a ballpark, use epics instead of PBIs (Product Backlog Items).

Here are the 8 steps:

The findings of the Spec Review should be presented by the developers and the Account Manager at a meeting with the key decision makers of the project for review and acceptance. It is important that all the required people are in a room together to review the plan. It is also valuable to record this meeting.

Different clients will have different levels of documentation on what they want to be built. You need to be ready to do a Spec Review for any one of the following possible cases:

Product Backlog Items (PBIs) can be described in the form of a "User Stories" when appropriate. It ensures the developers will know the context for a PBI.