All Posts in Industry Commentary

|In: Industry Commentary|Last Updated:

An RFP is a means to an end. The end is to transform some or all of a business. The usual means is to gather requirements, match them up with software features as promised by the vendor, and choose the software that matches up the best.

Therein lies a Grand-Canyon-sized gap: connecting the dots separating your understanding of what the software should do (requirements) with how you want your organization to run differently (the transformation).

What a traditional RFP will help you do is find a software solution that provides capabilities the business needs to stabilize, optimize, and transform. It’s a partial solution – its results are, that is, necessary but not sufficient.

The challenge that RFPs are trying to solve is to help you and your colleagues gain confidence in a transformational event. To that end my company recognizes five stages of organizational change: Analysis, Organization, Stabilization, Optimization, and, finally, Transformation. The problem is that transformations need to be understood and considered—not sold. You are expecting that the world is going to change in some way, and that the way the business has been working may not work in the future.

Which is a key reason you need to avoid the tiresome “Chocolate or Vanilla?” argument. It’s a transformation. You and your colleagues are re-imagining the business and the marketplace it competes in. Chocolate, vanilla, sprinkles and the rest are about keeping IT costs down – a perspective that can cripple a transformation before it has a chance to start.

Once more, with feeling: If you set your goal as selecting software, even the best choice will be the wrong choice. Your goal is transformation. Your selection goal is choosing the best combination of software and solution partner.

There are a lot of ways to select this combination (the starting point is to include the implementation team) that work better than RFPs. Depending on your situation, here are two simple tools to consider:

One approach is largely suggested by a regular reader (Mike!) is to build a decision score card. This approach is useful when you are still narrowing down options—but maybe not for making a final decision.

  • Form a selection team of key partners in your company that need to have a say in the decision.
  • Ask this team to create a list of 20 high-level requirements, described in terms of business capabilities, not software features and functionality, to verify that the solution provider has a basic grasp of the fundamentals.
  • Ask the vendor to pick 10 or workflows that cover these requirements. Budget a bit of time- this should take a half day at the most. Make sure to budget time for questions and answers—with both the vendor and yourself getting a chance to ask questions of each other.
  • Ask the selection team to score on how well the vendor showed that the solution answers the needs for current as well as future state of the team.
  • Ask the vendor for an informal quote—just on the software licenses. Don’t ask for an implementation quote from them. Also ask for customer references and talk to other customers.
  • Vendors generally are not the best implementors of a system. This seems counterintuitive, but it is often the case. In some SaaS software options, you may not have a choice, but where you can, ask the vendor for introductions to at least three implementation partners. To start, ask yourself only one question—“Can I imagine that this company will work shoulder to shoulder with me?” If you find yourself saying any form of  “Not really”, keep looking.

The next suggestion is the Conference Room Pilot (CRP), described here as “An Agile variant optimized for implementing COTS and SaaS applications.” (See this article for more info  https://issurvivor.com/2015/11/30/devcrpops/ )

This definition captures a lot of the benefits of the approach—In a limited amount of time, you will gain confidence that the system, team and individual, from all sides of the table, can quickly address requirements and productively demonstrate even a bit of limited value quickly. You will leave this event knowing this project is going to work—Or not. You will also know if you feel comfortable knowing if you and the team are ready for this.

The key challenge is having a “CRP” master or mistress of ceremonies that can explain the process, keep everybody on track, and eliminate confusion,  and maintain forward momentum. This person needs to show people how to use the system, describe the adaptations made, and be emotionally available for new users who are giving this their best go. There should be a completion goal each day, and frequent check-ins to make sure that people are staying on track. By definition, this is a form of Agile, and Agile is radically centered on the humans in the process.

Comments

|In: Industry Commentary|Last Updated:

Consider this a plea for the better angels of our nature to return. Or, in some cases, to show up for the first time.

This column over the years has criticized a certain meta consultant and its many worthy competitors in the way that they have tried to steer conversations when it comes to software selection.

I get it—There are a lot of choices out there for any business need you can think of, whether CRMs, HRMS, ERPs or more, and whether they live in the cloud or on premises. The field is getting more crowded by the day, and on a feature by feature checklist, there doesn’t seem to be much of a difference. If you are on the hook to make the choice, you really want to gather as much information as you can, in order to help your organization, and avoid difficult conversations later.

And given the industry’s ongoing convergence in capabilities, you might even hope that somebody can make the choice for you—and you can either take the credit or avoid the blame, depending on how the project turns out.

It seems like the safe way to address this concern is to hire a meta consultant or selection consultant to help you ascertain the fit, and give you recommendations. They can, and will give you recommendations, sometimes informed, and sometimes not so much. Some are quite good, and others can be a bit “Lazy”, dusting off the same RFP template and running you through a process, when, they likely already know the answer of what platform might actually be the best one for your organization.

How can you tell the difference between the two?

I think it is pretty easy, and not just because I play in this sandbox (truth in pundicizing: I’m not a disinterested commentator).

The major application suites are more or less at parity these days. Who aren’t at parity are the teams implementing the software. They’re not equal, and have much more to do with the success or failure of a project than the software.

And RFPs are not going to help in you determine who would work the best with you, understand your culture and your goals, and, indefinably but importantly, feel to you like a real partner.

If RFPs actually worked, selection consultants would already know what to offer you, based on the umpteen RFPs their firm has already conducted over the last 18 months. If they did work, why are there still difficult projects that selection consultants point to as part of their own sales pitch?

Experience has shown that software and implementation companies will put in mountains of work to TELL what they’d do, only to not be given the chance to actually SHOW how they might actually have a real advantage for a specific customer. After a decade or two of these cookie cutter RFPs, potentially amazing partners of yours kinda give up, and just copy and paste their answers into the next auto scoring excel spreadsheet that is emailed to them.

What’s the alternative? Dump the RFP, and get to know the people that you would be working with.

Choosing both a solution and an implementation partner to make it work has a lot in common with recruiting and hiring. That includes a key principle in the hiring game: Having applicants do the job in the interview.

This is the better solution for solution selection, too. It’s one we’ll flesh out over the next few weeks – to get to know the people who would actually implement the project, and ensure that you 1) feel like they understand you, and 2) can adequately explain, face to face, how they are going to help you implement the software in a way that will meet your goals. This comes down to communication, and your understanding of what the Partner can effectively promise and deliver to you.

You have every reason to be skeptical, and the selection consultant should encourage it. The best way to gain an understanding of the potential solution and implementation partner is to work with them.

More on what that looks like next week.

Comments