The right foundation for the project is a critical factor when you plan to grow your customer base and scale the product in the future. Even if you’re starting with an MVP development – i.e. focus just on the core functionality instead of the full-blown project – the foundation you lay down in the very beginning will either save you from large expenses in the future or, vice versa, cost you a lot.
The goal of the inception phase is to clarify the scope, project objectives, and solution feasibility.
The client, business analysts, project managers, and developers get together to do the inception phase, which aims at working through the idea thoroughly, gathering requirements and expectations, assessing and identifying possible risks, and estimating the cost of the system development. It is different from simple project estimation because it involves a lot more research and for most of the projects, the inception phase costs around $5,000.
In this article, we’ll talk about the 7 steps of the Inception Phase we go through at HUSPI.
Is the inception phase necessary?
Considering the fact that the inception phase is around $5,000, you might ask “Why would I do that when I can just get a free estimation and go on with our development?”
Well, skipping the inception phase as a separate stage of development is an option 🙂 However, the main factor that you need to consider is the granularity of your idea and the scale of your project.
- If you come to us with just an idea of, for example, “I want a 3D design platform” and nothing else, you will need an inception phase so we all are on the same page about what exactly is required and how best to do it. We also determine the scale of the project at this stage.
- If you come to us with the clearly defined and described concept, then it takes less time before the development starts.
- If it’s a simple mobile app with few features, for example, and you know what you want, chances are you don’t need a full inception phase. (But it’s our advice to discuss this issue with the project manager because what you think as a small task might be actually a large one.)
- If your project is a large interconnected system that has to integrate with many services and has a lot of functionality – investing into an inception phase would save a lot of money for you in the long run.
Inception phase steps
During the inception phase at HUSPI we focus on 7 major parts, which we’ll talk about below in greater detail:
- Stakeholder needs
- Wireframes and high-level architecture
- Solution requirements
- System scope
- Iteration planning
- Cost estimation
Define stakeholder needs
Stakeholders are the people or groups of people who must be satisfied by the project and this may include anyone who is (or potentially will be) materially affected by the project’s success or failure. Most of the time, stakeholders for us are the clients that approach us with the initial idea.
As we mentioned above, the main reason for the inception phase is to clarify the idea and describe it in processes and features, so that it becomes more “solidified” in terms of its scope, boundaries, features, users, etc.
There are many ways to define stakeholders needs:
- Creating user stories to see the user journey and identify goals and gaps.
- Hosting brainstorming sessions to let everyone speak. You can stumble upon a feature or a constraint you’ve never considered before just because the creativity finally had a field day.
- Building process diagrams to go through the algorithms of the app or system’s work.
And wield the children’s most powerful weapon: the question “Why?” Sometimes things might seem obvious to you, but you have to make sure these things make sense to the people who will be using the system. Also, this would help to streamline the processes because you’ll be able to either remove the unnecessary stuff or know the exact purpose of the ones that remain.
Develop wireframes and high-level architecture
The project’s architecture ensures that the foundation is ready for scaling the operations. High-level architecture helps to show the overview of the system and its components.
The wireframes’ objective is to illustrate the components and the users’ journeys.
Define the requirements for the solution
During the brainstorming sessions and other meetings with the stakeholders, there will be a lot of features you will come up with. Now is the time to weed out the features that might not bring a lot of value to and distract the users from the main business goal. Another reason to reduce the number of features and define the requirements is to avoid so-called “feature creep.”
Feature creep is a term that describes the situation when the app or web solution have so many features that users are not sure what is the main goal of the software and what are they supposed to do. This doesn't mean the features are bad per se, but their amount or the badly thought-through user journey leads to user loss.
How do we define the requirements? There is a list of questions that can be used as a guide:
- How will you use this particular feature?
- What steps does the person need to take to use this feature? Where can the person find this feature?
- How can we meet this particular business need?
- Where does the process begin? What should happen before? What would happen next?
- How do we know this process/feature is complete?
- Who will use this feature?
- Who will provide the data for this feature?
- Who will get the data from this feature?
- What needs to be tracked and measured?
- Where will the data be visible? Who will have the access?
Besides these questions, consider brainstorming about the “What if…?” scenarios. What if… the person doesn’t have an Internet connection? What if… it rains? What if…?
Define the scope of the system
The scope can be a tricky notion because there are two scopes to talk about:
- Product Scope
- Project Scope
|Product Scope||Project Scope|
|The WHAT||The HOW|
|Functionality and features that make up the product.||Work that is required to deliver the product, service, or result with the features defined in the product scope.|
|Completion is measured according to the requirements.||Completion is measured according to the PM plan.|
Simply speaking, we need to decide what goes in or out.
Now that we have talked about the requirements, features, functionality, and everything else, we need to clearly define the scope in order to prepare for the next stage: planning.
Provide the basis for planning iterations
Iterations or sprints are a basic unit of development in Scrum. The length of the sprints is agreed upon and fixed in advance.
For example, at HUSPI, some of our project sprints are one or two weeks long. Such short periods allow to plan well and at the same time provide enough time to develop and test the features. Sprints shouldn’t be longer than one month because it will be hard to plan for such a long period of time. Two weeks is the most common iteration length.
To optimize sprint planning, it’s important to keep the backlog (the scope described in tasks and features) neat, organized and prioritized.
Each iteration begins with a sprint planning event (identifying goals and tasks for this particular period) and ends with a sprint review or demo (showing progress to stakeholders) and a retrospective (identifying lessons learned and improvements for the next planning sessions).
Provide the initial basis for schedule
The schedule is based on the project milestones (for example, features or a group of tasks) and looks like a timeline of what should be done when.
For example, you can use Gantt charts for the visualization of your tasks.
Provide cost estimation
Finally, when all the previous steps are done and everyone is on the same page as to what is expected, what is required, and when all of this should be done, we can prepare a detailed estimation for the project.
The inception phase is an important part of product creation when you start with a great idea and need to define it in business goals and development goals.
- You determine the vision, scope, and system users.
- You identify key features and requirements.
- You decide on the architecture and its feasibility.
- You get the schedule, risks, and costs associated with your product.
And with that, you’re ready for the next stage: the actual development of your product.