Before starting any custom application project, we sit down with all stakeholders for a Strategy Session. The goal here is in part to educate clients on better ways to approach their projects. Often they are already too far ahead, looking at technical specifications and deciding on development matters, without first settling their project requirements. This leads them to being too focussed on technical details instead of the big picture, i.e. the real goals of the solution.
The first part of the strategy session is about listening to each stakeholder give their insights and requests for the platform. This helps us gain a general idea of which stage they are in and where we need to educate or provide new ideas.
Once we have a better understanding of the stakeholders and their project, we can start with a more structured approach to defining the goals and creating the solution around that. Broadly, the steps involved are:
- Identify pain points and bottlenecks in current workflows. If the client has existing, manual workflows in place, we want to get a better understanding of those and where they feel a lot of time is wasted.
- Establish the primary and secondary goals of the solution. This generally depends on the type of solution being proposed. For example, an ecommerce solution’s primary goal is typically to sell products. For an intranet, it could be to increase productivity.
- Discuss and design the ideal workflows for all users. Here, we identify the key activities of each user type and how can they go about this as efficiently as possible.
- Based on the workflows we can then establish the user requirements. These are not feature requirements but rather goals that each user wants to achieve. Each of these needs to have ROI, such as revenue or productivity increase. The user requirements should be about the human element and completely technology agnostic - thus in our Solution Architecture, we call them “User Stories” (read more here).
- Establish Non-functional requirements or NFRs. These are used to describe expectations of the system outside of the user goals, such as quality, security and scalability.
Going through these steps gives us the general scope of the solution. It gives us an idea of what the project needs to achieve and why.
But we don’t stop there. The strategy session is also about the business, and we want to identify potential opportunities and obstacles in the target market. For example, payments can be a challenge on the business side to certain solutions as hacking and data security is always a risk if the solution is storing valuable data.
Lastly, we want to identify the open questions that need researching. The goal is that when development starts there should be no open questions which may complicate or derail the process. As part of the strategy session, the items that need researching will be identified, but it will be during the solution architecture phase that the research is done and the answers found.
Research can include market research, to validate the concept or specific user requirements, or to gather new requirements that the stakeholders may not have considered. It could include business research, for example if there are conformity issues or data security and privacy implications. And it can include technical research, if third party technologies are required then these may need researching before the developer can be confident in the estimate.
Typically, most clients will have conducted some market research prior to the strategy session, to identify their idea’s viability and value in the market or internally in their business. Following the strategy session, the documented research questions and assumptions about user requirements need to be tested with actual users - a second round of detailed market/user research. This will ensure that each functionality has a specific business case and ROI, i.e. a business reason for this feature to be implemented.
At the end, the findings of the strategy session are documented in a format that is understandable to both technical and non-technical persons. Each stakeholder needs to be able to understand it, as it serves as an initial roadmap for their project, and it will also be shared with technical vendors to get an initial estimate of time and material cost.