5 of 5: Top 5 Mistakes Collecting SPM / EIM Project Requirements

You shied away from real improvement opportunities by falling back into the old way of doing things. It’s nice to upgrade parts of your system so they perform better, but if you don’t redesign around the new capabilities you may not see any real benefits. Your new system will still be a pig, even if it’s got a shiny new coat of lipstick.

The Problem

You’re fighting human nature again. The selection of a fancy new enterprise software package is a big deal. A lot of promises are made and due diligence is done around making sure the investment is worthy. Rarely is there the directive to “keep our processes exactly as they are.” In fact, many times the introduction of a new system is identified as the perfect catalyst for implementing the many changes management desires.

Many times while gathering requirements you are asked to describe in uncomfortable detail “how the day to day processes” will look. In general, this is fine. Part of building a solid system is putting together one that’s easy to maintain. The problem comes when the group gets caught up in the minutiae of supporting a system. Small issues get magnified and exceptions become the basis for system design. This is all very difficult to conceptualize on a white board, so it becomes a huge waste of time. The easiest path ends up being “the way we do it today” because it’s understood and there will be fewer questions.

Other times you are given a design in lieu of requirements. Once again, this is not a problem in general. The problem comes if your software doesn’t support that desired design or if you have a better solution that the clients resists. The tendency is to fold and go with what they already understand.

Most times the client subject matter experts have their methods and want to fit the new system to those methods whether they are good or not. Humans have an amazing ability to adapt to change, but they don’t like it.

The Solution

Process requirements can be generally put into two buckets: cyclical and maintenance.

Cyclical items are all the actions that have to take place in order to process compensation on a regular basis. This would include creating manual transactions or adjustments, putting reference data into the system such as people or rates, or potentially upstream actions such as pulling a report from SAP.

Maintenance items are all actions outside of the regular cycle. This would include plan updates, ad hoc reporting, issue resolution, etc.

As part of the requirements sessions you want to create as detailed as possible a future state model for all processes that fall under the cyclical category. These operations happen every pay cycle and there needs to be a clear understanding of what needs to happen and when. Sometimes this activity falls to the design phase of a project and that is fine, but they really are Design Requirements. A design requirement is a stipulation of how certain things happen in the system. For example, you may have a requirement that adjustment transactions are needed. A design requirement may be that adjustment transactions can only be created by an automated process. This obviously changes the scope of that requirement a great deal and should be captured as early as possible.

The exploration of these routine workflow items is vital to creating a clean running system. All ideas for improvement can be incorporated during this early stage and all designs can be built around the new processes. Since it’s still early in the project, old processes can be analyzed and rethought without too much disruption. Many times a client will push back on a new process simply because they can’t see how it’s supposed to work. This is where it helps to have an experienced team that can help with visualizing the new processes and potentially doing pilot and/or proof of concepts. I like to give options with pros and cons identified and let the client decide. It helps with buy-in later.

Maintenance items should be listed, but not designed in detail just yet. Clients typically don’t fully understand what these items will be, how complex they are, or how frequently they will happen. So you would be wasting a lot of time looking at them in detail. It’s best to wait until as late as the UAT phase before starting to put together these processes. However, once you start don’t hesitate to offer solutions that break the current mold. Most clients are open to new ideas if they make sense and are backed by clear explanations and a clever presentation.

The key is to expressly categorize design requests as they occur. “How will I enter that rate?” should get the answer “How often do the rates change?” If the answer is “once a year”, then this gets put into the maintenance bucket and is addressed later. If the answer is “once a month”, then this gets put in the cyclical bucket. We schedule a requirements meeting or we address it now and it gets its own Visio diagram.

You are always going to need to “sell” your ideas for process improvement. So the goal should be to minimize the number of ideas that need to be sold. This will allow you to put more thought into them and come up with the most evidence to support your plan. Hopefully, this leads to better designs and less backsliding into “the old way of doing things.”