Scheduling app projects
I’ve worked on too many projects to not have learnt the importance of careful and realistic scheduling. Early on in discussions with a client it is vital to spend time working out when a project can be delivered. If a client has unrealistic expectations and is unwilling to collaborate on an achievable schedule it is better to part company rather than risk disapppointment and frustration later on.
A project schedule should be a living document, frequently reviewed and updated. Even where the requirements list is small and well defined the schedule may still require changes.
One of the first things to do is to look at who is going to be involved in bringing an app to the App Store or Google Play. Let’s say you want a to create an app for your chain of book stores. It is to be for an app based book group. Here is a possible list of the people or roles which need to be involved:
- The person or team who are going to be leading the project in the book stores.
- The team who will help define what the app will do, how it will work, architect the app, write the code, internally test and quality check the app, work with the client and/or beta testers with alpha/beta/release candidate builds, release the app, maintain and enhance the app once released. You may be working with one person who will do all of this, or for larger projects with a team comprised of architects, developers, testers.
- The developer or team of developers who will provide the web service for the app. This may be a smaller or bigger task than the development of the mobile app code itself. It is important early on to understand if your app project will need a web service.
- The UI/UX designer(s) who will work with you and the developer to come up with a look and feel for the app, structure and detailed visuals.
- Stakeholders within your organisation who will want to have an input on the app. They may not want to get involved until there is something to see, will probably be involved in sign off, or may need to be consulted at every step in the process. The number of stakeholders may grow as the app develops and gets closer to completion.
- External beta testers and users who will want the app once released.
The more people/groups there are involved in the project the longer the app will take, even with the best project management. All of them need to be taken into account when coming up with the schedule. Time for feedback, especially early on and later on in the process must be incorporated. If you don’t then what you think might is a two month project can easily turn in 6 months and then a year.
Here is an example schedule for the book group app project (this could in the form of a Gantt chart). This assumes that the requirements for the app have been defined (i.e. user stories/what the app needs to do) - ideally in conjunction with the app and web service developers through some upfront consultancy.
- Week 1 - Wireframes for the app created by either the app developer (if this is a service they offer) or the UI designer (in conjunction with the client).
- Week 2 - Wireframes reviewed by app developer - particularly important if the UI designer hasn’t worked on many app projects before - and updated by the UI designer.
- Week 3 - Wireframes, maybe in the form of a tappable prototype using a service such as Invision, discussed in detail with the app team in the book store organisation and interested stakeholders.
- Week 4 - Wireframes updated and initial creative vision for the app shown (i.e. how the app could look, probably multiple options with different colour schemes, etc).
- Week 5 - Initial draft of specification written or set of user stories/epics refined. This will provide some needed detail for the app so that the app developer and web service developers can begin to form a better idea of how to architect and design the code. Client to review and feedback.
- Week 6 - Specification or user stories/epics updated and reviewed by the client.
- Week 7 - Specification signed off by the client or user stories/epics loosely organised into sprints.
- Week 7 - Technical documentation drafted so that the dependencies between the app and the web service are defined. This will allow the app developers and web service developers to work alongside each other and not hold each other up too much.
- Week 8 - App and web service development starts.
- Week 8 - Initial creative delivered so that development can start.
- Week 12 - Testing version of web service made live for app developer. Up until now the app developer will have been working with a mock version of the web service and now needs to start integrating with a live web service.
- Week 12 - Alpha of the app, using mock web service/data, available to stakeholders. The app team in the book stores will have seen builds prior to this if work is split into sprints.
- Week 13 - Feedback discussed and any impact on the schedule determined (e.g. the way something in the app works gets lots of negative comments).
- Week 15 - Initial beta of app which is functionally complete but may have a number of known issues.
- Week 17 - Feedback on beta collated and any impact on the schedule determined.
- Week 17-19 - issues fixed and app refined, maybe with further beta builds issues.
- Week 20 - Release candidate of app made available.
- Week 20 - Client provides App Store metadata and details of screenshots to use.
- Week 21 - Client signs off release candidate and is submitted to the App Store.
- Week 22 - App has been approved and is soft launched.
- Week 23/24 - If soft launch went well then PR can start and app properly launched.
- Week 23+ - Continued maintenance and improvement of app.
If you are working with teams of people from different companies (i.e. one company providing the UI/UX creative, another the mobile app development, another the web service) someone will need to be in control of whether or not deadlines are being met. Ideally this will be a project manager internally to your organisation who can provide oversight. As you can see above there are a number of inter-dependencies between the different teams involved in the project, if one part (for example the web service slips or creative isn’t delivered on time) then the release date will probably need to move.
Projects of any kind require careful planning and continued management. The complexities of managing an app project shouldn’t be underestimated and its important to make sure all parties are onboard and kept updated as progress is made. Apps On The Move can work with you to determine a schedule which will keep everything on track and enable your app to be released on time.