As a project manager, we all know and understand that the correct understanding of the requirement will make or break the project. Moreover, we know that the implementation team will use several elicitation techniques such as interviews, brainstorming, requirement gathering workshops, etc to understand the requirements and document them. To ensure the correctness of the requirements we follow a technique known as “reverse role play” in which the implementation team will explain the business need to the business team while the audience will ensure that the speaker’s interpretation of the business requirement is as per their expectations. In this article, we will discuss some of the pre-requisites, some tools & techniques and finally the difference that we must acknowledge when it comes to gathering the requirements for a complex project.
Let us first define a complex project. Although there is no clear distinction between a simple and complex project let us try to scope the work for the purpose of this article. Moreover, the term “complex” is relative; a complex project for a project manager with 2 years of experience may be a simple one for a project manager with 10 years of experience in the same area of expertise. An empirical way to look at the definition is by the combination of cost (or budget) of the project and the duration of the project. For the purpose of this article, a complex project is one with more than 10M USD of budget and more than a year’s long duration. These values are based on the recent poll conducted on the project managers which concluded that a project manager with under 10 years of experience can be intimidated by such a project. Additionally, I must also include the availability of technological resources for the project and the political connect of the sponsor of the project in defining the complexity of a project. The two latter parameters are subjective but we can devise a methodology to convert into a numerical value. We will discuss this topic in my other article where I will discuss my tool for effort estimation.
There are certain requirements that must be adhered to before the project team can start the interview process and gather the requirements. These pre-requisites are project charter, signed contract, and project kick-off. However, in this article, we are not focusing on these aspects of the project. Apart from these procedural requirements, a successful project manager must also outline other aspects of the project such as processes and people. Some of these criteria can still be relevant for simpler projects but it is mandatory for a complex project.
One such pre-requisite is understanding the user’s perspective of the business need. So far, my experience is that most of these projects are conceived and initiated in the boardroom with executives and higher management. I am not implying that the executives are unaware of the ground reality but it is imperative to understand the user’s perspective also. In one such implementation, when I started meeting with the users and was trying to understand a process say Bill of Materials or Material Requirement Planning I was not feeling comfortable with the information I was getting. With little curiosity and understanding, I felt that the user is interested in learning a computer. So, I traded our knowledge. I can proudly say that he is the one helped me understand the manufacturing process. I, in turn, helped him understand the computer, ERP package and other nut & bolts of the computerization. Later on, I also realized that he became an avid proponent of my management style and computerization.
With this incident, I become cautious and to avoid such awkwardness I built an excel based tool. This tool is for private use only and I start capturing some of the details about the person whom I am interacting with. These details include his behavior, attitude toward the system, his manager, and towards me, things that he focuses on and some similar activities without affecting his privacy or spying on him. That tool gave me a good glimpse of people’s thought process within a couple of weeks of the requirement gathering phase. That process is a time taking process and hence will not work where the requirement gathering process is small.
One final aspect of the requirement gathering phase of a complex project is the timely but comprehensive understanding of the requirement. To accomplish this, I built another tool that will link between the requirement and named it R3 (Requirement – Requirement relationship). With this tool, I was able to build a complete schematic diagram of the system. The business users loved that and it also speeds up the process of requirement gathering.
To complete the requirement gathering phase in a timely manner we must use some tools and techniques. Let us understand some of these tools that we will need. It is important to mention that none of these tools are exclusive to a complex project. However, these tools are very useful for a complex project. The first and foremost tool is the brainstorming sessions.
Use Cases & Scenarios – Use cases and scenarios are very helpful in any complex situation. The use case is helpful in validating the different functionalities, exception cases or the boundary conditions. However, these tools come with a drawback that one can prepare the use cases only after knowing the high-level functionality of the system.
Prototyping is yet another tool that is used in a complex project or in a complex scenario to demonstrate a part of the whole of the system. This type of tool is very useful for people who are visual. It not only clarifies the requirement but it also speeds up the build process. The caveat is the process may get delayed in case of the wrong requirement. Someone may also say that, it’s better that we find the issue of the wrong requirements early on and hence saved millions of dollars for the customer. I tend to agree with that.
Role-Playing is one of the other tools that is very helpful in gathering requirements for a complex project. Not only the implementation team and the business team switch their roles but they also switch within the team ensuring that everyone understands the system in great detail. Personally, I like this tool more than anything else because it also creates some sort of backup resources in case of need. Additionally, it also enhances the skill set of resources.
It is important to understand that the tools, techniques and other pre-requisites are different for different types of projects. For example, role play is more relevant for an ERP implementation project which is generally complex. However, prototyping is more useful for a technical discussion or to showcase the usage of relatively new technology. The success of a project lies in the right selection of these tools and the proper usages of it.
For the latest version of the project estimation tool, please complete the contact form. I will get in touch with you within 48 to 72 hours, Monday to Friday.