Usually, the first question we get asked is for a ballpark figure for any project. Put simply, it's impossible to tell, and may not provide anything useful anyway. We wrote about this some time back.

Instead, we carry out a detailed discovery workshop, which serves a number of goals, one of which involves estimation and pricing. But there's way more benefits than just pricing. This post will outline what we do, and why it is useful to our clients.

The Process

The process consists of 3 parts. The discovery interview, the UX and process modelling, and the estimation and scoping.

Normally, we set aside 4-6 days of our time. Even at this point, we cannot give a specific time because every app project is different. We try to stress that time bounding this phase will not serve the client well - It's best to consider it finished when the level of detail is enough and the detail is considered correct by both ourselves and the client. It's far better to do one more iteration if it will improve the deliverables rather than saying "we've reached our time budget", So, while a typical discovery can be 4-6 days, we stress that it should take "as long as necessary". Don't worry - there are multiple check-in points along the way so it won't get out of hand.

Discovery Interview
We find we need the client for the first half to full day of the process. This usually takes place at our office, but can be at the client's office. We prefer ours, because it leaves less opportunity for the client to be distracted. This initial process takes the part of an interview and sounds deceptively simple; but we glean a lot here. We take notes, and mind maps and review them at the end of the interview. The conversation is based around 3 simple questions:

  1. Who is your project aimed at?
  2. What is a successful outcome at this stage of your project?
  3. What are the business problems to be solved?

Drilling into these:

Who is your project aimed at? We ask this because this informs our design thinking. An app aimed at children for example, will have a different approach than one aimed at, say a bank's customers.

What is a successful outcome at this stage of your project? This question relates to where the customer is in their project journey. It speaks a little to ambition, but also helps us frame the project a little. For example; some projects are early stage and the discovery is all about costing, and some form of internal selling (e.g. internally in a company, or to a VC); other projects may have budgetary approval and this is the beginning of the project process. It's useful for both of us to understand where we are at.

What are the business problems to be solved? At this point, we're getting into the meat of the project. This is sometimes asked as "What do you want your end users to be able to achieve?" This is where we start to think about the features to be developed. You'll note that we try to keep this quite high level. We're focused on the "What" part of the conversation, as we will take this and turn it into the "how" during the next part of the workshop. We will at this point drill into some detail. If a customer mentions "we want to be able to log in", we'll try to understand how the user signs up, is it is username, or an e-mail, and other such details. We do this with each of the identified business problems.

Two other things happen during the discovery interview

  1. We think about data. Data is important in a mobile app. Some data may be embedded in an app. Some data may be obtained and cached locally, some data is only correct if it current; so we ask about immediacy of data, its importance and so forth.
  2. We act as the champion of the end-user. Sometimes a client may be focused on what's best for the business. We try to focus on what's best for the user. In ideal circumstances, these will be the same, but we find the end-user needs to be represented here. It sometimes leads to questions about "why do you want this feature?" or "as a user, I don't want that feature". We do this in the best interest of the project. So we advise clients to be prepared to be challenged.

UX And Process Modelling
The next step is the process is to model the app. Here, we develop outline diagrams called wire-frames which address how the user will achieve all of the tasks the client wishes. In our wire-frame development we consider empty states (such as when the app is opened for the first time), error states (how the app handles problems) and normal "Happy" paths. This takes a number of days to develop and we get into a process of iteration with the client.

We develop a version 1 of the wire-frames, give them to the client and solicit their feedback. We take there feedback and produce a version 2, supply this to the client and solicit their feedback. This process continues for as many versions of the wire frame as are necessary. We find 3 versions is not unusual; it can be more, it can be less. Each version typically takes less effort than the previous one as collectively we are always moving closer to the agreed functionality.

At some point along the way, the client agrees "This is what we want", and we can then begin the next part of the process, estimation and scoping

Estimation and Scoping
With the detail now in place, we can begin an estimation process. This involves considering each screen and putting an estimated time effort to develop the screen. We consider APIs the app may need to communicate with it; they may already exist, or being developed by the client, or are something the client wishes us to develop. We consider any work that may be necessary to utilise different modules (such as camera, GPS, etc.). We layer onto the plan the need for QA, and Project Management, and we consider the need for iOS, Android, Back End work and so forth.

From this we produce a detailed list of tasks necessary to develop the project. We add our rate card into the plan, and this produces an estimated cost.

With all projects, there are a number of factors that must be taken into account; Cost is obviously one, but the client also will typically have a want for a specific timeline, and a list of features that are "must-have" for release. The detailed task list now gives us all we need to help with the scoping exercise.

If the project estimates over budget, we have a number of things we can consider. The estimate is a good reflection of the ambition of the project. If the budget is less, it would suggest the the budget and ambition are mis-aligned. Similarly, if the timeline doesn't match the timeline the customer hopes for, then we can consider how best to resource the project, or re-examine the set of features that are required for launch; a phased approach, where a 1.0 release contains a cut-down feature set may be acceptable.

Regardless; with the facts in place, the client is now in a position to make educated decisions around their first release.

Deliverables

The output from our discovery workshop are:
1. Detailed wire-frames outlining the entire functionality of the project - This essentially acts as the blueprint for the software.
2. A detailed breakdown of the effort and cost to develop their project.

At the end of the workshop, all intellectual property then belongs to the client.

Some clients at this point in the process pay for a couple of extra days for us to produce Mock-Ups. Mock ups are graphic designs which show one or two screens in the app as if the app were completed. Whilst wire-frames are great for technical and functional people, they don't portray the vision for the project well; Mock-ups, which use the client's branding shows what the app may look like. We find that these are a very effective aid to selling the project concept - They appeal to Sales/Marketing and C-Level executives.

Benefits to the client

The process is necessary to get to the detail of a project - It takes the project from a collection of ideas into a more tangible concept and provides significant benefits to the client. We typically find:

  1. It helps identify potential problems to be solved that the client may not have considered.
  2. It brings clarity to each feature, beyond a basic idea and into proper detail.
  3. It helps focus on the important features, and gives the ability to discard the less needed features.
  4. It puts a realistic budget in place.
  5. It helps the client to start to "see" their vision, and scrutinise it with a level of detail they have not done yet.
  6. It moves the project along, producing useful project artefacts necessary for the build.

Summary

Estimating a software project is a complex task, and necessarily involves understanding of the detail of a project. When a client wants a ballpark figure, we feel we're doing them an injustice by trying to tell them something before we understand this detail. Instead, we carry out the above process; it brings our experience and expertise on building apps to bear on the process and adds the much needed clarity.

Thanks for reading the Tapadoo blog. We've been building iOS and Android Apps since 2009. If your business needs an App, or you want advice on anything mobile, please get in touch