Spec Reviews are the first step to engaging properly with a client and need to be executed well. The following rules will ensure you know how, and how much, to spec out upfront.
Many teams start their implementation before dedicating time to understanding the primary purpose and functionality of the software. In some agile-leaning environments, the often simplistic user story is considered essential, contrasting with the detailing of all software functionality, which is viewed as "too waterfall." Garnering multiple perspectives from different stakeholders (both business and technical) during Spec Reviews is crucial for accurately capturing the intended function and behavior of the software.
Despite meticulous reviews, some aspects remain overlooked. The unknown 'unknowns' inevitably come to light as the work advances, making the estimation of knowledge work like software development (along with its testing phase) challenging. Risk emerges from the overlooked or unanticipated factors, even after thorough consideration. It's crucial to acknowledge that new insights will continually arise as we navigate through the development and testing phases—irrespective of the upfront thoroughness.
Tools like journey maps are a useful input into both development and testing, providing fertile ground for coming up with test ideas and identifying areas of risk to influence test coverage.
Having senior testers involved in this step can be valuable as they bring different skills and perspectives to the review, especially as they’re generally one of the few people in the team with a focus on what might go wrong (via a critical thinking mindset), rather than focusing on success (typical of the builder’s mindset).
Figure: Spec Reviews are the first proper client engagement
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.
Specification Reviews can be a long process and not having access to the relevant parties that hold the vision and the budget can create obstacles.
Critical stakeholders are people with a sound understanding of the business requirements and control over the budget. These stakeholders are rarely technical.
Getting accurate information from a client during a Spec Review ensures that the full scope of the project is captured and there are no surprises later on. Accurately refining the product avoids waste.
A client will often ask for more features than are really necessary for the MVP. They may also think that implementing a feature is easier than it is.
There are a few things you can do to control the scope of the project and deliver the client the most value.
When a Spec Review concludes, the journey towards project kickoff is only partially complete. For instance, imagine a scenario where the client had multiple questions and slight hesitations about the estimates provided during the Spec Review. Without a structured follow-up, these hesitations could evolve into concerns, possibly stalling the project before it even begins.
At the end of the Spec Review presentation with the client, work out a good time for the follow-up meeting and book it into their calendar immediately.
At the end of the Spec Review encourage the project to go ahead with the current resources, while it is fresh in their heads.
Say words to the effect of:
Spec Reviews are a vital part of architecting a new solution for a client, they are the plans upon which a new project is modeled. They serve as a key stage in the pre-sales process for software development consultancies as they create an opportunity for the developers to demonstrate expertise and provide immediate value to the client. For these reasons alone, it is evident that those who are assigned to carry out this exercise must be well-trained in the matter.
A User Journey Map (aka Customer Journey) is a visual aid that allows the clear communication of user needs.
These artifacts should be used at the beginning of a project during the early stages of research and design. This allows user requirements to properly inform design decisions made during development, and can help teams build a strong common understanding of a project.
Capturing feedback in a Journey Map during or even after development, can provide high value as well. Pain points discovered in this way can reveal opportunities or areas for immediate improvement.
Often when building systems it isn't super clear what all the nuts and bolts should be. The complexity of projects can vary quite a lot - and getting customers to tell us what they need is not easy. There might be several major stakeholders or domain experts each with slightly different ideas understanding that causes contention in how the system functions. Being a good consultant requires good listening and then good analytical skills to determine the customer's technical needs.
Event Storming is a fun collaborative modeling technique invented by Alberto Brandolini that enables members from different teams and disciplines to participate in workshops to learn how to break down complex business domains and processes.
Event storming is fun! Running a successful workshop requires preparation and understanding of the Event Storming process.
Every workshop has an Event Storming Master (aka Facilitator or Moderator) to guide participants through the workshop.
At your company, you never want to have a person asking "Where is that file?" The answer should be "The answer is Teams, the question is irrelevant".
Microsoft Teams is a great solution for organizing client files and conversations. Create a new Team for each of your clients, and if you have multiple projects for one client, use Channels to keep them separate. There's no need to create a new Team just for a new project.
Once you have this set up, it is likely that you want to have a link between your Teams instances and the associated CRM record.
per page
1 - 20 of 22 itemsper page
1 - 20 of 22 items