• Performance Management Done Right

    Justin Biard on consulting

    Don't let the right tool become the wrong solution. In capable hands Anaplan, Oracle-Hyperion, OneStream, et.al. can all be implemented to address your performance management needs. It is true that software vendors provide a mix of price and features to differentiate their platforms. They must do so to be competitive.

    On-premises solutions could be critical or you could be looking to jump to the Cloud. Perhaps you are a Microsoft-only shop or your IT strategy dictates Linux for all servers. One vendor or another may be a slightly better fit for your requirements or your strategic preference. All solutions are ultimately girded by the overall project scope: expected delivery time, available budget / resources and deliverables.

    When Solutions Fail

    There is a universe of possibilities for how unsuccessful a solution will be at addressing your performance management needs. The risks to success are found where requirements, the capabilities of the tool(s) selected and project scope are misaligned and to the extent that compromises or work-arounds become unlikely.

    Project Delivery Risks

    It is rare for these key areas to align perfectly or to remain so throughout a project.

    • Solution Requirements
    • Software Features
    • Project Scope (time, budget and deliverables)

    As your business continues to change, these factors will also continually drift apart over time increasing the risk of the right tool(s) becoming the wrong solution for your performance management needs.

    A Good Place to Start

    Time is critical so it is important to move quickly but it is also important to make well informed decisions. If you have not started yet, a good place to start is requirements analysis. Every ounce of detail you can realistically uncover now will save you pounds of trouble later.

    Understand why you need the solution in question. Gather and prioritize your requirements before you select a software vendor or finalize the project scope.

    This scenario is ideal. If you are not yet partnered with a particular software vendor then you will have the most flexibility at this stage of your project. It is also important to remember that for all but the simplest of projects, there will be requirements somewhere that will not be addressed. Usually these are subtle details but sometimes they can become show-stoppers.

    It is helpful at this stage to start visualizing your overall solution expectations in the form of high-level diagrams. How does a home architect communicate their understanding of requirements for a new property? At each stage of the project, they will produce incrementally more detailed versions of the architecture to communicate the right details at the right time and to avoid costly re-work. Here is an example of such a diagram for a traditional performance management solution:
    Example Functional Architecture Diagram
    Identifying requirements, critical features (must-haves) and success factors now will help you avoid workarounds due to missing features and even total solution failure later on. It will also help you prioritize compromises that you must accept (and new feature requests for the vendor) when finalizing your software selection.

    On The Road to Success

    Once you have completed some level of requirements analysis with a high-level vision for the solution, you will be able to approach vendor selection with a degree of confidence and put them to the test. Grading vendors on their ability to meet your requirements is not a guarantee for success but it is a great second step down the road.

    There are very few more awkward conversations than to go back to your customer with a surprise to tell them that a critical feature expectation will not be met.

    Vendor Firing Squad

    Looking at product features and understanding how they could address your requirements is both educational and necessary. If you have two or three software vendor options but only one of them satisfies all of your must-have requirements then you can begin the process of elimination or prioritization based on other external factors such as cost or strategic partnerships.

    After this point changing directions can be costly. It is important to refer back to the prioritized feature list (created above) to ensure that you are not surprised later on by any gaps that may exist with the software vendor's platform and your requirements. Skipping this will only serve to increase project costs and the risk of eventual failure.

    Note: There is usually a benefit (to the customer) for purchasing software at critical times of year from a software vendor. Software sales teams will often have more leeway to provide discounts or incentives, for example, around their fiscal year end.

    Delivering the Solution

    Now that you have a perspective on your solution requirements and a software vendor selected, it is time to lock down your project scope (timeline, budget/resources and deliverables).

    No matter which vendor or technology solution is selected, the most common pitfalls (outside of inaccurate requirements) with delivering a performance management solutions are:

    1. Data quality issues
    2. Availability of metadata
    3. Lack of customer participation
    4. Limited scope of testing
    5. Ineffective training
    6. Over-selling and under-delivering

    The good news is that these pitfalls and their symptoms can be avoided with the right approach to project planning and management. The bad news is that project timelines and budgets are typically at odds with avoiding them properly. If you feel pressure to cut corners on any of the above, we encourage you instead to consider reducing your project scope.

    Delivering the right solutions incrementally is generally better and less expensive than consistently delivering the wrong solutions.

    The two most common project approaches to delivering successful performance management solutions are "Waterfall" and "Agile" methodologies with a general recommendation for using a hybrid of the two. Whichever project management approach you are most comfortable with, we recommend some form of initial requirements and design followed by frequent reviews of the tangible solution with your customers. Do this throughout the build.

    The duration and frequency of work in progress solution review meetings should be established at the onset of every performance management project.

    The purpose of showing your products early and often is to gather feedback on prototypes and to make course corrections along the way. Even in a non-Agile project, this feedback is critical to transferring knowledge, reducing training-related defects during testing and delivering a successful performance management solution.

    Wrapping Up

    In this post we looked at a high-level process for successful performance management solution delivery. We talked about three of the key drivers of success on a performance management project including:

    • Solution Requirements
    • Software Features
    • Project Scope (time, budget and deliverables)

    Finally, we reviewed some of the pitfalls that come up on a project where performance management solutions are to be delivered. We hope this discussion gave you some insights for your own projects.

    We work with customers and consulting partners around the world. If you have any questions or would like our help delivering your performance management solution: