Use Your Inner Geek to Save You Money

This is the third in a series of articles on Needs Analysis.

On the Geek Scale, where are you—a full-out, taped glasses, pocket protector 10? An iPod-using, Google-searching 4? Or maybe an "I don't even know how to turn ON a computer" 1? No matter where you are on this scale, you can bring out your inner geek to save yourself money on your project. (I'm assuming in this article that you will be using the system being discussed; if that's not the case, please translate.)

A good, detailed Request for Proposal (RFP) is critical to ensuring the proposals you receive can be compared apples to apples, as I discussed in the previous article in this series.

We sometimes get RFPs that have maybe half of the information we need to understand the project, yet it's not possible to ask questions of the potential client to really create a good proposal for them. In these cases, I feel like a surgeon in the operating room armed only with a roll of duct tape and a plastic spatula. We simply walk away from these situations—I don't enjoy guessing in a proposal, nor dealing with the heartburn of not meeting the client's expectations that were never in their RFP.

The central tenet to Needs Analysis/RFPs

If you put this one concept into practice, you will write a great RFP:

The more clearly you make your needs and wants, the more accurate your proposals will be.

If saving money is important, you'll be happiest in the end if you do your own Needs Analysis before creating your RFP. Consider the following guidelines in the context of the system you want created:

1. Who are you? The context in which the proposed system will be used is very helpful. What does your organization do? Who do you interact with? What product or service do you offer? Where have you been? Where are you going?
2. Who will use this system? Do you need a sexy, easy-to-use system for your clients? Or one that's powerful yet plain for you and your business partner? Do users need to be led by the hand, or do they pick up new systems quickly? How much training will be needed?
3. Who are the stakeholders and decision makers? This may seem redundant to the previous question—it's not. There are others involved besides the users, like bosses, board members, etc. Of particular interest is whether the programmer will have to deal with stakeholders who have varying levels of conflict with each other (my undergrad degree in Psychology comes in more handy than you might imagine).
4. What is your world like? What do you do in your job, specifically as related to the system you want? What pain are you attempting to end? Who isn't getting what they want? What do you want to improve or accomplish? Why do you what this now? Make sure you talk to a representative group that will use this system; you may understand your needs, but not theirs!
5. The big one: What do you want the system to do? You can't possibly get too detailed answering this question—I promise!
   1. Draw a flowchart of the system, if possible.
   2. List all of the tables and fields needed (example: PEOPLE [first, last, email], STORE [address, city, state, zip, phone]).
   3. If you want to replace a current system, print/take screenshots of the forms of your current system, and draw/write on them what would work better. Describe what doesn't work well and why.
   4. Good systems mirror the real world--define all of the real-world steps you go through. How will the system help you perform these steps? What automation would make your job easier?
   5. Who needs access to the information in this system? What security is needed? Define all of the roles for people who will interact with the system, and what they should/n't have access to.
   6. Imagine anything is possible—what would you have if you could have everything? You never know: something of high value may be simple/cheap to do...
   7. Think about EVERY input and output. Do you get information from other systems? People outside your organization? Does one form need information from two different people? Do you need specific reports? Labels? Do emails need to be sent? At what points in the process?

Consider this: often when I'm done performing a thorough Needs Analysis I understand very clearly the job of the pertinent person or people in the organization. By the time I complete the system, I am probably able to do 80 or 90% of their job (pertinent to the system). If you haven't spelled out ALL the ways this system will affect all users, you haven't put enough information in your RFP.

There are plenty of guides for writing a good RFP on the internet—you can find one in 10 seconds. However, those I've found tend to focus on specific questions, etc. My goal with this article is to put you in my head (watch out for sharp things, useless facts and bottomless pits) so that you understand the principles of performing a needs analysis.

Why should I work so hard writing an RFP for you?

Exactly, right? You're the customer, and the customer is king!

However, I can tell you that the less work you do, the more work your vendor will have to do in their Needs Analysis, which will require more of that king's ransom of gold to complete your project. Or, you will end up hiring someone who gives you an inaccurate proposal (spelled G-U-E-S-S). You will be much more likely to end up paying a lot more than you thought, because they didn't really understand your needs. Or perhaps the product you get won't work the way you want it to, or even at all. Yikes!

Companies who hire Pushing7 have a clear idea of how much their project will cost, and can set the priorities of features to adjust the final cost where desired. We're very used to having clients who rave about working with us, because they know we get them.

So, sit down and do a brain dump of everything related to the system you want created, starting with the questions above. Then take your clipboard and talk to others involved, asking lots and lots of questions. Have someone unfamiliar with the situation read it and give you feedback. Or we'd be happy to give you a free hour to review it and discuss your project.

Want someone to get you and what you want to accomplish? Drop me a note! Anyone who gives us an RFP with at least 90% of questions answered gets a free box of donuts!