Clients could be of different types and one can’t necessarily be a technical type of person. If client has a very abstract idea in head the initial aim is to get him or her talking and extract as much as possible business facts about solution.
For that we appoint a conversation where client tell us how solution has to work and obtain the initial technical consultation what platform or technology can handle his business idea and what the budget could be for the project. It is very informal talk where client describes his business, what he sells, how deliver it to customers, how payment flows go and what info he needs to extract from the system.
Further on this conversation can be transformed into the first and very important document called a Project Vision.
Based on the Project Vision project manager sometimes with the coordination with CTO is working out a technical solution. Technical solution means a platform, framework or plugin, which is decided and agreed to apply in the project to achieve the business purposes, which Project vision sets out before development team.
Later on Project Vision will be evolving into high level requirements, features and functions descriptions, user cases, mockups and become the main document to provide a preliminary loose time frames for the client. We can call it Project specification or a Project roadmap.
Needless to say that Project Roadmap is created very closely with the Client. Client adds requirements, describe the behavior of the functions, writes user cases. For better articulating requirement or feature client is free to use the following strategies:
- Referencing the analogical functionality on other site
- Visual presentation of the functionality in form of pictures, drawings or diagram
- Describing User case or User story. User case explains how user interacts with the system and how system should respond and what happens if user does anything wrong
- Creating a prototype using any existing Prototyping tool of client’s preference
Based on the Project roadmap and agreed Technical solution we are preparing a Release plan, which introduce the list of features or pieces of works (Integrations, design, etc) and preliminary deadline and timetable for each feature release if necessary.
Release plan is the document we share with Client and client is the one, who prioritize features.
Once the Release plan is confirmed with the Client a project manager forms his development team. The choice of the developer is dictated by its experience in a given field of expertize and selected Technical solution. If the solution requires drawing design, creating Look and Feel of the site a designer and frontend developer are assigned to be in the team.
The development team from now on will be working around the clock on iterations basis, where each iteration corresponds with the feature or piece of work confirmed in the Release plan.
Each feature requirements and user cases are transferred to the so called Backlog document, which also exists in Bug tracking and project management tools such as Jira, Trello, Asana or Redmine. Backlog document is the one, which approved by the client and in most cases made up by the client. It is a valuable and important document, which the team is entirely adhered to.
Thus the project is shaping with each iteration and client sees the progress and can touch the feature after preliminary release and comment and modify its functions and behaviors if necessary without slowing down development and remaking the whole system. It allows development team to keep track of deadlines and client to control progress and modify the solution in course of development.
What allows development team to keep on track and be on the same wave with the client?
- Daily sprint meetings of development team and project manager, where each team member reports what he has done so far and what predicaments he is facing or maybe improvements he can to invest in the development
- Weekly or bi-weekly calls, which client has with project manager and the team to discuss new ideas around the feature, modifications he needs to implement and how project progresses.
The average iteration has size from 1 to 3 weeks. When feature is finished on the staging server QA expert conducts tests based on User cases list associated with the feature.
After that feature code is transitioned to a client’s server or client runs UATs right on our company staging server and after acceptance the feature can be pushed to live server.
The similar tactic is used for design work. Development team puts out ready pages on the staging server for client to monitor progress of the work and once the design is in place it is transitioned to the QA and put further to the UATs.
The mentioned documents used on the project are kept in the Bug tracking system for further analysis, potential disputes and internal usage.