RFP Development – Iterative, Collaborative and Empowering

I’ve done my share of software and hardware procurements – not as many as some consultants – but enough to know my way around an RFP (Request for Proposal).  And the truth is that RFPs are really horrible. They are full of contract language that few people understand and, unfortunately, they are often loaded with requirements that the Library doesn’t understand; or worse, requirements that the vendors themselves don’t understand!

I’ve seen the same RFP issued by many different libraries. Some of these RFPs were actually created by the vendor and has a few gotcha requirements that ensure their competitors will get the boot.  I’ve also seen RFPs that have conflicting requirements – this happens when the Library doesn’t understand the requirements they’ve included.

But the development of an RFP has the opportunity to be an empowering experience for the library if it is done correctly. However, this requires leadership and time.  It’s not as simple as doing a couple focus groups and checking off the requirements from someone else’s RFP.

The leadership part is key.  As an organization, it is important to be clear about the reasons for considering new technology or a switch in software. Are you doing an ILS procurement because you have to migrate, or are you just checking to see if there’s something better out there? Is there a particular problem you need to solve?  If you are looking into RFID or materials handling….have you prioritized?  Is your number one goal to provide a better patron experience, improve security, or reduce staff workload? You need to know these things in order to ask the right questions and to evaluate the options. And someone has to be in charge of keeping track of the organization’s strategic goal – even when the process heads into the weeds – which happens pretty quickly.

For example, in order to write an effective RFP for RFID or materials handling, it is important that you understand the technology. This can mean a pretty steep learning curve for the people involved. In my experience, most libraries don’t know what they don’t know – which isn’t a good place to start. In the case of the ILS, it is less a learning curve than a big group effort because no one person really understands what is needed in an ILS. Circulation people know what they need but they have no clue what’s important to Catalogers – and vice versa. Even the System Administrator, who may be extremely knowledgeable about the current system, may not be aware of some of the ridiculous workarounds that some staff employ to make the system “work” for them.

A good requirements development process is iterative and collaborative:  define the organizational goal, define needs, learn what you need to know, redefine needs, learn more, refine needs. Then, finally, collaboratively narrow in on the truly critical requirements. All without losing track of the strategic goals of the organization.

Typically, a first pass at a set of requirements will describe the current system one way or another.  “The new system must do A, B, and C and should not do X, Y and X!”   It is important that you don’t stop there because there are many ways to meet a person’s needs with software (and technology), but without exposure to those options, how can you know?  So, learning about the different ways of doing things and helping staff open up their minds to new ways of getting their needs met is needed.  This sounds easy but it is a challenging process to get people to let go of their anxiety about doing things differently and to get comfortable with new ways of doing their work.  Visiting other libraries that have made the change you are considering can help:  from one ILS to another, from barcode to RFID, from a circulation desk to an automated check-in system.  As they see other ways of doing things, their minds may open up to new ideas. Using specific activities to reveal and then release constraining mental models is necessary.  Helping the staff envision where they want to end up at the end of the process is critical.

Ideally, some requirements will fall away, and the real priorities will emerge.  Others will morph into open-ended statements that give proposing vendor opportunities to offer up new solutions.

The final collaborative part is bringing the group together to differentiate between desirable and mandatory features. This is where a facilitated discussion is in order so that everyone has a chance to state what is most important to them and to learn more about the needs of people in other departments.  There may be conflicts but ultimately, the group has to come together around a set of minimum requirements. Done poorly, it is a process fraught with resentment. Done well, it builds stronger relationships across departments.  Ideally, the process gets to a place where everyone supports each other’s minimum requirements because it’s possible that one department’s favorite proposal will get rejected because of another department’s requirements.   For that reason, minimum requirements really should be minimal and they need to be critical as well.

Ultimately, a positive RFP development process involves paying attention to the long term goals of the organization as well as the short-term strategies.  It requires keeping an eye on the horizon but also paying attention to the minutia and technical details.  Oftentimes, it requires learning about a technology you know very little about but because the details matter, you need to take the time to learn.  There are lots of different reasons to choose one ILS over another or one automation vendor over another but what makes sense for you library isn’t necessarily the same as another’s. Pulling together key people and teasing out what matters in your library takes a commitment from management to provide strong leadership about the strategic elements and give staff the time they need to work together to learn more about one another’s needs, learn more about the technology they are evaluating, and then create a set of requirements that they understand so they are empowered to make an informed and educated decision that everyone supports.

This article originally appeared in Collaborative Librarianship (Volume 6, No. 1).