In this blog post I want to discuss one of my favourite side projects during my PhD. In fact, I started to work on this topic in the German Special Interest Group Requirements Engineering and Project Management the same day I started my PhD (November 2005). Recently, Springer accepted our manuscript for publishing and we are proud that this work is finally available as a book. What a great conclusion of a wonderful year 2012!
In this post, I give a short overview, describe my role in the creation, and give a preview on some recommendations from the book. Finally, I share some experiences from the wonderful time we had during assembling this book.
Why did we write this book? Reports about failed projects are quiet common in the technical press. One of the major reasons is insufficient definition of requirements. Growing complexity of projects and dynamic environments make good requirements engineering and requirements management even more important: they grant competitive advantage by providing systematic decision support and by helping to shorten the time-to-market.
We decided to approach this topic from the perspective of project management. Specifically, we discuss the following question:
How can and how should requirements engineering and project management work together?
We discussed our practical experiences as project managers and requirements engineers in the group. We all agreed on the following facts:
- Requirements are crucial and critical, as they define the project course.
- Good requirements analysis is essential for defining the project goal.
- Good requirements management is necessary to keep the project on track.
- The project result cannot be better than its requirements quality.
While investigating the interplay of project management and requirements engineering we found that there exists a large body of literature on project management. Fewer works exist on requirements engineering and hardly anything has been published on the relationship of both disciplines, especially on the German market.
Therefore, we decided to write this book ourselves. We focused on giving suggestions for project managers from the perspective of requirements engineering and to highlight links between requirements engineering & management (RE&M) and project management in all areas of their daily work. In many areas we found the goals of RE&M and project management very conflicting, and one of our recommendations is to assign both tasks to different persons.
My role in this project
While we created this book, I matured from a newbie to something the EU refers to as a young researcher. In the beginning, I could only contribute literature research and similar work to the group, because I did not have a comparable background to my co-authors. During my PhD time I became project manager in a number of research projects (including development work for industry partners). I consequently applied the body of knowledge I learned from my co-authors. During that time I started to organize and moderate group meetings and was able to contribute to the group’s progress in this way. The value of my efforts is reflected in the fact that the group elected me to represent the project as one of the three editors. All in all, I contributed in the following ways:
- I (co-)authored three of the chapters in the book.
- As an editor, I established and managed the contact to our publisher (Springer).
- I negotiated the contract in the name of my fellow authors.
- I contributed to organizing and executing the internal quality assurance process.
- I organized, and in large parts did the formatting and editing of the manuscript.
As a postdoctoral fellow in Hannover, I based one half of my first own lecture on this work and received excellent feedback from my students.
As a preview of the content of the book, I share some of the recommendations we give to practitioners. In contrast to the book, I give recommendations for requirements engineers in this blog post:
RE&M is critical, even before the start of the project.
Requirements engineers should be aware that important requirements were most likely discussed, before the project officially started. Your project manager should have some of this information, but might not be aware about their importance. Try to figure out who participated in the discussions that lead to the project and where you can get more information (e.g. transcripts, slides).
Both, RE&M and project management deal with requirements, but the goals of these activities differ.
Project managers work with requirements all the time (e.g. they base their decisions on project goals). We think that for this reason project managers can benefit in their daily work from knowledge about methods and techniques of RE&M. Project managers and requirements engineers have different goals, though. For example, when faced with tight deadlines, project managers might assess the risk associated with a vague requirement different from the requirements engineer.
RE&M is often not subject to continuous improvement and retrospectives.
Especially, if an organization uses a waterfallish process, too much time passes between the requirements analysis and a potential retrospective after the project. Still, errors during requirements analysis are often the most expensive and critical ones. As a requirements engineer, you should take notes, when you discover critical issues that might have caused problems otherwise. Having an account on how you reduced the project risk helps to prove the value of your RE&M activities. You can also plan RE&M specific retrospectives after important focus groups or workshops.
What did I learn?
There are huge differences in how organizations implement RE&M and project management. Agile approaches lead to completely different challenges than plan driven approaches. Different frameworks and standards vary in their guidelines and perspectives. Therefore, education and experience of project managers and requirements engineers have a huge impact on their way of working and thinking.
The biggest challenge that we repeatedly encountered in recent years resulted from this complexity: Different perspectives lead to misunderstandings and conflicts, until we discovered them and could use them to our advantage. It took us significant time to align all authors with their multifaceted backgrounds and to agree on shared concepts and definitions. Our resolution was to avoid creating a general and universally applicable process model. Instead, we put our different experiences and points of view “on the table” and discussed them. Sometimes, we could not agree on a single perception, because of too different backgrounds. In those cases, we decided to have both perspectives equally represented next too each other – if we were convinced that the conflict was not caused by different terms for the same concept.
We created the book iteratively and started each iteration with a workshop. In these workshops, the group agreed to assign two or three authors to a specific topic (e.g. Risk Management). These authors would write the chapter. Finally, a number of other authors reviewed each chapter. Despite the different viewpoints, we wanted to create a consistent reading experience. Therefore, we conducted a final lectorate to harmonize writing style and terminology of the chapters, without changing their basic views. We are proud that we could respect the opinions and experiences of so many experienced project managers and requirements engineers in this way.