In a recent project, my client consisted of the CEO and an engineer. The CEO’s vision was very abstract and I had to have multiple sessions with the engineer to elicit concrete and programmable requirements. The goal was to ensure that both of them were happy with the end results while minimizing the amount of rework needed by the developer. Here are some tips to ensure that the client and IT partner remain on the same page.
- Simplify Client requirements to 80/20 rule
- Less is more, try to get to efficient requirements that meet 80 % of the functionality and iterate to enhance
- When meeting with client, start with pencil and paper If I can draw it and follow the logic, then I can build it.
- Start with a diagram/Excel mockup of the app. What are the user inputs? What are calculations? What the are constants? What are the assumptions?
- Figuring out what the user inputs are reduces the complexity of the app.
- Let the developer decide technical decisions. Should the values be stored in a database or flat file? Tell the developer the environment they will have access to for example, is it a WordPress site with access to MySQL etc?
- Ask the client if the application will be used mostly on the web on a desktop/laptop versus iPad/mobile. Knowing this will help the developer to know where to focus most of the effort on design. For example, optimized for desktop/iPad and usable on mobile.
- Draw a wireframe if it helps. https://balsamiq.com Balsamiq has a trial product that’s very easy to use and export to a PDF.
- Use cases can help but are less used in Agile development
- If the client provides data in PDF, use a PDF to excel conversation tool from Adobe to provide to the developer as it will speed up things. There a free Adobe tool at https://acrobat.adobe.com/link/acrobat/pdf-to-excel
- When communicating ideas from the client to the IT developer, keep it simple take a screenshot and use an iPad and pencil to mark up the document for clarity. The goal is clear communication and reducing any surprises when demoing the product to the client.
- TEST, TEST, TEST, catching errors quickly and informing the developer can avoid a lot of rework and pain once the project is demoed to the client.
- Start demo of the product with happy path scenarios and then add in edge cases and error trapping after. This ensures only relevant work is done that moves the project forward.