Building Trust in a World without RFPs

Chris Rowe // October 2014

If you are going to invest the time and money it takes to build a high quality web project and you don’t have an internal team of developers to do it, the first thing you have to do is find an external team that you can work with. A big part of selecting a team is developing a level of trust between the client and the development partner. Sometimes this can be done quickly, by getting a recommendation from a friend or colleague that you trust, but more often it takes time and some work.

In the ancient history of web development one of the most common ways to build a website started with a Request for Proposal (RFP). This made for a clearly defined process for building trust.

Building trust with a RFP

Step one - The client writes the RFP

By writing down everything that they wanted to get done, in as much detail as they could, the client was able to feel confident that the development partner knew what they were going to be asked to do. This is a very important part of trust, since without good communication and clear expectations, it is easy for a project to head in the wrong direction

Step two - The development partner responds to the RFP

When a development partner responds to a RFP, they are confirming that they are clear about what needs to be built. Often it also includes a detailed plan for the project, as well as a budget. Assuming that this is the proposal that is selected, you now have a clear agreement by both sides on project scope. On paper this is a good starting place to build trust, but in practice it can lead to some big problems. The largest issue usually being that there is very little interaction between the client and the development partner up until this point

Step three - Building the site

Now the real work begins. In most cases, this is where the collaboration really starts. The RFP does not contain everything the development partner needs know in order to build a website. If the client changes their mind about what they want or need since they wrote the RFP, this needs to be communicated. While thousands of sites have been successfully built this way, it can feel like the time and energy spent working on the RFP before starting the collaboration was somewhat wasted. Or at least it could have been better used had the client and development partner started working together from the beginning to define the project.

Building trust the Agile way

Step one - The client picks a development partner

Without the aid of the RFP process, this can sometimes be difficult for the client, who has to base their decision on the development partner’s portfolio and references. The development partner also has a say in what projects to take. It is not in the development partner’s best interest to take on a project that is likely to not go well, so the client does not have to carry all of the burden here.

Step two - The client and development partner define the scope of the project together

While the client will most certainly come to the table with ideas about what they want to build, it is much earlier in the ideation process. The idea is to minimize the amount of time spent by the client and the development partner before building the site. The earlier the collaboration starts, the more chance the development partner has to learn about the client’s needs.

Step three - Building the site

Often times the development partner can start building before all the features are fully fleshed out. Sharing early prototypes with clients can be the best way for them to learn what they really need. During construction, the client can provide input on an ongoing basis and since the plan was created together, it is easier for the development partner to understand the motivation for the change and get behind it.

Conclusion

While more and more projects are getting built without a RFP, these projects are still out there. It is almost like two separate worlds; The development partners that respond to RFPs, and the ones that don’t. To be clear, taking the agile approach is not a shortcut. You still have to do the hard work of defining the goals of a project and documenting each feature in detail.

The big difference is that you can get help. Clients don’t have to know how to best achieve their goals. Instead they can ask the development partner, who are the experts are in the technology, how to best use it. Likewise, the development partner needs to know what is important to the users of the site and the client often has the best understanding of this. Through early and close collaboration, the process of defining a project can be more productive and lead to a better site in the end.

A note on cost:

The RFP process often is linked to fixed bid pricing. While this is appealing to clients who want to know how much a project will cost, the constraints it poses on doing all your planning up front creates problems later on.

When using Agile with external development teams, you still have to estimate all the known work up front, so the client can budget for the work. The difference is that as the needs of the project get refined throughout the development process, the focus can be more on meeting the changing goals of the site, than on an outdated RFP and change orders.

Filed under: