Preparing Your Project for Success
It’s time to look at bringing your app to life. The key is selecting the plan and team you trust to bring your app project success.
It’s paying off
The time and effort you have put in up to this point really start to pay off here. Knowing your market, what the users want, your business model, the technical challenges and opportunities based on your budget and timeline. They all meet up and the rubber is about to meet the road. You’re about to start your app build.
Everything you have done up to now will likely give you a good idea of who may be helping you do this and how you expect the plan to unfold. Here are some essentials and last minute pointers to help avoid any speed bumps.
As always, we’ve included some tips on the side like this for extra insight.
Your project contract
It’s strongly advisable to have a contract in place for the project. Projects that rush this stage almost always result in delays and backtracking. At it’s bare bones it should cover at least the following:
Time – Start/end dates and milestones therein. This is what deliverables from all parties will be committed to and accountable for.
When do you need the project to start and/or end? Are you going to be busy with anything else during that time which may impact the deliverables, development progress or associated communication?
Does this fit into the everyone’s scheduling? If not, it’s a non-starter.
Cost – Costs and deliverables associated with each milestone. Specific amounts on specific dates for specific deliverables.
What’s you budget? Is this available now? If not, when? Is your funding contingent on any time sensitive requirements or applications?
Is this in line with the quotes/costs you have received from each supplier? If not, better to know early and plan accordingly.
Quality – This has to be objective and agreed by all parties. It’s hard to nail but visual and functional requirements including detailed references is time well spent.
Is this your first build of the app? What are the benchmarks for functionality, aesthetics and general usability (etc.) within the marketplace?
It’s important all parties are in agreement over these expectations or it can lead to confusion – or even worse, disappointment.
Scope – Clear specification of the deliverables. Again these should be objective so there is as little room for misinterpretation as possible.
What are the deliverables? What’s happening now? What plans (or thoughts) are in place for the future of the app?
Knowing these and having them sufficiently brainstormed and documented is invaluable. It provides objectivity and shared understanding.
Important to note that our focus with regards to the contract is on the technical/management requirements as opposed to legal requirements. These should be advised by your lawyer.
What works for you
In Meeting an app developer, we touched on the importance of considering your working culture, schedules and habits are a suitable fit with others involved in the project. This factor has the most impact on your day-to-day experience of the development. Getting your expectations (and everyone else’s) set correctly can genuinely be the difference between a dream and a nightmare experience. Let’s start with communication.
Do you prefer frequent communication or a weekly update?
Do you prefer meetings, Skypes, calls or email?
Are you available 9am – 5pm? Might there be a time difference?
These simple things will have a surprisingly profound impact your satisfaction and productivity throughout the process. COnvey these expectations early to ensure your prospective developers (as well as any other stakeholders) are on the same page. If not it could lead to unexpected costs later down the line depending on the time factored into the costs you have received.
We recommend a middle ground. If communication is too frequent it can often cause confusion (if all documents aren’t synchronized and up to date), exhaustion (juggling constant communication while maintaining development progress) and likely delays. Ironically, too little communication has the same effect. It’s the project manager’s responsibility to make sure everyone has the information they need on the agreed channel(s) that work for everyone. This is a moving target as the communication for and between parties will change throughout the project milestones.
This is perhaps one of the hardest parts of setting up the project. Deliverables can appear simple and clear cut in early stages of projects. Techies do the software development, designers do the design, etc. The challenge is in the reality that these elements have to weave together – it’s in the details where gaps can occur. For instance, who’s dictating the sizes and formats of images or icons? There’s a fair argument for this to be the designers, developers or indeed you and your team.
You can never account for all of these scenarios. Some will emerge and need to be resolved as the project proceeds (where effective communication comes back in). We do however recommend you try to commit deliverables onto black and white in a way that looks past the high level (design, software, video content, etc.).
The easiest way to do this is to look across the pages of your prototype. You can also refer to your Requirements Specification Document (RSD) which is a document that usually accompanies the completion of your prototype and/or scoping phase.
The aim of our blog is to share our experience and advice in the hope it saves you time, hassle and money. We’re keen to hear your ideas for future posts so if you have any questions or requests please don’t hesitate to get in touch. Thank you!
At Ngage, we’ve had the pleasure of developing apps for amazing organisations and entrepreneurs from around the world. From prototypes for aspiring start-ups seeking user validation to an enterprise app being gathering input for international projects spanning continents. So what have we learnt so far? More importantly, how can we use it to help you?