How to apply “first things first” when developing and delivering digital solutions
Writen by Gwenola Michaud
The 80/20 rule, also known as the Pareto principle, indicates that about 80% of the consequences come from 20% of causes. The Pareto principle is a great model to keep in mind when prioritizing tasks and developing strategic plans. In the case of software or digital solution development, here are some examples of difficult scenarios that teams can face:
+ 80% of the development effort covers only 20% of the requirements needed by the business, leading to
delayed delivery and tension between users and development teams.
+ 80% of test cases cover only 20% of the features to test, leading to incomplete validation and inferior
quality of new features.
+ the majority of users use only 20% of the validated features upon roll out.
To maintain the pessimist point of view, these negative situations are not mutually exclusive. So, the key question to consider: how do we help teams to be more strategic in cases where the minimum development effort would cover the majority of the requirements, in alignment with business needs?
One way to put “first things first” is to focus on requirements, including requirement gathering, understanding, validation and their prioritization. Teams can’t design, develop and test all required features at
once. Requirements need to be gathered, documented and understood. In addition, they need to be prioritized regularly. This prioritization should be a fundamental and regular exercise where all stakeholders contribute in close cooperation. Customers/users and the wider development team (i.e., designers, developers, testers) collectively determine the potential value of a requirement, the cost to implement, and at what level of risk.
Users and development teams need to exchange information on requirement importance and cost/complexity in development and validation. It is difficult to adequately prioritize when evaluating only the business considerations, or only the development considerations. Furthermore, sometimes reevaluation needs to take place concurrently, based on the trade-offs between development cost estimates and business inputs. Users can and should be able to reevaluate feature importance, based on cost estimates and on the technical impact on the future architecture of the solution, if the feature or component is not implemented early in the project. Finally, users’ input during feature validation should be considered regularly. So, how do we do this?
Alignment between business considerations and overall solution design and evolution is essential to optimum development and needs to be completed on a regular basis, as suggested by Wieger (1999). Such a review should consider the potential value of the developments to the business, alongside the costs incurred and risk assumed in development. The merit in this method is that it considers all requirements together, from both business and technical points of view. It enables teams to identify the features and components to prioritize, based on relevance to business and feasibility in development. This prioritization of requirements needs to include all available requirements, all relative development costs and all risks, according to the following priority level:
Note that business relevance could be estimated considering the relative benefit and relative penalty.
Of course, this analysis may be tedious if the backlog includes hundreds of requirements. Some tough decisions may be needed to reduce the scope of requirements and to stagger the delivery plan into phases as a function of business needs and development capacity. Additionally, it can be difficult to understand how intermediate versions of a solution can and should be used in the interim, until delivery of the complete solution. However, the decision should consider the resource capacity alongside user expectations, to maintain the development team’s focus; delivering relevant solutions on time, within budget and meeting business expectations.
To tackle a complex system, a breakdown by element or component is required. The team’s focus is to develop according to priority. However, some resources should still be dedicated to clarifying and reviewing the integration of all components. In doing so, all stakeholders get a clear understanding of the complete solution under development. Dedicated communication and clarification of information should be encouraged throughout the process to ensure that any perceived complexity is acknowledged and teams are aligned on the overall development vision.
Teams should also review existing third-party components or available libraries which could remove the need for further development by building upon existing components. This approach requires a level of flexibility and certain capabilities within the team, such that the study and analysis of components
outside a given organization is possible. This role is rare, but so useful.
For any solution, it is fundamental to monitor user satisfaction level by ensuring feedback from the user validation phase is incorporated into lessons learnt and/or new requirements. Of course, any new requirement should be considered in conjunction with the existing requirements and/or those already added to the wish list. Without this information loop, the global development team risks working based on assumptions rather than gathered data, and drifting away from agreed business targets and user preferences. In this case, development satisfaction can be based on business relevance (common to the priority level), user satisfaction, or the actual cost of the development and validation phases:
In order to build in a considered and continuous manner that remains pertinent to the business, regular deployment is key. This enables teams to learn alongside users, take decisions based on priority and satisfaction level, and closely monitor relevance and progress during the entire development cycle.
Cooperation between teams is essential to continuous and regular delivery of solutions which address business objectives. Utilizing the feedback loop method when considering added requirements, where regular reviews and reprioritization is core practice, enables development and user teams to continually learn,
evolve and adapt solutions.
Would you like to contact me, don't hesitate to do so at the following email address:
GMichaud@GM-Consult.it
Acknowledgements:
Wiegers, K., 1999, First Things First, https://www.processimpact.com/articles/prioritizing.pdf
Photo from Austin Distel - Unsplash