“Projects could be so much fun if it wasn’t for the users.” Well, I have often heard this from different project teams. And there is some truth to this: Too many projects fail to ‘wow’ an organization because the business is disappointed about the final results. Based on my personal experience, I believe that the traditional implementation approaches are partially responsible for that.
THE TRADITIONAL APPROACH
In my first consulting job, I was taught to spend a lot of time on gathering and documenting requirements. These documents often reached massive proportions and they were signed off by puzzled business people. Once we had the signatures, we were allowed to move on to the actual design. This might work for ERP packages with standard processes. But not necessarily for Business Analytics where processes are flexible and unique. But here is the issue: It is tough for the business to articulate clear requirements. Especially when they are used to manual spreadsheet processes and do not know how technology can help them. Visualizing and understanding best practices is a whole different problem (Read this post for a more detailed discussion)
THE PROBLEM: LOCK IN
The traditional project approach limits the ability to develop a solid and better process. How do you want to ask for something that you don’t even know is possible or exists? Users provide basic requirements but they are left wondering about how all of this will look in the future. They are afraid to ask for things as they have seen stuff fail in spreadsheets. They sign-off on the requirements only to find out that the final design does not really help them. They are basically locked-in before they are actually qualified to make a final decision.
A BETTER APPROACH FOR BUSINESS ANALYTICS
Business Analytics software like IBM Cognos 10 and TM1 is very flexible. You can quickly develop powerful solutions. And that allows us to use a better approach: iterative (rapid) prototyping. Instead of strictly separating between requirements gathering and design, we split the entire project into several prototypes. Each prototype is being reviewed by the business.
THE APPROACH IN ACTION -AN EXAMPLE
Take a look at the following sample budgeting process (this is a real example from a client). The initial requirements gathering activities allowed us to identify four distinct process steps:
- We gathered the detailed requirements for the first process step.
- We built a prototype based on the input using best practices
- The business reviewed the prototype in a formal meeting
- The feedback was validated and documented in the project documentation
- The prototype was updated and the team proceeded to process step 2
- The next prototype review will include the agreed upon changes from prototype 1
Each prototype iteration took just 2-4 days at most. The users had the opportunity to review the proposed solution at least four times. After the final prototype review we obtained the sign-off on requirements and design. That’s when the final built started. Here is what this looks like:
What’s the advantage of this? Reviewing the prototype allows the business to visualize and understand their future process. And that allows them to refine their requirements. Also, they are able to see how the software would help them. Last but not least, there were few surprises in testing. The end result: Happy business users!
A WORD OF CAUTION
This method can work in many cases. However, I have found that you need to be very careful not to get trapped in a situation of ever expanding scope. As the stakeholders begin to learn they often develop a lot of ideas. It is critical to balance the desire to add more stuff with delivering the project on schedule. Make sure to have the appropriate support from the management team. Also, make sure to have the right people on the ground.
If you haven’t tried this approach, consider it! User happiness is the best project KPI.