13 Jan Differentiating the Differences in APO requirements
I hear this a lot on IT projects, “Oh that’s not for us; we’re different.” And I always end up wondering, compared to who? And that’s the key: there is no “same.” We’re all different. But where do these differences come from and how many are real, and how many are imagined? Knowing the difference can save quite a bit of time and effort (and money) on any IT project, but especially APO planning implementations.
The double edged sword of APO is how highly customizable it is. This flexibility can be powerful, or paralyzing depending on how you manage this phase of the project. There are two types of “differences” in an organization. Those that are critical to maintaining the business, and those that just evolve over the course of time. The critical differences are a no brainier to go after. Develop, customize and modify the system to enable these processes and both IT and customers will see huge dividends from the investment. It is the other types of “differences,” the comfort, or cultural customizations that cause the most trouble.
Knowing what these unintentional differences look like is a tricky skill to master. The simple example I always use is, “this button needs to be blue.” Maybe it was blue in the past two systems, but does it need to be? Does it hurt the process at all if it’s red? If these differences are not easily configured in APO, you could end up wasting time, effort and valuable resources customizing the system. These are huge distractions and consume an inordinate amount of resources compared to the benefits delivered.
Teasing these differences out can require some very difficult and awkward conversations, but they are necessary in the long run. Usually the business side has lived with certain features so long that they have a hard time knowing the difference. It requires patience, asking the 5 Whys, and drilling down to the root requirements to arrive at what is really important to the project. It is important to remember that nobody is (usually) intentionally being difficult for the sake of being difficult; everyone just carries in the bias of previous experiences. It is a conversation worth having to hold a mirror up to the business and separate out the real from the comfort requirements. While it can be difficult and awkward at times, in the long run, the project will thank you in the end.