We have a client who was looking to migrate a lot of documents from System A to System B while also consolidating them into the new storage paradigm. The current process depended heavily on using Excel, a time consuming and error prone process.
The client originally thought that the bottleneck was in the actual migration. However, once we met with them and applied the User Experience (UX) methods, we realized that the majority of the time spent migrating was not in the actual moving of documents. It was in the mapping, that is, deciding where does each of the source documents and folders from System A would end up in the new System B.
The business process proved unmanageable because the client was using Excel to track all these mapping.
To solve this, we built a mapping tool that brought in over $2 million in savings.
Before the tool was developed, each business area was taking about 4 months of a Senior Information Management (IM) person and one support person. At that rate, complete migration was going to take 16 years, and it was hard to add people because of the complexity and risks of errors in Excel mapping.
The new tool removed the complexity, making it much easier to bring in more people.
The time required to migrate was reduced to about 1 month of support person and less than a week of Senior Information Management member is now required for supervision. That’s a 400% improvement for support staff and 2,000% improvement for senior staff members.
Here are some key lessons I want to emphasize:
1. Your Business/Functional Requirements may not be describing what your business users really need. (In our client's case, they were looking to speed up migration instead of figuring out the mapping part)
2. Asking your business users what they want may also be futile. In our case, they asked for a faster migration tool. Later on, when we tried to 'explore deeper' using traditional methods - they asked for a an Excel Macro to better track the source to target relationship. Even with the best possible macro, the project was going to take up to 7 years with their current people at hand, while the Mapping Tool we developed allowed them to complete all migration in just over a year.
3. Be clear on your project's primary business objective and what key activities you would like to optimize, then have your Business Analyst watch the business users perform these key activities. It's many times more revealing to watch them do it rather than asking them what would they would like to see improved.
4. Most of the scope creep comes out of allowing your business users to 'design' the system functionality. A more effective approach is to observe them using their systems to collect accurate data, then validate the data with prototyping and usability testing before building the system.
5. When using Scrum and other Agile methods, don't jump into implementation. You'll pay the same price for the scope creep, only you'll pay it in small installments in each of your sprints. Have your first sprint solely focus on UX activities validate that you’re understanding the real problem.
This case study is not an isolated incident. A study by PMI (Project Management Institute) confirmed that 47% of software projects are running into issues with requirements. As I (hopefully) demonstrated here, this new UX methodology is ultimately effective in combating these risks.
Thinking of getting your Business Analysts to use these processes but just unsure where to start? Get in touch to discuss your specific situation.