What can we do to fix it?
When I was planning out the chapters of the book, I was looking at it from the point of view of how I fix things if they go sideways or, better yet, how to prevent those things from happening in the first place. I was trying to figure out the areas where most of the problems occur and things that we can do to help prevent or fix the most common issues.
There are many ways that a project can get out of control, for lack of a better term. Generally, when an organization and a partner put together what a project will consist of, there is a pretty good idea of what the project is supposed to accomplish. Generally speaking, the point of the project is to introduce the system into the business to improve its efficiency, save money, and help the company to improve its financial status.
The sales team of the partner and the customer agree on what the solution will look like in general terms, including which of the D365 F&SCM module will be deployed, some basic configurations of those modules, data management and migrations, reporting, and potentially, the inclusion of ISV modules or application integrations between F&SCM and some other application(s). Note that these applications may be legacy applications, running on hardware in the company’s data center, or newer cloud-based SaaS solutions. We will have a long discussion about integrations in a later chapter.
As most salespeople aren’t technically qualified to create the Statement of Work (SOW) on their own, they will get the help of a solutions architect (SA) to help with scoping out the solution and a project manager to assist in costing the project. Once this is completed, the solution and plan are handed over to the delivery team. As the project plan at this stage is a very high-level plan, the project manager will, with the assistance of the SA, fill in who will do what specific tasks at what point in the project.
However, one of the things we tend to find out after the SOW between the two sides has been worked out and signed is that people have their own agendas, and they want their issues dealt with in a specific way. If we go back to the previous example of the expense report, we need to come up with a solution that will fix the business process.
At this point, those on the project might start pointing fingers at each other and attribute “blame” for the incorrect solution. At this point, as the SA, it is your job to calm everyone down and come up with a way to implement the customer’s requirement, but you should also be able to explain and negotiate a potential change to the way they perform that specific business practice.
In this case, if you can show the customer how the method they wish to use causes issues in areas such as expense payments, reporting, tax collection, and several other areas, you may just be able to convince them that maybe there is a better way to execute this process. The SA needs to be politically savvy enough to be able to negotiate with the customer to do things more conventionally.
