January 18, 2010

Gather Thee Requirements Three

 Print This Post

Business journaling for me customarily serves to help my existing clients or prospective ones through some weighty issue or challenge. Today’s post will merely be cathartic in nature and may serve as the only way that I can slog through the rest of the morning, so please bear with me.

Getting called into an RFP (Request For Proposal) with very little information or requirements gathered is a commonplace enough event for technologists. An RFP is the chance for the service provider to deliver a summary of what sort of services they intend to deliver to the customer. Rarely will an RFP include pricing, as in this initial stage the service provider has not collected the Customer Requirements.

Apparently for the client in question it was not RFP time, it was RFQ (Request For Quote) time. They wanted to know soup to nuts what services would be provided for them and what it would cost plus or minus 10%. In order to perform such a task a service provider must have gathered together the Customer Requirements. Some people call them “Customer Spec” short for specification. Essentially the service provider has to have a good understanding of what the client wants in order to ensure that all of their basic requirements are met, and that most of their “would like to have’s” are at least addressed by the proposed solution.

This particular “emergency” RFQ was initiated by the customer as they wanted to know by 1:15PM how much “it all” would cost. The customer prefaced the conversation that he recently fired the last service provider for not delivering what he needed. The customer delivered a few printouts of screens in the ERP (Enterprise Resource Planning) application that was built by the prior service provider. The customer stated that it was “all wrong” and that he wanted things done differently. When asked for test data he said that he did not have any data or transactional maps that would guide a service provider in building the application, just a handful of utterly useless screenshots.

Dear Mr. Customer;

I so wanted to take part in your urgency today. You see I thrive on action, and it sounds to me like you needed some.

I understand that you are behind schedule and without any tool in place to do work. Your line of business is not a commonplace one, so it demands a level of customization that many would not understand. Your business size is not large enough for an enterprise solution, but it is big enough to demand some level of automation. You have been recently burnt by a prior service provider who did not understand what you needed, and only delivered a fraction of your un-documented requirements.

Please, please, please. Mr. Customer, gather thee requirements three.

1. Stated Budget. Before beginning any deep dive into what a customer wants, it is imperative to understand what size budget they are willing to allocate to a project. If in the clients mind they want to spend $2,500 on a solution, the service provider must not take the time and energy to deliver a $50,000 proposal. It serves no one to hold back on rough numbers. ERP solutions (for an example) often run in the 6 figure range so a customer expecting to receive one for a few grand can quickly be educated on what is commercially available and developmentally  feasible.
2. Key Functional Requirements. The customer should be able to tell you the top 10 things that they want their website/application/service to do and what work it should perform. A good service provider can then help them to force rank those deliverables and put rough estimates on each one.
3. Tell us how you plan to grow. Scalability is the ability of a provided technology to grow with the business. Businesses may have in mind to NEVER go above ‘X’ number of employees, or another stated level of size. Such notions should be taken into account by a service provider when planning for website/application/services. The life-cycle of the services provided should not be shorter than the median growth estimates of any line of business. As an example, you would not sell a two-seat vehicle to a young couple with plans in the next year to have a child. (Well unless you are one of those really BAD car salesman/service providers) Estimating your usage and growth are important for a service provider to factor into their equations.

There.. That wasn’t so bad was it? Providing a few key requirements can help to streamline the RFP/RFQ process as well as help to shield your business from financial or operational harm. As a service provider, we are here to make your business work. We are only happy doing what we do when YOUR business is more effective. Ability… CHECK, Urgency… CHECK, Requirements… Well, now you get the picture.

Posted in Web Design