This blog series will consist of 4 parts:
- High level process from receiving a lead to launching a mobile service
- Our development tools and processes
- User Centric Design, the DMI way
- Service Concept development
This first part describes our process from lead to delivery. We’ve simplified it by focusing on incoming leads but we also work actively on finding the type of customers we want to work with ourselves. The process may seem long and complicated but the first 3 steps can take as little as 2-3 days.
1. Incoming lead
We get 5-10 requests for proposals every day or about 1200-2400 requests every year. Out of these about 5-10% turn into business for us. Therefore qualifying and filtering incoming requests is of critical importance. This usually goes through 2 filters:
A. Lead qualification
Is this a serious request? Does the request fit with our offering? Do they understand the cost involved in hiring a top developer like DMI? Do we want to work with the organization?
Our lead qualification team usually send an email with follow-up questions including a brief template for more details. If the request is from a big company or existing contact that we trust then the request will usually go direct to (3).
B. Budget and scope qualification
If it passes the first filter then it usually means that we need to verify that the client has a reasonable budget for the scope requested. To assess this a sales manager provides a cost range based on our cost estimate tool or through a request to our technical team. Sometimes this includes a recommendation on simplifying or phasing the requested concept/scope to make the effort lead time for delivery more reasonable.
The final stage is putting together a proposal which may require anywhere from 4 hours to more than a month work with a team of 1 to 6 people depending on the complexity and size of the project. Therefore a conscious decision must be made whether to invest the time required or not and how much time before we start responding. About 20-25% of all requests get approved for the proposal stage. Sometimes the client knows exactly what they want and other times they have no idea. If the client doesn’t know what they want or only on a very high level then we usually propose a scoping and design project phase (see 6) before making a full formal proposal.
3. Client Approval and Project Start
Hurray, after months of hard work the client approved the proposal and wants to get started. It can take anywhere from 2 weeks to 6 months for a proposal to go through so sales need to have a lot of patience.
The project start request goes to our Start Request Meeting (SRM) that meets daily to review project starts and sale requests. SRM goes through a checklist including if scope is clear, budget is sufficient to cover resources, timeline is realistic, etc and if all is OK approves the project and assigns resources for Project Management, UX/UI Design, Development, QA and Operations. The approval process is sometimes split in a scoping & design phase and a development phase whereas there may be two approvals. Once the project is approved the delivery organisation takes over the ownership of the project from sales.
4. Scoping and Design
The scoping and design phase is required for most projects but can vary from a few days work to several months. This can include everything from customer research, service concept design, business case development, information architecture, wireframes, mock-ups, prototyping and user testing. The main objective is to come up with a scope and design that is sufficient for the development team to work on. Based on this the project manager can then come up with a project plan (including sprint plans) and detailed resource estimates.
5. Mature development
The scope is clear enough for delivery team and so finally the project is ready for development to start. This phase can take anywhere from 4 weeks for a short project to 6 months or more for a business critical solution.
Our agile methodology allows for a lot of flexibility in terms of changes to scope and design throughout development even when the budget is fixed. The best results are achieved when the service is tested by real customers during the development phase.
The team and process also depends on the number of workstreams. The simplest projects only consist of front-end app development or a mobile website whereas others include multiple front-ends (iOS, Android, Windows Phone, Responsive Design) and back-ends (Back-office, middleware, databases, content management, integration, etc).
Quality assurance starts from the first release from development and continues until the very end. We believe that QA for mobile is more critical than anywhere else. Customers simply expect your mobile apps to work. Therefore our minimum recommendation is to put half as much time into testing as development. e.g. For a project that takes 3 months for 2 people you need at least 60 work days of testing.
Read our blog post to know more about our QA process.
The project has been fully delivered and tested. It’s time for the client to give final approval. We walk through the user acceptance criteria with the client and assuming all is ok we can go ahead with the app upload or service launch. Once the project has been accepted, the responsibility is returned to the original sales person unless otherwise agreed.
8. Operations (Hosting and maintenance)
For any project that includes backend or middleware it’s essential to include operations as early as possible. We actually include operations from the first project approval meeting. The operations team leads the deployment and hosting planning and sets up the staging environment and the final production environment. When the project is accepted by the client an internal handover meeting between development and operations takes place to ensure everything is ready.
That’s it, from start to finish. Our process also shows that the development part, although very important, can be a fairly small part of an overall customer engagement.
Discover our other work processes:
- User Centred Design Process
- Coding standards
Image courtesy: Justin Mezzel