Avenga’s response to the war on Ukraine: Business Continuity and Humanitarian Aid
The Avenga Team
Table of content
Felix Sahm – Senior Project Manager Judith Erb -Team Lead Digital Strategy Julia Eberhard – Digital Strategy Consultant
In complex projects with a corresponding costly framework, it is important for everyone involved to always focus on the elements in the scope that have the highest business value for the client. In other words, tasks that enable direct sales to the end users and thus help to use and justify the budget in the most optimal way. However, many companies, and even some of their service providers, do not always succeed in doing this. In their daily work, elements are regularly in the foreground only because they are already specified in detail and prepared for implementation, regardless of their actual business value. As a result, many ‘valuable user stories’ with a clear ROI for the client do not receive the appropriate priority, or they even remain unedited for a long time. This results in project progress that reflects a lower business value than required.
In this article we will reveal to you what the causes are and how project teams can maintain the right focus, even with complex projects.
→ SAFE: Digital Transformation with speed and scale
Basic requirements are defined at a high level of abstraction at the beginning of the project, but after that often nothing happens for a long time. This gives the parties involved the important higher-level view of the big picture ‘vision’, but an implementation with specifically prioritized work packages migrates through the day-to-day business.
Moreover, some requirements change in the course of the project, which results in new priorities. This makes it difficult to maintain a common understanding among all the participants of the applicable requirements for the project.
A detailed description of every single requirement also matters. The closer the deployment date gets, the more detailed and clear the description must be so that the defined implementation stages are accurate.
And last but not least, there can be very different subjective assessments of when a requirement is adequately described.
The complete description of all current requirements and the ongoing maintenance of a common understanding of the relevant business values can therefore significantly facilitate the correct prioritization of individual work packages in the daily project work. This requires the support of all stakeholders in the project and a proper level of transparency.
Usually they don’t happen right at the beginning of the project, but in the course of the project the following are often encountered:
These problems can make it difficult to prioritize individual elements and to evaluate the associated stories in detail, and should therefore be clarified beforehand. Tackling something unspecified often leads to double development work, because the first results don’t meet the set expectations. This neither promotes adherence to a release plan nor the trust of the client.
If it is possible to draw up common and always up-to-date recommendations for prioritization, it helps to ensure that valuable development time is always used first for the important elements; i.e., those with the highest business value.
If a high business value is attributed to an element based upon recommendations, then the associated user stories should also be prioritized. This is true even if a story is not yet described in sufficient detail, because often only during the approach to the implementation are hidden obstacles revealed that impact completing the story. Thus, the early stage of development can become the basis for an important discussion of the requirements.
→ How to choose an outsourcing service provider
But who are these “participants“ who all have to play together in unity? Prioritization provokes tension between different roles within the team and sometimes causes competing goals:
Within the project, the product owners are of central importance: they discuss the requirements with the development team until a common understanding of the implementation of the expected effort is reached. If this is not possible, the requirements must be further refined.
A sensible approach is to ask the other stakeholders relevant questions and discover any unknown obstacles, or so-called “spikes“. A spike becomes necessary if the team does not have enough information or experience to make a realistic estimate of a requirement.
A spike is a limited assignment to analyze a specific problem or to collect specific information. The goal is to reduce uncertainties and thus project risks.
Spikes ask and answer questions in order to achieve the outcome of:
There are different uses of spikes:
→ How to Choose the Right Salesforce Partner for Your Company
If this approach with spikes is to be implemented consistently, all those involved in the project must be aware of the implications to their area of responsibility.
Business owner
Competency Departments
Product owner
Development teams
Once all stakeholders are aware of these implications for their work responsibilities, the scope is easier to maintain and ‘valuable user stories’ receive the appropriate priority.
In this way, you can work with your teams and service providers to regularly achieve project progress that reflects clearly visible business values for all relevant stakeholders. This benefits not only the business owners, but all roles within the project.
