Design Phase = Successful Project
In our last blog post Pitfalls of Connected Product Development, we covered the dangers customers can face at various stages of their IoT Journey. Being aware of the pitfalls is just the first step in avoiding them. A comprehensive project design phase can help eliminate them completely, before even one line of code is written.
We often get the question “Why should we engage in a design phase?” This usually masks the underlying question “Why do we separate the design phase instead of having it lumped into development?” In this post we will explore why having an individual design phase can help protect against risks like unexpected costs or delays, and why it is important to keep design separate from development.
What is a Design Phase
The design phase is the process where product stakeholders, the product owner, architects, designers, and developers work together to define the system at a level of detail in which developers can start. During this collaboration the team will build and refine user stories, clarify intention, identify and mitigate risk, document complex processes, architect the system to meet performance requirements and create a plan for maintaining the product throughout its lifespan.
User Stories
User stories are a fundamental element in software development, allowing developers to capture and document the features and functionality desired by users. User stories are written from the perspective of an end user and they provide a clear understanding of what needs to be built and why. By breaking down requirements into individual user stories, with each story describing a single piece of functionality, it becomes easier to track progress and prioritize features.
Clarifying Requirements
During the design phase, the team works together to understand and refine requirements. Do user stories exist? Do the user stories make sense and have value? Are they in conflict with each other? Are they achievable? Are there user stories that are missing? Why does the user need the story?
It is essential for the team to consider why these user stories exist. This understanding meets the heart of architectural choice decisions, such as databases or communication protocols, used by developers during implementation stages. As an example, determining if they should use a serverless architecture or WebSocks vs REST protocols.
Hazards of Unclear Requirements
When these requirements are not clear early on a project may be impacted in several negative ways such as:
- Increased likelihood of design changes: Without a clear design, developers may make assumptions leading to rework when reviewed by stakeholders.
- Decreased user satisfaction: When the software is not properly designed to meet user needs and expectations, it may not be usable or useful, which can result in decreased user satisfaction and adoption.
- Decreased collaboration: The design phase is an opportunity for stakeholders to collaborate and make important decisions about the software, which can be lost if the design phase is skipped.
Reducing Risk
One of the key benefits of the design phase is that it helps minimize risk. By carefully planning the software’s architecture and design in advance, developers can identify and address potential issues early on. This reduces the likelihood of costly and time-consuming rework further down the line. A “spike” is Identified when a team member identifies potential risk that could come up during development.
A spike could be as simple as a known problem that has multiple solutions, or as complex as integrating an unknown 3rd party component. Either way time is spent by the design team to “put a spike through it” (solve the issue) and document the solution so it can be estimated accurately.
When risk is not identified early the team may face problems during the development phase in the form of:
- Unplanned development costs: When a design is not properly established, the software development process may become more complex and time-consuming. This can increase development costs and reduce profitability.
- Architectural changes: When unknowns are not identified and clarified early, the project may need to change midstream. This leads to rewrites and time wasted on code that will never be used.
Building “The Right” Thing
A well-designed software system is more likely to meet the needs and expectations of its users. The design phase provides an opportunity for developers and stakeholders to collaborate and ensure that the software will meet its intended goals and objectives. As an example, it is not necessary to engineer a solution that would scale to 3 million users for an industrial manufacturing project that may have 100 customers with less than 1000 devices each.
If the team doesn’t understand the “Why” of user stories they may run into problems during product development and maintenance cycles in the form of:
- Reduced efficiency: When a design is not properly established, developers may spend more time investigating solutions and making changes to the code, which can slow down the overall development process and increase cost and the time to market.
- Difficulty in maintenance and scalability: When the design is not well thought out, the software may become difficult to maintain and scale, which can result in additional costs and challenges as the software evolves over time.
Determining Lifespan
Another benefit of the design phase is up front planning for the maintainability and scalability of the software. A well-designed system is easier to maintain, as it is structured in a way that makes sense and is easy to understand. It is also easier to scale, as the design makes it more simple to add new features or expand the system in the future. On the other side of the spectrum, a proof of concept project should focus on rapid experimentation – fail fast, learn and pivot – rather than long-term utility or robustness. A good design plan creates a scenario that leads to the desired outcome.
Does My Project Need a Design Phase?
Now that we understand the necessity of a design phase, we need to determine if it should be separate, or part of overall system design and development. Here are two different scenarios:
Scenario One
Customer A was provided a ROM for an IoT project of 500k to 1 million. Budget is approved, the team is kicked off, and they start on the design. Part way into the system design, the team encounters a technical hurdle, new requirements, and a performance requirement that had not been originally documented. In this scenario the approved budget is already at risk, and Customer A has to go back and get approval for additional funds or make cuts to the project.
Scenario Two
Customer B is provided a ROM for an IoT project of 500k to 1 million but are told that 75k of the estimate is to be spent up front in a separate design phase. After the design phase, a backlog is created and estimated. The 75k is approved by Customer B and the team begins work. During the design phase the team uncovers a technical hurdle, new requirements, and a performance requirement. The project is re-estimated at 1.5 to 2 million. The stakeholders now are able to make better informed decisions based on the new information. At this point, they could decide to break the project into phases over several years or to increase the budget to cover the difference.
These two scenarios may seem very similar. In both scenarios a design phase happens. In both scenarios there is scope identified. And in both scenarios the budget is adjusted. However the difference comes down to the interactions that happen between the stakeholders, the team and financial decision makers. In Scenario One, the interactions would generally devolve into finger pointing and placing blame. In Scenario Two, the stakeholders understand that the purpose of the design phase is to identify and mitigate risks early on. The team knows that at the end of the design phase there will be discussions of direction and budget.
Conclusion
A well-timed design phase gives stakeholders and team members the opportunity to analyze the project to understand what is being built and how to mitigate risks. Going through this phase allows for a realistic assessment of any changes necessary for budget, requirements, or timelines before development begins.
Executing a design phase answers the right questions with the right timing and will deliver the right product that meets user needs and expectations.
Written by Brendan Rabb, Technical Product Owner at SpinDance. He can be contacted at brendan.rabb@spindance.com.