Secret ingredients to quality software


Meetings - Do you know the agenda for the initial meeting?

Created on 04 Sep 2012 | Last updated by Christian Morford-Waite on 26 Feb 2021 05:05 AM (about 2 months ago)

The first meeting is on you. While you have 1 - 2 hours to provide the prospective client with enough information to decide whether to pursue a Spec Review, the focus of the initial meeting is the client, their problem, and how you might build a solution.

The best way to action this is to ask questions, listen and take notes: Clients appreciate someone genuinely considering their needs. A brainstorming session is a fantastic way to give and receive feedback immediately. Even if the client decides not to use you, you should leave them with useful information and a positive impression.

The purpose of the initial meeting is to:

  • Listen - Understand the client's motivation for engaging software consultants. Clients 'want a software application built', but understanding the motivation for getting that software built will assist you in making a successful bid for the project. Three examples could be:
  • To replace an outdated, hard to maintain existing system that's core to the business.
  • Building new 'nice-to-have' functionality to allow the client to offer a new service to the market.
  • Assisting a start-up company with a speculative venture.
  • Listen - Understand the 'pain level' of the client
  • Listen - Determine whether scope, time, quality or cost has the highest priority for the client and what level of project management they require. E.g. if a project must be delivered by June 30, a high level of management will be required to ensure enough resources are supplied to achieve this
  • Listen - Understand as much as you can about the processes/business rules the system has to manage. Every level of detail you can correctly comprehend and confirm back builds your credibility as a good communicator and supplier!
  • Listen - Assess the overall scope of the project, i.e. is this a 'small', 'medium' or 'large' project. The attending Architect should start guessing how many man months this project might be. This information will help you assess how long the spec review should be. These initial thoughts should not be shared with the client at this stage as they are most likely incorrect.
  • Listen - Determine the client's budget and who controls that budget. E.g. Are you dealing with the business owner or a line manager in a corporation? Do they have a fixed amount to spend? Do they have a time period to spend it in?
  • Listen - Find out if this is the sort of project you can do and want to do
  • Listen - Qualify the client to make sure they can afford what they want
  • Consider technology options
  • Introduce your team, explain how our involvement can help them, and whether you have a 'good fit'
  • Explain your rates, including pre-paid
  • Explain the strengths and challenges of a Time and Materials or Fixed Price approach
  • Explain our Scrum development method including the importance of a Specification Review
  • Potentially explain their role as the Product Owner and show a bit of the Product Owner video
  • Take exceptional notes
  • Ask for the sale: "This project is right up our alley and we'd love to be involved, is there anything stopping you from scheduling a Specification Review?" This will focus the mind of the client on the next step
  • Leave a bit of marketing collateral behind. Branded Notepads or USB sticks are ideal.

Figure: Do you listen?

Adam CoganAdam Cogan
Ulysses MaclarenUlysses Maclaren

We open source. This page is on GitHub