The key to establishing better requirements

Three keys for establishing requirements: Collecting knowledge, delegating responsibility and getting excited.

Problems when establishing requirements

Most IT projects start the same: with a mountain of documents that can only be moved between offices with a forklift, and where everyone already knows at first glance: This will take a while. IT workers are faced with a forest of information in the form of documents, process descriptions and training material from which requirements should be derived. Often, the most important thing is left out: People. The intended end user is not normally included in this document.

What then happens is repeated in a hundred projects every day: Users feel misunderstood, reject the system or the entire project, and the project goal becomes further and further away. But it would be easy to figure out and receive requirements where they arise. Namely, with the user. This can be done by taking the extreme step of talking to one another.

In 2012, I was partial project manager of a tool manufacturer’s IT project. My customer had carried out an IT project a few years earlier, and it could only be completed by reducing the quality and increasing the budget. The managing director and the IT workers figured out the crux of the matter later on in a lessons learned workshop. From a certain point in time, everyone was lacking an overview of the entire picture and no one knew that requirements were missing, which had to be improvised later at a great expense.

The business invested in software that the IT team could use to track, record and prioritize requirements for this new project.

The best software and project management approaches are only as good as the conversations that provide the information to be handled in the project. If the tracking software is only fed part of the requirements, then there is a period where only a part of the requirements is being processed. Even agile project management approaches are limited in their options, because although they give participants the option of reacting quickly to changes, they do not to tackle the implicit knowledge from the system.

I was shocked by the extent to which requirements were overlooked in the development phase. There was no communication. Again, the business was at a point where missing requirements left them having to catch up.

I got more and more into the role as mediator between IT and the department to prevent further losses. And I recognized where screws had to be turned to enable communication between participants.

Colleagues become requirement heroes

Even today, it is the custom that IT creates requirements, normally as a seemingly endless mountain of documents.

It also showed many aspects where it makes sense to not only have closely connect the department with IT early on, but also to strive for ongoing cooperation. Both areas can learn from each other and gain an understanding of the restrictions to the work of the other. That way all parties can support change management activities, which is the basis of clear and bidirectional communication.

Quickly, two colleagues from the department were found who wanted to work more closely with IT. Over the course of the first days, there was often a big surprise when preconceived opinions or images had to be revised.

The name “requirements heroes” came up during the development process and was concocted by an IT colleague. The team liked the name so much that they adopted it.

The user, the unknown being

Old systems still serve as the first source for requirements, documentation, process descriptions or training material.

If the requirements are requested by users who know the processes in the end and what really happens in each organization, have adapted them to their working methods, the scope of the requirements is not only more complete, the users can also be directly included in the process. If they transfer responsibility for “their” requirements, then they are ready to deal with the entire system.

The colleagues involved were on fire, because they noticed their work really making a difference. They became exclusive stakeholders for their own requirements, were informed about changes and could see the current state in an openly available version of the product requirements document, and later the functional specification.

My customer even exceeded this by allowing the some key features of the system to be tested by the users who gave the requirements for them.

Presentations, meetings and workshops

A meeting is put on quickly; indeed the stakeholders are often tortured with presentations far too often, that come from PowerPoint hell and turn into deserts of screenshots and text.

A lot more than a trusty lecture is needed to make sure the participants in meetings and workshops are not only physically present, but also participating mentally. For starters, dividing the meeting into different classes like, for example, information and discussion meetings. Information meetings always take place if a group of stakeholders need to be informed of a fact, but a simple email is not enough. Discussion meetings go a step further and allow the fact to be discussed. The participants can also be narrowed down depending on the type of meeting.

Generally, information should be transported as appealingly as possible, because only then can you really get into the heads of the participants. That can be anything, from a prepared flip chart, to a role play with the new system.

Once a week, we held a video conference with all the interested stakeholders. They were recorded and could later be watched online as a video in the intranet. The requirement heroes and the entire development team discussed questions and explained changes. As soon as it was possible, all questions and changes were shown live in the system.

After the first meetings that were held with live presentations, the requirements heroes became more comfortable and did role plays on important milestones like a yearly meeting where they demonstrate the use of the system. The stakeholders were impressed.

Summary

An extensive requirements search cannot be limited to documents. Each organization has its own rules and processes and to find these, you have to speak with the people there. Then everything will work out with just a little bit of translation between the different worlds of IT and the department.