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.
- The questionnaire should be tailored for the client according to the his/her functional area and role.
- Microsoft Dynamics Sure Step provides you with a good starting point for questionnaires. You will have to tailor them considering the client business, scope, and the requirements knowledge based on the proposal and the client organization structure.
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? |
- This is something I learnt from one of my bosses; for which I must give him credit. Going with your detailed homework shows your knowledge about the topic and helps in gaining the customer's confidence that you understand it. At the same time, it also reduces the chances of missing out on any areas during discovery and the time the customer has to spend on explaining the process to you.
- In this process, get examples of complex calculations (for example, revenue deferrals, royalties, commission, and pricing calculations are good candidates where you would need examples). Understand different scenarios and all the factors involved in calculations.
- Understand the current business process flows (as is processes).
- Ask for any work instructions or operations manuals that document their current process to help in understanding the current business process.
- Get samples of the reports, especially external facing documents like invoices (sometimes customer invoices can become a project by themselves), checks, customer statements, packing slip, shipping labels, and so on, as applicable). Similarly, get samples of other templates, such as current fixed assets, import template, positive pay.
- Schedule an existing-system walkthrough, especially for areas that are unique for the customer's business. Take screenshots and document the process. Clarify if any changes are to be made to the existing processes and provide recommendations for changes.
- In global projects, engage the business SMEs to work with their counterparts from different locales to come up with unified processes.
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:
- If new customer arrives, he/she will go to the new ship queue.
- If order is for more than X dollars, it needs to go through the big order queue.
- If the credit limit is exceeded or past due account, route to the credit queue.
- If a special product (license purchase, and so on), it needs to go to the merchandizing queue.
- If there's a customer tax exemption, route it to the tax queue.
- A credit card order should go through fraud checks and to the fraud queue, if necessary.
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.
- Understand the current process and document the pain areas; ask questions to clarify.
- Avoid any discussion about solutions in the requirements meetings (you don't want the business to dictate the solution).
- Do not spend time on discussing out-of-scope areas until the client has approved the change order. Do not let your project derail, if it is not approved to be in scope, it is not approved by the person who is signing the check.
- Capture reporting, security, integration, and data migration requirements along with other requirements discussions. Non-functional requirements play a key role in shaping a project's success.
- Avoid using Dynamics AX terminologies or acronyms (for example, posting profile, value models or DAX, OB, CRP and so on) during discussions with the business team. It may be your 10th Dynamics AX implementation, but most likely it is the first one for the client, and you will throw them off by using those terminologies.
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:
- I had a customer requirement to post an out-of-balance general journal entry. Dynamics AX doesn't support it. The reason why the users were asking for this to be a requirement was because the previous system had a bug that would post an out-of-balance entry in certain scenarios and then accountants had to use this feature to correct it.
- A customer wanted a very complex workflow to be created. Every taxi expense greater than $30 had to go through multiple approvals, all the way to the CEO. All of that was being done when they were handling expense approvals on paper, and was okay till then. We had to explain the complexity they were adding (in terms of implementation and, more importantly, ongoing support) by building a complex workflow. The question is not whether Dynamics AX can handle it; you need to ask what value it would add and whether the efforts are justified. It was a tough battle to win, but it was worth fighting for and we won it in the best interests of the customer.
- Another customer requested changing the unit price field to 8 decimal places. They were selling some products in the quantity of 1 million units and the per unit price would come to 8 decimals in reporting. Hence, the person who was writing reports in the data warehouse requested the change in the ERP to save reporting efforts.
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.
Note
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.