Daily project work prioritization: focus on real business value

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

 

Why is this so?

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.

 

Issues with prioritization

Usually they don’t happen right at the beginning of the project, but in the course of the project the following are often encountered:

  • Clients demand long-term technical commitments, insist on fixed release schedules and meticulously monitor their adherence to them, without any flexibility for any requirement changes.
  • The parties involved make a commitment to succeed with the long-term plan and place planning process above the business value of the project.

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.

 

Correct prioritization

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

 

Different roles = different priorities?

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:

  • Business Owner is responsible for the resources, money, and time.
  • Competency Departments are responsible for professional application of every project.
  • Development Teams are responsible for the project’s development and implementation.
  • Product Owner is responsible for the work of the development team and maximizing business value.

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.

 

Reduce project risks with spikes

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:

  • Why? Something should be implemented, but it is unclear what.
  • What for? To build understanding, identify ambiguities, and uncover unknowns.
  • How? Temporarily within a defined time frame.
  • Result: Reliable assessment and a better understanding of the requirement.

There are different uses of spikes:

  • The technical spike is used to explore different approaches to a solution within a project. Making a build-vs-buy decision, evaluating the potential performance or load impact of a new user story, or evaluating specific implementation technologies.
  • The functional spike is used when there is considerable uncertainty about how a user might interact with a system. Functional spikes can often be evaluated through prototyping, whether it is user interface mockups, wireframes, pageflows, or other techniques that are best suited to obtain feedback from other stakeholders.

How to Choose the Right Salesforce Partner for Your Company

 

Implications for stakeholders

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

  • Responsible for resources and the value generated
  • Decides on developments and future plans
  • Needs feedback from the project in order to make wise decisions in short cycles
  • Justifies the project status to the shareholders
  • Runs the risk of prioritizing quickly visible intermediate results in order to report progress
  • Must have confidence in the team without being able to foresee the full implications of each decision with certainty
  • Has to accept setbacks and changed requirements in the course of the project and bring a positive error culture into the team

Competency Departments

  • Support the definition of the common understanding of the technical content and its correctness
  • Ensure capacities are planned for the long term to avoid all available resources being exhausted right after  the start of the project
  • Make decisions regarding questions about details that may inhibit the flexibility of the development team in finding solutions
  • Pursue their own departmental goals which do not always correspond to the project focus
  • Want to participate fully in projects and solve problems by giving their professional input

Product owner

  • Support the clients, report the status, and ensure that everyone is aware of plan changes due to unspecified requirements
  • Is often confronted with a large number of stakeholders who bring in their own ideas regarding the need to drive the project forward
  • Is the Single Point of Truth for all project participants
  • Must set priorities and focus development on what creates business value
  • Has the best ability to deliver real benefits early and continuously

Development teams

  • Work and make decisions independently, while taking responsibility for their decisions
  • Must frequently re-prioritize when requirements change
  • Warn about obstacles to implementation and recommend alternatives that fit the scope
  • Deliver the output needed for project progress that is visible to stakeholders

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.

 

Conclusion

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.

Start a conversation
We’d like to hear from you. Use the contact form below and we’ll get back to you shortly.
Back to overview