For many project managers, these terms are synonymous and entail those activities in certain models that occur at the outset of the project whereby our project teams write a requirements specification. Personally, I am not a big advocate of documentation heavy implementation models but understand these models remain prevalent in today’s projects. So what is the difference between gathering and analyzing requirements?
In my opinion, gathering entails that set of activities whereby customers are asked to define their requirements including that set of needed capabilities, interfaces to existing systems, reports, etc. In a nutshell, the project team is told the set. When analyzing requirements, the project team listens to how the customer runs their business before distilling the conversation into a set of business needs. In a nutshell, the project team analyzes the business operations and defines the requirements vice being told (gathering) the requirements.
Clearly in either situation, the customer will ultimately agree upon these requirements so neither activity is not completed in isolation. Typically, what I have found is many business users if asked to define their requirements will actually tell the project team how their current system works. How many times have we heard the phrase, "my current system works this way", or "this is how I do it today." What the users typically describes is that set of key strokes or data entry that occurs within the current system. This approach will necessarily include how screens function, what reports are required and is not necessarily what the new system capabilities should be but what the old system does. Especially with a commercial software implementation, gathering requirements sets the customer expectation the new system will work like the old system. This leads to extensive customization of the commercial software, force fitting business processes vice optimizing them and rarely leads to a new system that is an improvement on the old system (the reason for the project).
In the situation whereby, the project team analyzes the requirements, the old system context is not set as an expectation but rather that some business processes will change and will improve the business situation. When the customer leads with "My current system work this way," the project team should probe deeper and ask the why questions to understand the true business requirement/need. This affords the project team the opportunity to model the business processes within the core capability of the commercial package, minimize customization, and ensure the strategic objectives of the project are met the most important of which is an improved business situation with the new system.
To illustrate the point, I recently had a customer who during the requirements phase was defining the required data elements for a screen including screen operation. They were describing how their current system operated. The system was a service ticketing system that required a screen to input service tickets, another to modify tickets, a third to review tickets resolutions, and they needed three reports to manage the business. Clearly, they were defining a detailed design based on the existing system. To distill the requirements, I asked a couple of pointed questions.
Why do you need a screen to analyze tickets?
Why do you need a separate screen to modify tickets?
What are the purpose of the three reports?
By asking these questions, I determined the customer uses an outside vendor to service the tickets and this vendor is paid for each resolved ticket. The three reports were currently used to support the invoice review process and were three different cuts of the same data. In this situation, the project team now understands the business to a deeper level and has greater flexibility in not only improving the business but providing a solution with minimal customization. In my instance, I combined all the screens together as this is how the commercial package works and provided a single report in the form of a pivot table that provided the customer an easier way to review invoices as well as an electronic record of the reconciliation process which eased the negotiation process when differences of opinion occurred.
In my opinion, project teams and especially commercial software project teams should always analyze the requirements vice just gathering them.
Comments