In the project initiation phase, project managers often encounter a bit of a dilemma. The pragmatic sponsor not only has the necessary budget, but often already has a concrete idea of the solution. However, this should actually only be worked out in the project. Good for the project manager who translates the given goals into a hierarchy.
Quo vadis, project manager?
In order to be able to say in a project where the journey is going, it is advisable to first define certain requirements, which the solution should fulfill. A number of these often already come from the sponsor. These can – but do not have to – include restrictions on time, budget and scope. These kinds of basic project goals (achieve X by deadline Y with a budget of Z) are partly binding, partly guidelines to define a rough direction.
In addition, there are numerous stakeholders from the project environment, be it executives from affected departments or members of the steering committee. These stakeholders often already have concrete ideas about what the project should achieve. This often revolves around time expectations or, for example, a specific country scope for international rollouts. Especially these colleagues will only be contradicted very carefully, but you should be careful to point out the consequences of a possible decision.
Last but not least, the project team – including you as the project manager – is loaded with expectations for the project outcome. These often revolve around the technical characteristics of the intended solution. Under no circumstances should the specifications be taken less seriously than those of the sponsor or the executives. After all, unity on this front later makes acceptance and motivation of the specialists much easier.
But what to do with all these ideas, wishes, specifications and hopes?
We have never done that before!
Optionally, of course, you can do nothing with them at all. As you can guess, this blog post would not exist – or would be much shorter – if that were my recommendation. If you neglect the requirements, you risk a whole bag of problems that can, in the worst case, break your project.
- Unclear objectives … it is not – or not for all – clear where the journey is fundamentally headed
- Poor quality … Requirements are poorly described in terms of quality
- High complexity … requirements are well described, but too complex for the set scope
- Changeable requirements … Changes of requirements happen unregulated (yes, scope creep, I’m looking at you!)
- Language barriers … the description of the requirement fits in terms of content, but not in terms of language
- Information loss … by unclean methods requirements or their parts are not completely represented
Order in the chaos
It doesn’t take much at all to address these points – a little organizational skill is enough for the vast majority of projects to align requirements with sufficient clarity. „Sufficiently clear“ because you always need to keep scale in mind: for a small, localized web project, you will choose the requirements definition (and possibly the entire project methodology) differently than for an international project with dozens of project members. A coordinated (1) documentation (2.) that is aligned in content and scope with the project size (3.) already saves many children from the well here. A clean change management (4.) and recurring reviews with the requirements (5., 6.) then do the rest.
It is generally recommended to collect the „wishes“ from the first section, evaluate them and turn them into requirements in coordination with the functional and administrative stakeholders. These then define the scope to be addressed in the project. This includes evaluating and prioritizing as well as discarding requirements because they may not meet other components of the project (time, budget, scope).
Depending on the customer, project complexity and PM method in the company, this can be done in a very structured way according to IEEE610, or very pragmatically with self-built Excel lists. However, please do not underestimate the importance of this step, because it is the measure of the project success, and also the acceptance by sponsor, managers and employees.
The categories you form are up to you. For example, is it exciting whether it is a functional, technical or legal requirement? Or is it more important that it represents a duty (must-have), a wish (if possible) or an intention (future need)? Coordinate with the sponsor and the team how far you want to go into detail.
Yes, and then?
With documented requirements, you have a powerful tool in hand for all subsequent project phases.
You go into solution design with an agreed-upon view of the target state. You can check every discussed process, every function, every technical solution for your mapping of the requirements. This way, you always know in the design if you are on the right track.
This, of course, benefits you during build and test. If you have agreed on all requirements beforehand, your implementers will have no problem implementing the solution design, and the testers will accept the built solution much faster.
Last but not least, this also applies to the employees after the go-live of your solution. By recording the requirements early on, you knew in advance what the areas involved were concerned with, and there are fewer if any unpleasant surprises after you have „delivered“.
As always, we wish you every success,
