A university is building an online portal for students and staff. The contractor says it can deliver the requested features, while university departments expect the portal to support their day-to-day work. But do both sides mean the same thing by “the requested features”?
That question brought to mind a real project: the University of Vienna’s student service portal. The university started the project in 2012 with an outside contractor. A published case study reports that the project’s scope remained unclear, acceptance tests failed, and the university stopped the work after two years before restarting with a different approach. University of Vienna case study
TThe example below is my own illustration inspired by reading that case study. It does not describe the university’s risk assessment or suggest what its team did.
First, describe what could happen
A vague concern might be: “The requirements could be unclear.”
A more useful risk statement explains what might happen and why it matters:
If university staff and the contractor understand a requirement differently, the team could build a feature that users reject, leading to rework and delay.
Now the team has something specific to discuss and investigate.
Ask two questions
To decide how much attention this risk needs, the team asks:
How likely is this to happen?
Are different departments asking for different things? Are important decisions still open? Has the contractor shown that it understands how staff and students will use the portal?
What would the impact be if it did?
Would the team need to redo a small feature, or could the mismatch affect important parts of the portal and delay the launch? Would the problem be easy to fix now but costly to fix later?
These questions help the team compare risks. A disagreement caught during an early review may be manageable. The same disagreement discovered after months of development could mean much more rework.
Look for warning signs
The team can watch for signs that the risk is growing:
- People give conflicting answers about what a feature should do.
- Important decisions stay unresolved while development continues.
- Demonstrations lead to repeated changes or rework.
- Users say a feature does not support the task they need to complete.
These are risk triggers: signs that the team should investigate or take action.
Choose a response
If the risk needs attention, the team chooses a risk response. For example, it could:
- Agree on priorities and clear acceptance criteria before development.
- Show working features to users regularly, so misunderstandings surface early.
- Delay a feature until its purpose is clear.
- Accept a minor unresolved issue if fixing it now would cost more than the likely consequences, while continuing to monitor it.
A named risk owner should follow up on the chosen response. For instance, a product lead could organize reviews with the right university staff and track decisions that are still open.
Check whether the response is working
Risk management continues throughout the project. After a review, the team checks: Do users agree that the feature meets the need? Are disagreements decreasing? Is rework becoming less frequent?
If problems continue, the team may need a different response. Even after taking action, some residual risk remains. The team should understand what uncertainty is left and decide whether it is acceptable to proceed.
The practical lesson
Risk assessment is a way to make a concern specific enough to act on:
- Describe what might happen and what it could affect.
- Ask how likely it seems and what the consequences could be.
- Watch for warning signs.
- Choose a response, assign an owner, and check whether it helps.
That turns a vague concern into a decision the project team can act on.