So you’ve decided to create a new web app or mobile app and you’re now wondering how to give your new project the best possible start in life.
This should be your goal:
- Build a fantastic product that your end-users love and use.
- Do the above on time and within budget.
Unfortunately, it’s not!
In fact, 49% of IT projects fail and never provide a return on investment for the business owner.
Here’s what usually goes wrong with an app project:
- The app idea is created and stakeholders agree to the project.
- You build a team (or hire an external team).
- The team gets to work.
- They miss one deadline.
- The team continues to work.
- They miss further deadlines and the budget is growing.
- Some new features get added late in the process.
- The budget and timeline are looking increasingly depressing.
- And so on.
Luckily, it doesn’t have to be this way.
Here are 7 steps to start an app project that will greatly increase your odds of being able to release on time and within your original budget.
1. Create ONE project goal
An app project is usually part of a much larger scheme of things within your business or goals.
- Are you looking at raising capital?
- Are you looking to test your idea with a group of early-access users?
- Are you looking to create a feature-rich app all in one go?
It’s important that you consider what you actually want from the project and write down that goal to act as a guiding light of your project.
Here are some examples:
- Create functional prototypes in order to raise $1M venture capital.
- Create a minimum viable product in order to test and iterate your app idea with your ideal users by June 2018.
- Create an app that will allow your staff to streamline their invoicing process and reduce the time required for this task by a total of 200 hours per month.
The project goal will be different for every project and it’s crucial that you write down your project goal in order to unveil exactly what you’re trying to achieve during the project.
2. Create ONE product goal
Your product goal is the guiding light for everything that you do from this point onwards and is different from your project goal.
It’s useful to think of the project goal as the goal for your business and the product goal as the goal for the end users.
Let’s use one of the example goals above:
Create an app that will allow our staff to streamline their invoicing process and reduce the time required for this task by a total of 200 hours per month.
(APP NAME) enables our staff to invoice our customers in under 5 minutes.
How the product actually achieves the goal is something we can consider at a later time, but for now we simply want to frame your product goal in order to guide your actions and decisions moving forward.
When creating a product goal, there are a number of things to consider:
- What should a user feel as they’re using your app?
- How will your users lives be different after they use your app vs before they used it?
- How does your app move them from where they are now in their lives or work to where they want to be?
It’s crucial that this step isn’t skipped as it truly is a beacon for your project and it’s eventual success in the market.
3. How does the app achieve the product goal?
Now that we have a project goal and a product goal it’s time to decide at a high level how the app will achieve these.
This is where you’re effectively designing the user experience and user flows of the app from a high level.
At this point of your project, you should also start considering your budget and time frame requirements and ensure that you can reach your product goal with these constraints in mind.
Sketching and / or very large whiteboards are your best friends at this point as you collaborate with key stakeholders and ideally the end-users to establish how you’re going to achieve your product goal while also keeping the project goal in mind.
When designing the product at this resolution, you should work in a systematic way:
- What are the key actions required to achieve the product goal for the user? Don’t worry too much about the app itself at this point, just think about the practicalities of achieving the product goal.
- How could those key actions take place within a mobile or web app?
- How can we streamline those actions to reduce as much friction as possible?
- What can we automate or take away?
- What have we created or thought about that isn’t directly related to your product goal?
As a result of this process, you will ideally come away with low fidelity sketches of user-flows within your app.
These sketches should always be aligned with achieving the product goal and will be invaluable when it’s time for you to start defining the product requirements and creating higher resolution designs.
4. Create the product requirements
Now that your app has been designed at a high level in a way that clearly helps your end-users achieve their goals, it’s time to break down that design into a clear and easy to understand list of requirements.
You’re effectively distilling the app’s high level design into written features.
But first, let’s take a step back. Why are written product requirements so important?
- Accuracy of quoting from contractors and agencies (the more nebulous a project’s requirements are, the higher the risk that the contractor is taking on).
- They translate very well into tasks that designers and developers will use to create the project.
- They create a fixed scope of works that will enable your development team (internal or external) to manage and create.
- They allow you to create a project timeline and release dates.
Quite simply, product requirements are essential to reducing the risk that is inherent in software projects.
A great way to create product requirements is to write them out as user stories. User stories will map very well to your high-level design you created in step 3 and will be heavily used later in the project when your development team is creating the product user story by user story.
User stories should follow the following template:
As a (role), I want (feature), so that (benefit).
Here are some example user stories:
- As a staff member, I want to be able to quickly search for an existing client, so that I can invoice them quickly.
- As a staff member, I want to be able to quickly create a new client, so that I can invoice them quickly.
- As an admin user, I want to be see a graph showing the value of all unpaid invoices so that I can see how this affects cash flow.
- As a business client, I want to be able to pay my invoice by credit card or PayPal from the primary landing screen, so that I can pay as quickly as possible.
Each user story should be independent of other user stories, be aligned with your product goal, be estimable and testable.
It’s also incredibly important that each feature or user story is explicit and has enough context to ensure that the meaning and outcomes are as clear as possible.
You don’t want to have your development team constantly asking you what is meant by each user story!
5. Design the screens or pages at a higher resolution
Now that you’ve created goals, high level designs and user-flows and also the requirements for the project, it’s time to create the high resolution designs that will demonstrate what your app will look like.
It’s incredibly important to do this at the start of the project and not during the development phase.
It’s significantly cheaper to iterate and make design changes at this stage than it will be as the project progresses.
Your goal for this stage is to design the app interface in order to achieve your product goal and also reflect your desired business brand.
During this stage, your team should be:
- Designing each screen or page of your app.
Ensuring that those screens are always aligned with your product goal, not designed for the sake of design.
Tools such as Sketch or Invision can be used to transform the high resolution designs at this stage of your project into interactive prototypes which can kick-start the user feedback and iteration process or even be incredible leverage for fund-raising.
These designs and prototypes can also be incredibly useful to consultants or agencies that you’re reaching out to for quotes for your project. They will reduce the perceived risk inherent to your project and potentially get you a more accurate (and hopefully cheaper) quote.
The key goal of this stage of the project is to have designs for each screen of your app which have been approved by the project’s key stakeholders and the project should not proceed until this has been achieved.
6. Create a communication & release plan
We developers can be an introverted bunch so it’s important to ensure that all key stakeholders (product owner, development team and others) are all on the same page with both communication and release expectations during the creation phase.
If you’re using a team of developers that use an Agile methodology to manage the project, you should be receiving official updates from them at least every two weeks.
These updates should contain:
- What was achieved during the two weeks.
- Any learnings from that time.
- What they intend on working on during the next two weeks.
- When there will be a release that you can use / touch / feel.
These meetings are also a great time to discuss which new features should be priorities and also discuss how the project is tracking so far.
This system should be used whether you’re using an internal or external team, but will have to be adjusted slightly depending on a number of factors.
The key goal of this framework are these two points:
- You’re in touch with your development team often and:
- You have a clear understanding of when you will see the result of the work being done and can use / touch / test it.
Losing contact with developers is not an uncommon occurrence and is a key indicator that the project is probably not tracking the correct way.
The same is true for the second point.
Longer and longer periods between releases are a key indicator of a problem within the app project.
The ideal outcome of this stage of the project would be to have a communication / release plan document that has been agreed upon by all stakeholders and is actively used for the remainder of your project.
7. Trust the system, but get help if required
With the app project framework I’ve shared above, you’ve dramatically increased your chances of releasing your project on time and within budget.
You’ve reduced risk by:
- Designing your app with the project goals and product goals in mind and kept the end-user at the forefront throughout the whole process.
- Documenting the project requirements and sharing them with the key stakeholders in order to accurately quote and manage the work.
- Designing the app with the key goals in mind and getting stakeholder sign-off early in the project. This leaves very little to the imagination of the developers creating the product and allows design iterations to be made at the start of the project when it’s most cost and time effective to do so.
- Documenting a clear communication and release guideline for the key project stakeholders to maintain during the project. This ensures that you’re all on the same page with regards to deliverables.
But even with the above framework in place, some things can go wrong.
- Teams lack the technical ability to implement features.
- There are communication barriers between the product owner and the developers creating the product.
- Time frame and budget increases are consistently justified for seemingly legitimate reasons.
And so on.
So don’t be afraid to ask for external help if required.
In fact, the success of your project depends on it!
To successfully create an app within your time frame and budget, you need to create clarity and a system of success.
You also need to ensure you’re building a product with your end-user in mind!
By following the above steps you’ve covered both key points and have created a plan for success.
Best of luck with your app project and please reach out if you’d like my help along the way!