Requirement gathering is a crucial step for a project and especially an IT project to succeed. Without a detailed understanding of what the requirements and accordingly the corresponding functions and features of the output are, the project is likely to fail. We all know this pictures that show what can become out of a tire on a rope hanging down a tree, if requirements are not clearly defined; therefore most of the project manager undertake thorough requirement gathering activities. Although every good project manager knows about the importance of getting the requirements right, how is it possible that still project fail due to lack of understanding of the requirements?
My answer is that in those projects time was an issue and project manager had to race through the process of gathering due to executive pressure. Executives always want to see progress, but progress in an IT project often means lines of code or finished features. Unfortunately, no code is generated during the requirement gathering process; therefore it is hardly seen as progress. The worst situation are those were the sponsor thinks he knows the requirements and hence doesn’t see any necessity for requirement gathering at all. I have recently been in a situation like that, were a project almost failed, because of the sponsor’s actions during the requirement gathering. Fortunately, we were still able to make the project a success. In the following I will describe the situation, why the project could have failed and how we turned it around.
An executive came to our team with a project suggestion. He had an idea for a project in a department that wasn’t his, but he was convinced that they would need that software he had in mind. Because it sounded like an interesting project, we took it. After our first meeting with our customer it was clear that there hasn’t been a business case, since the project was just based on the idea of the sponsor. Our sponsor was a powerful person in the company so that we and our customer were forced to start the project, although we were hesitant to do so without a business case. We tried to create a business case to get the requirements clear, but none of our customer had a clear picture of what was exactly needed. So we arranged a meeting with our sponsor and our customer either to get our requirements right (We have prepared a process map to find the activities where the proposed software would be helpful) or to stop the project. Unfortunately neither happened, because our sponsor dictated the requirements and the users were afraid to disagree with him. Although we were not convinced that those were the needed requirements, we had to move on due and start developing the software. We were right and the actions of our sponsor made us almost miss the deadline due to scope changes in the middle of the project.
In IT projects a close collaboration between the project team and the users is important to be able to check if requirements were translated into the right features and functions. Because we anticipated that the requirements might have been wrong, we intensified the collaboration with the users in order to discover development of none valuable functions immediately. As a consequence we experienced a rolling scope change, that is, many incremental changes that minimize the wasted time, but lead eventually to a big change in the requirements.
Our sponsor agreed with all the changes in the scope, since his ultimate goal was to make the user happy; however his actions almost made the project fail. The lessons learned is that you should never start a project were the requirements are unclear or pushed onto the users from top management, because the actions we took to rescue the project are not possible in every environment.
Prepared by Peter
Posts
