We will be discussing the techniques that are helpful in the analysis phase along with a few examples. In this chapter, you will learn the following topics:
You need to dive deeper to understand what you are up against. One of the common reasons why projects fail to deliver on time is that the requirements keep on bubbling up at a later stage. You should ensure that you have the right resources on board before you start discussions on requirements. It is the foundation for your project. Projects will fail if the requirements are incomplete, if the right analysis was not done to understand them correctly, or if you neglect to push back on requirements that do not add any value. All these cases will result in more work (often rework) and will impact the quality and timeline of the project.
It becomes tough to fix such projects at a later stage, as things that were missed initially keep bubbling up throughout the journey and you are always reacting to them (of course, the business team gets frustrated with explaining the same things over and over again).
Consultants use different techniques for gathering requirements. Each has value in certain circumstances, and in many cases, you need multiple techniques to gain a complete picture of the requirements. The following diagram shows some common techniques used for requirement gathering for ERP systems.
Listening is the first step in the requirements-gathering phase; you need to listen to the customer to understand what they need. We will now talk about the tools you can use at this stage to make listening or the information collection process smoother.
Prepare questionnaires to collect information and let the business SMEs fill them out. At this stage, you are giving them an opportunity to provide you with the details of what the business needs and with their view of the requirements.
Here is an example of how the quality of your questions makes a difference. Suppose you are working with the client to understand the revenue recognition and deferrals process, one way of doing this is to go to the client, ask them to explain the entire process, and ask an open-ended question, such as "What would you like to have in the new system?". Another way is to understand the topic and put together good questions to engage the customer. The following table shows a sample of some questions or scenarios; I will take it to the customer and ask them for clarification/examples and more inputs:
Revenue recognition and deferral questionnaire |
---|
Give me an example of the most common revenue recognition. For example, defer revenue to 12 months, starting today. |
Do you have scenarios of deferring only a portion of the revenue (that is, if the revenue consists of 60 percent license and 40 percent services, then only services should be deferred)? |
Renewal with the date in the past (start date in past). |
Renewal with the date in the future (Start date in future). |
Selling a future-dated contract. |
Upsell of the product for the remaining period of the existing contract. |
Rounding off—first or last month? |
Proration calculations for the first and last month. |
Complexities with uneven periods? (calculations by number of days in period? Applicable if you have 4-4-5 periods). |
New sale with contract dates in the past. |
Contract cancellation for the remaining period—reverse deferred revenue for the rest of the periods? |
Contract cancellation with full refund—reverse deferred revenue for future, and recognize loss for past periods in the current period. |
Batch invoicing for renewals and calculations of deferrals/recognition. Do you want every entry to hit GL or aggregated values? |
Posting of deferral and recognition of a line discount. |
Allocation of total order discount at the line level for deferral/recognition. |
Migration of previously sold contracts (deferrals and recognition entries). |
Cancellation of contracts sold prior to migration. |
Contract cancellation with full refund for contracts sold prior to migration. |
Renewal of previously sold contracts. |
Upsell on contracts sold prior to migration. |
Replacement scenarios (?)—Need to cancel the previous line item and add a different line item starting today. |
Integrations with the contract management system (where do you get the plan start and end dates from?) |
Customer bought today, product launched in two months from now, for a year. Work starts in two weeks from now. When do you start recognition? |
What happens when the launch date of a planned marketing campaign moves? |
Variable billing per usage? (for example, cloud scenario, number of impressions in advertising business) |
Are there any other scenarios we missed? |
What are the key pain points in the current system? |
Now that you have collected information from the customer, it's time to analyze and come up with your understanding of what they need. Document the requirements, open questions you want to discuss further and get ready to lead the requirements discussions.
It's time for you to dive deep into the requirements by engaging the customer and asking the right questions to extract the information that you need. Clarify conflicting requirements across the business groups.
Get business rules defined and validated in the form of flow charts. Each functional team should work together on the future state of a business flow. This will validate the completeness of requirements coverage, dependencies, and business rules. For example, the order review process will be as follows:
The following diagram describes the process flow—I will go to business after analyzing several spreadsheets and the existing documentation about the current budget planning process and have them provide feedback on the requirement understanding.
As a consultant, you need to bring in the knowledge of the best practices in the industry, help customers improve their processes, and push back on requirements that do not add value to the business. As part of this negotiation, you will need to provide insights into why a specific feature is not needed anymore and what it can be replaced with in the new process.
Often, requirements are seen from the perspective of how it works in the current system. It does not always mean how it should work. What is worse, is that challenges/bugs in the current system become requirements to be implemented in Dynamics AX. Consultants accept these as requirements and provide custom solutions. Understand the problem you are trying to solve. Get to the bottom of the issue and provide a solution accordingly. In most cases, customization is a lazy way of providing solutions as an analyst; you are just taking the solution from the existing system and pushing your work to the developer in terms of customization.
Here are a few examples of requirements for which you should push back:
There are many examples like this; poor analysis will add more customization. Every time you get a requirement that needs customization, try to think how other Dynamics AX customers are using it. Why did Microsoft not build the feature? You will then find the pointers to push back. Having said that, there may be some legitimate needs for customization though.
These types of requirements keep coming back hence, you should document them in your Business Requirements Document (BRD) with the priority of Out of Scope.
In some situations, you run into strong personalities from a customer/business SME and they might be reluctant to accept the provided recommendations. You should document your feedback in BRD/Gap Fit documents as Strongly not recommended. For example, in one of the projects, I was involved in a review capacity. The customer wanted to see on-hand information of different variants of the product in columns (because they were used to seeing it that way in the previous system). Dynamics AX 2009 used to store them as rows and it was going to be a major change in the core feature of Dynamics AX. I documented all the reasons to avoid it. Eventually, there were issues with the feature and initial documentation of the pushback was helpful.
Your goal should be to simplify the processes and go with the industry standards. Your efforts in this exercise are to protect the interests of your customer and the project; don't be shy in pushing back.