Team building in requirements engineering
Not everyone who (has to) work in an IT project pursues the success of the project as their primary goal. Of course, nobody is happy if his team, individual colleagues or even himself are rationalised away, his tasks change or the work becomes more complicated. This is predictable. If you get into the power and intrigue of a client company as an external consultant and try to collect complete and correct requirements there, you have to be able to distinguish friend from foe and get the flea circus to become a team or at least to work together like a team for once.
You are probably familiar with the expression “herding a bag of fleas”. This is the image that every flea jumps off uncontrollably in a different direction. A team works more like a team pulling the heaviest carriage in the same direction, coordinated with each other in the same rhythm.
Unfortunately, as requirements engineers or consultants, we cannot physically tie down our contacts or even crack a whip. From a hierarchical point of view, we are often not the coachman, but only a horse. Rather, we have to tie them with invisible threads and align them to a common goal.
How does that work? The following principles must be observed:
- De-escalation and confidence: The coachman is responsible.
- Comprehend the situation, show understanding and then move on to the factual level.
- Find and proclaim common goals.
- The reins are kept tight.
- Carrot and stick.
De-escalation and confidence: the coachman is responsible
There is only one coachman per coach box and with good reason. If several people were to take the reins at the same time, the project members would be confused by contradictory statements. The disagreement of two requirements engineers or conflicts between requirements engineer and project manager cost unnecessary energy and can be exploited by malevolent stakeholders by playing them off against each other. Therefore, exactly one person is responsible for requirements engineering and thus for the project scope and change requests. This is especially true in difficult projects or a difficult environment. This person only wants one thing, namely to make progress with requirements engineering.
Ideally, the requirements engineer is not only responsible for the content of the requirements engineering work package, but also manages this work package independently. Since he or she has a clear idea of the procedure and the results to be achieved, he or she can – at worst at a snail’s pace – persistently and consistently follow the planned procedure. All side wars may slow down progress, but they can’t completely divert the project from its course. A clean requirements engineering approach is therefore a survival strategy, especially here.
The requirements engineer needs a lot of strength of character in difficult projects. Any weakness would be exploited immediately. If he is easily vulnerable, the project saboteurs will hurt him. It has always helped me to remember that the aggressions, even personal insults against me don’t really mean me at all, but that it is all about unwanted software, an unwelcome process change or internal disputes that poisoned the climate even before I came. This is how you keep yourself emotionally out of it.
Luckily, as an external consultant, you can look at the internal games at the customer from a distance. They do not threaten my existence, but they do threaten my project. And that’s what we have to fight for. Trust in the fact that even the worst opponent of the project cannot really afford to topple it all by himself and thus cause enormous financial damage to the employer. Never lose faith that there is a solution for everything. That’s why there is no reason for you to get emotional, fuel conflicts or be drawn to one side or the other. De-escalate, that is, try to smooth out project-related conflicts or keep them out of the project. Admitting your own mistakes and showing how you intend to iron them out is also part of this. You know where you want to go, and you align everything accordingly.
Comprehend the situation, show understanding and then move on to the factual level
To de-escalate and not accidentally say the wrong thing, you need to understand exactly what is being played, who is making deals with whom and competing against whom, who fears what. A colleague of mine once said quite cheerfully: “Thanks to the new way of working, everything here will go much faster. You’ll be able to go home early in the afternoon and have more free time.” This was supposed to motivate the employee to contribute to the project, but at that time we didn’t know that the employees feared such an increase in efficiency that some colleagues would have to stay at home completely in the future. The effective arguments depend on the situation. And you need to know them as well as possible.
The most important source of information about the interests and aversions of employees is a person (or even several) who benefits from the success of the project and has been working for the company for a long time. This should be the project manager responsible at the customer, who would be held responsible if the project failed. But also the project sponsor, an user or a secretary who is fed up with all the intrigue can provide valuable information. The most important sources have unexpectedly opened up to me so far. Often it was not the person I had been told to contact or the meeting where “stakeholder management” was on the agenda. Informal communication opportunities such as shared lunches, an after-work corridor discussion, a one-on-one meeting with a rather quiet but attentive team member played an important role. Often, those who did, turned to me of their own accord to help me. Probably the above mentioned (systematic work, confidence and de-escalation) brought me sympathy and trust. Both are necessary, because it is not easy for a member of the team to denounce a colleague of mine as a project saboteur or to warn me about someone. Absolute confidentiality is the prerequisite for this.
Many times I have already opened floodgates by a specific inquiry. I say something, see the unwillingness in the other person’s eyes and say: “Yes, I understand that you don’t like that. After all, it implies for you…” And then he’ll tell me whether I guessed right or not. Dissatisfied stakeholders like to vent. As the requirements engineer, why don’t you be the one who listens to these people? Especially the concerned and the project opponents are valuable sources of unofficial information, historical facts and possible project risks. And whatever you hear, they are not unsolvable problems, but the information can be constructively reformulated into software requirements.
Understanding the situation is one thing. But what do you do with this knowledge? To show understanding and empathy is a good strategy. You cannot simply ignore other people’s existential fears. Most fears are justified. Fortunately, some can be honestly dispelled.
Sometimes it is tricky to use confidential knowledge without revealing that you have it and where you got it from. For example, how can you justify checking information with a second source when the oh-so-committed key user has been chatting for hours? One must proceed discreetly.
Of course, you can’t please everybody. One wants green, the other red. Then you bring the issue to the table and let the people responsible at the customer’s site decide. It would be best if you could already suggest solutions and compromises. It is not the job of the requirements engineer to make decisions about the requirements, but it is very much the job of the requirements engineer to prepare, moderate and support such decisions. It is best to always stay on the functional level. Draw conclusions for requirements engineering from everything you hear and experience. No more and no less.
Find and proclaim common goals
Yes, different stakeholders pursue different goals. Some of them are not compatible with each other. But on an abstract, general level, you can still find common goals that you can swear the flea circus to. Do you like to remind us regularly: “We all want the XY to be introduced successfully. So let’s work together to figure out the best way to do it.”
The reins are kept tight
Keep control of everything if possible. Get involved in everything, ask lots of questions, tell others what you plan and want. The others must constantly feel that you are there and that you care. You should not miss anything, no meeting, no rumour, no dissatisfaction. Comment on everything. If necessary, insert appropriate clauses in contracts or agree rules with stakeholders, such as “every change request must be officially requested and approved by me”. The tighter your control, the earlier and more concretely you will discover attempted acts of sabotage.
Carrot and stick
Of course you are always nice and friendly to everyone. Good work is praised. But if things aren’t going well, you say so too. You clearly show the consequences of sloppy work and you like to calculate this in person days and Euros.
At one customer, where decision-making processes were not progressing and responsibility was often passed around like a Jackass, the contract expressly stated that decisions had to be made within 48 hours. Otherwise the delivery date will be postponed accordingly. In the end, this was just an empty threat, but I could quote the clause if necessary to speed things up.
Conclusion
Team building in requirements engineering is not easy. Of course, there is no blueprint or 10-point plan with which anyone can conjure up well-functioning teams. Even the above principles do not turn every bag of fleas into a team. But at least you manage to more or less put the fleas in front of your carts and get ahead! All you need are
- clear responsibilities and agreements,
- systematic work and interest in solutions,
- trust, discretion, sympathy and confidence,
- empathy and neutrality.
And a little experience probably won’t hurt either.
Notes:
In our t2informatik Blog you can find more articles from her, including
Agile requirements engineering
What prevents creativity in requirements analysis?
Misunderstandings in requirements engineering
Dr Andrea Herrmann
Dr Andrea Herrmann has been a freelance trainer and consultant for software engineering since 2012. She has more than 28 years of professional experience in practice and research.
Dr Herrmann was most recently a deputy professor at Dortmund University of Applied Sciences and Arts, she has published more than 100 specialist publications and regularly gives conference presentations. She is an official supporter of the IREB Board and co-author of the IREB syllabus and handbook for the CPRE Advanced Level Certification in Requirements Management.