The case for a better project brief.
In business, as in life, the number one source of stress and frustration comes from unmet expectations. It doesn’t matter as much whether we have high or low expectations, but more whether those expectations were met.
App developers and clients get very excited when looking at developing and implementing an app which improves processes, streamlines operations, or opens new areas of business. This can lead to both parties forging ahead on the project without laying a proper foundation to ensure the app’s successful implementation.
However, anyone implementing apps in an organisation for the first time might be surprised at how difficult it can sometimes be. I think that this is because apps in our personal lives are seamless to include in our lives and just as seamless to remove. We assume apps in business will also be as simple. However, business apps invariably interact with business workflows which make them more difficult to adopt. If apps aren’t adopted, there is usually far more negative implications for the business than when a personal app isn’t used.
The seeds of destruction and unmet expectations are usually sown early on and can be found in the technical aside i.e. how the app is solving the problem, or in the User-Adoption side i.e. how readily Users will adopt the app into their normal working practices. Don’t underestimate how much people resist change!
Both issues can be avoided by spending some time going through a series of questions to make sure each party understands what is expected of them. Clients and developers alike are entitled to certain expectations, and neither can succeed if the other fails.
You can use this checklist for each project as a way of documenting the expectations of each party. This serves two functions:
Clearly establishing the requirements of the app for both parties and;
Helping to identify when design requirements change which may impact on the original expectations. This almost always happens!
I strongly encourage both clients and app developers to insist that a document such as this is completed and agreed upon before embarking on any work. Even if one doesn’t have all the answers, you will at least know what it is that you don’t know.
I recommend getting the first version out as quickly as possible. App development, like any other creative process, is much better to collaborate on once there is something that can be looked at, buttons that can be pressed and visuals to be commented on. Until that point, the app will be abstract in everyone’s minds and it’s impossible to tell whether the same result is being visualised.
The remainder of this post elaborates on each aspect of the checklist.
What problem are you trying to solve?
What result do you expect to see when the app is rolled out and being used? What does a successful implementation look like?
A detailed description of the problem and what the client will consider a success is the most valuable but often-forgotten question.
Describe the current system being used.
What works? What doesn’t work? No business app works in isolation. Context matters. The app developer will need to use a lot of imagination to put themselves in the shoes of those using the app and those managing the business based on the results of the app.
The more information is at hand, the better the developer will be able to anticipate the needs of the business.
How many people will be using the app?
This has implications for subscription plans and how the app will be rolled out across the organization.
It’s assumed that ongoing support will likely be required. The developer can correctly price for this support when the number of users is known. As an example, the level of support needed for an app with 3 users is vastly different than for an app of 300 users. Contract agreements will need to reflect this.
How many User roles will there be?
Each role can be defined as a functional role of the user. For example, Managers, Technicians, and Administrators are 3 separate roles, because each is likely to need to access different information.
Keep the user roles to a minimum. The less roles there are, the less complicated the app/s will be and the easier and faster they can be developed, debugged, amended, and maintained.
Often, the Admin roles (and sometimes Manager roles) are better off being limited to viewing the spreadsheets directly, rather than as role within the app.
Have User Stories been completed for each role?
User stories are a useful way of clarifying what it expected that the user will be able to do with the app.
A user story will describe in as much detail as possible for each role, what a typical user will be able to do with the app and how they will use it. It can be written in either the first or third person, but I suggest writing it in the first person, as people seem to have a better chance at visualizing the required workflow properly when picturing themselves doing it. For example, say “I am technician Bob Smith. I when I start my workday I open my app to see my list of required jobs. I can see the currently, outstanding and completed jobs in one view.” and so on. Then the developer can ask “Well, what if there are hundreds of completed jobs?” Then it’s easier to identify that only X number of completed jobs should show. Or only the completed jobs from the last 7 days should be displayed.
What devices will they be using?
Android and iOS? Phones and tablets? Desktops? These are important considerations for the developer. Data is displayed in certain ways and the type of device it will be viewed on can have an impact on many design choices.
Will any users be using the app across devices? Multi-tenancy.
When a User uses an app across multiple devices, this is called multi-tenancy. For apps developed in AppSheet, multi-tenancy does not have as large an impact on the design as for other technologies. However, multi-tenancy may affect some ways in which data is collected, sorted, or represented.
What authentication method will be used?
This refers to the method which will be used to restrict access to the app. It is very important for the developer to know this upfront to set up their own environment to match.
Who is project managing from the client side?
Ideally someone with technical expertise regarding the problem at hand. It is also advised that the client provides the app developer with a single point of contact and a single designated authority who can sign off on changes to the app. Multiple points of contact often lead to chaos.
Has a dedicated test group been identified and briefed?
Select a dedicated test group who commit to providing timely feedback. This will catch a lot of bugs and workflow issues upfront, it may even prevent them from reaching the production phase entirely. The client project manager should brief the test group. Nothing is worse than the app developer having to create buy-in from the client’s staff.
Develop a roll-out plan and get commitment for system exclusivity.
For a large deployment, consider rolling out in phases. Each group that uses the solution should use the app exclusively. Running in parallel with the old system may result in Users not giving the new system the attention it requires, resulting in low user adoption and ultimately failure to implement the app. People often prefer using an old, familiar system whose flaws they understand than a better system whose flaws they don’t understand.