Selecting new enterprise software products is one of the most challenging and potentially high risk tasks many organizations undertake. How often have you gone through a lengthy purchasing process only to find that the choice you made is not the right one?  You sat through demos where the tool shined.  You developed an exhaustive list of requirements and compared them to the stated features of each product.  In the end, you selected a tool only to find out later that it was overly complex or it was a only a conglomeration of poorly integrated products instead of the “suite” that was advertised.

Our experience shows us that Agile methodologies offer a better way.  Enterprise Knowledge has developed a product selection process, based on classic agile principles to remove the risk from large software purchases.

We begin the process in the same way you would build any agile road map.  The business and IT teams collaborate to identify the high level functional areas of the new system.  It is important that the functional areas cover all areas of the application.  For very large or complicated systems, you may need Functional and Sub-functional areas.  The image below shows the primary functional areas of an enterprise web content management system that Enterprise Knowledge has defined and uses as our starting point.  We find type of structure helps to provide context and provides our clients with something more concrete and actionable with which to work.

After identifying the primary functional areas of the new system, the next step is to determine the roles of the people who will be interacting with the system.  The roles should be kept as simple as possible.  For example, the content management system above might have the following roles:

• Content Contributor
• Content Approver
• Site Administrator
• Site Visitor

At this point, everyone involved should have agreement on what the system does and who will use it.  This first piece of work should take no more than a week or so to complete.  The process can be sped up by working with a consulting firm like Enterprise Knowledge that has specific domain knowledge.

The next step is to drill down and understand how the functional areas work and what is important about each functional area.  We typically run a series of workshops to capture the following information:

• An agreed upon definition of this functional area.
• A small set of concrete examples of activities within this area.
• Measurable success criteria that can be used to validate the success of your project.

The business and their IT counterparts now have a common understanding of what the system needs to do and what constitutes success.  The first phase of analysis is now complete.

In order to speed the process, the business and development teams can split up at this point.  The development team needs to select the top 2-3 tools that best meet the needs described in the functional areas.  This effort should be time-boxed to no more than 1 week.  Again, this is a perfect match with an Agile approach.

While the development team is looking at products; the business team should start creating scenarios.  A scenario is a story that describes a specific task, typically including a series of steps to accomplish the task.  Testing each candidate solution against these scenarios gives organizations real insight into how the CMS will meet their specific needs.

Historically, organizations created a list of requirements, compared the requirements against stated product features, and scored each product to select the winner.  The problem with this approach is that most vendors have engineered their products to “win” these evaluations.  The applications are feature rich so that their customers can “check the box” for each requirement.  The fact that these features exist does not ensure that they are easy to use or that they work well together.  All too often organizations end up with something that does not really meet their needs.  Scenarios ensure that the application does what the organization needs, potentially across a number of functional areas, much more so than a generic RFP process where vendors are just checking functionality boxes.

Once the Scenarios are built and the candidate products are selected the iterative evaluation process begins.  The development teams work with each vendor to create prototypes of each scenario.  These scenarios are tested by the business for usability and applicability.  As the scenarios are built out, IT gets a good sense of how difficult it is to work with each tool; while the business gets to see exactly how these tools work in their environment.

Our customers typically know about halfway through the scenarios what the right solution is.  If none of the products looks like a fit, new products are selected and the process is repeated.

At the end of the process the organization knows:

• Exactly what their new system needs to do (the functional areas).
• Which product best meets their needs.
• What it takes to develop or customize the product.  This is especially important as it allows for a much more specific and accurate estimate regarding labor resources and timelines.

Are you about to make a significant investment in new software?

Does this approach make sense to you?

Reduce risk, save resources, and get it right the first time.  Let Enterprise Knowledge facilitate your next product selection process.  Send us an email at info@enterprise-knowledge.com.