One of the most common issues in a migration, integration, or almost any process improvement journey is defining the starting point. A customer uses a process that is so well known to them it is like muscle memory. The challenge is that they can often forget details because it is such a natural thing. Likewise, there can be unseen impacts that are assumed but not understood or known. Thus, we have requirements for a project no matter how “simple” it is.
<\/p>\n\n\n\n
The details must be addressed whenever we try to change or improve a process. For example, a long car trip will need to address the need for gas or a recharging station. While that is often assumed, it may not be clear to the person plotting the course. Our systems provide a level of abstraction from details. However, that often leads to us glossing over critical details like fuel for a car.
Data for a process is easy to over-simplify or incorrectly assume to be complete. For example, most systems have unique identifier values and status flags hidden from users. While that is not an issue for a self-contained system, it can be a blocking issue for integrating or communicating with another system.
<\/p>\n\n\n\n
While our customers can take these things for granted, we cannot do so as integrators or implementers. We need to ask questions and get as much access to the details of a process as possible. That may mean sending the customer back to their development team for documentation or details or even to a vendor. That is often a headache or effort they prefer to avoid. However, the cost of not doing so at the start of a project can lead to cost overruns, schedule slippage, or even starting an effort over from scratch.
<\/p>\n\n\n\n
I have found the “trust, but verify” approach works well when I combine it with clear communication. We start with a proof of concept based on what the customer provides us. That POC is designed with a focus on testing the “happy path.” That is the process and ensuring the details are all addressed. While this sometimes has to be done on a production system, it is always preferred to spend the time to set up a sandbox or test environment that we can use to verify inputs, outputs, and side effects.
That adds up to more work done in the initial design and requirements gathering phases, but the cost savings and reduction of headaches more than pay us back. That makes for a smoother improvement journey.
As this is a common challenge for system integrators and solution developers, how do you manage the customer relationship and SDLC to ensure digging deep enough to gather all requirements?<\/p>\n","protected":false},"excerpt":{"rendered":"
One of the most common issues in a migration, integration, or almost any process improvement journey is defining the starting point. A customer uses a process that is so well known to them it is like muscle memory. The challenge is that they can often forget details because it is such a natural thing. Likewise, […]<\/p>\n","protected":false},"author":1,"featured_media":437,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"categories":[20],"tags":[],"class_list":["post-1182","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-building-software"],"yoast_head":"\n