Before commencing a project we look for a project a s charter. But in case of a missing project we collaboratively work with the client to create a project charter to officially kick off the project work. When doing so, we evaluate the viability and feasibility of the project to assure it is under our wheelhouse.
Once the project charter is signed off, we start digging into the details of the project. We develop a common understanding among stakeholders on what the project is and what is about. Once we establish that, we go back and forth with the client in order to identify client’s actual intentions and required functionality of the application. This would allow us to develop more accurate artifacts that required to deliver a project successfully. Furthermore we check the viability of the project. If it’s going to be settled in a market with a low growth rate and about to conquer less market share in that segment, we’ll share our opinions with the client so he could take counter measures.
Once the both parties are established on the initial scope of the project, we provide two different estimates to consider. One contains the estimated cost, amount of time required and projected delivery dates for a solution with minimalistic features. The other estimate contains the costs, development time that would incur and possible delivery dates for a more comprehensive functionality of the scope. This would provide the client with options. They could go with the product with minimum functionality or the one with a more comprehensive functionality.
Assuming there is a finalised requirement spec, we identify every major module/section of the application. Then we further breakdown each module into manageable components (usually screen/page of an app). Then we dive down into each feature in a single page and estimate time for each feature. Usually these features are between 1 hour to 4 hours. These tasks end up in JIRA as backlog items. Any reusable code/classes/libraries are identified before and during this process and estimate them separately. This process is followed for each section and that constitutes the main body of the estimate. Few items get added to the estimate at the end. These additional items include UI finalisation (pixel perfection and UX)[fix number of hours depending on project size], Quality Assurance [30% of dev time], Contingency [20% of dev time], Deployment/app store submission [fix number of hours]. Contingency covers any erroneous estimates from us or any minor deviations of requirements by client while keeping the project cost static at the initial.
System architecture and design act like the foundation for the solution we build. Coming up with a suitable design & architecture would assure and enhance the robustness, scalability, security, performance, traceability and required third party integrations to perform without facing any showstoppers. Once we finalise the design and the architecture, it’ll be documented accordingly and shared with the client to get it signed off before proceeding to the next step of the project initiation.
Using storyboards, we provide the client with a high level screen navigation of the application to provide a picture of how the application would behave in terms of its functionality. Further we create wireframes which address every screen that is going to be implemented. They define the navigation from each UI to the other. Then we sign off them from the client to ensure the shared understanding between their expectations and how developers have conceive the idea of the application. Once the client signed off the wireframes, those would be used by our UI/UX designers to come up with different design concepts for the application.
We use scrum as a development model at Fidenz. We initially identifies what should be the optimum sprint length. This could range from 2-4 weeks depending on the size and the complexity of the project. Then we identify what high level features would be delivered in each sprint. Then we plan the intermediate sprint with great detail so that developers and quality assurance team could work based on the tasks created. Meantime, we identify individual resources who would be working on each task. Likewise we follow the same process at the end of each sprint until the product implementation is completed.