A few good tips for the most efficient use of your web dev budget>
1. Requests for Proposals pay for themselves
The RFP document will be how the development team provides an estimate on both the work described in the document and the risk you represent as a client. Better RFP documents will result in a higher response rate, more accurate estimates, less time in meetings talking about the RFP, and less padding to account for risk.
The customer acquisition process is the most expensive operation for a custom development shop. Every lead that comes in the door represents a mix of opportunity, risk, and expense that development teams work very hard to mitigate. The good news is that you are the one with the money to spend, but to get the most for your money, you need to maximize your vendors’ opportunity and minimize their risk and expense.
Start your RFP with the the project working name, who to contact with questions, and how and where to submit the RFP to. Next, write a short, high-level project summary that includes what you want to do and how you will define success. Follow the project summary with a project timeline with a deadline for submitting proposals, a start time, and when you need the project completed. If you have any specific technical requirements, include them. If parts of the project are already completed or will be sourced to other vendors, make that clear as well.
Make sure each page of the RFP has a page number; this will save you time when going over the document in phone calls. Section headings also help to quickly steer conversations to the relevant portion of the document.
Focus the RFP on what needs to be done and avoid how it is going to get done. Sometime there is a temptation to get into details, but a decent web development team will quickly figure that out on their own. There are exceptions, but focusing on what to do and not how to do it is a good rule of thumb.
Pro Tip: A good RFP document can replace about half of the scope of work document your development team will write, which translates to even more cost savings for you
2. Start with a Minimum Viable Product
A Minimum Viable Product has just the features necessary to be deployed with a focus on the early adopters in your target demographic.
It is painful to cut away at a product you are passionate about; however, fewer features will result in a product that is easier for customers to use, an RFP that is easier to estimate, and a quicker time to market. Fortunately, web applications built by skilled professionals are generally easy to add on to. To communicate any features that you don’t want to be part of the current estimate but are likely to be in future releases, add a section for future considerations to make sure the estimated architecture will work with your future plans.
An example of a feature that is usually not needed for an MVP but will require architecture changes is Internationalization, or support for multiple languages. Internationalization requires a different database structure as well as a modifications to every place internationalized text is displayed.
Pro Tip: Carefully and realistically evaluating the priority of your required features will help the team meet your needs more efficiently.
3. Flowcharts Clearly Describe Processes
Every organization has a set of processes that are used to accomplish common goals. These processes can be broken down into tasks and decisions that result in a set number of outcomes. The most effective way of communicate processes is through a combination of ordered lists of text describing each step in the process and flowcharts.
If you don’t have Microsoft Visio to make your flowcharts, there are some excellent free alternatives available online:
When defining your processes, make sure to point out critical paths or parallel processes: Tasks that don’t depend on each other, so they can be done at the same time.
Flowcharts are only useful for describing processes and sometimes a sitemap. To describe what your product will actually do you’ll need to write some functional specifications.
4. Use Wireframes to describe your features
Wireframes are very simple drawings that define layout, features, & navigation. Wireframes do not define color schemes, typography, or other look & feel aspects of the site.
While a printed wireframe is needed for the RFP document if you can supplement this with an interactive wireframe with integrated notes you will have better results. My favorite tool for this is Axure. At $589, it’s not cheap, but there is a 30 day free trial that may suffice for one project. If you’d like some free online options, there are good ones, but you sacrifice features:
Smashing Magazine also did a excellent post on wireframe tools: 50 Free UI and Web Design Wireframing Kits, Resources and Source Files.
Functional specifications and wireframes are where the jump is made from a pure business or product management skillset to a task that requires specialized skills. If you don’t feel comfortable creating your own wireframes, it’s time to seek the help of a professional information architect.
To get the most from your wireframes add page numbers, notes, and a separate page to list any difference in the feature set in the wireframes and in any other planning document. Wireframes are a great tool for determining what features will be included and where they will live, but it’s easy to forget the project is on a budget. So once you’re done make sure the project in the wireframes is still the project in your budget. Page numbers are a really simple tool for keeping everyone on the same page. They are often forgotten, but make meetings go much smoother. Adding notes to the side of the page allows features to be better explained, reducing assumptions and rework.
Pro Tip: The professionalism of the documents you generate will strongly influence the way your business is perceived.
5. Evaluating The proposals
After submitting your request for proposal to a development team, expect a response within the same business day. The response will generally contain an introduction to the development team and a request for a question and answer session sometime within the next 24 to 48 hours.
Depending on how busy the team is, they should get a proposal to you within 5 days. The proposal will be the development team’s paraphrased understanding of your RFP and Q&A session. Developers will need to convert your functional specifications into a system-level feature list for the purpose of estimation. This is because several software systems are involved in any one page of a website.
After the features list, you will find an itemized hourly estimate. This will be grouped so that all dependencies for a given system are grouped into one line item. If you find the need to negotiate down any of these items, request more information on them and try to cut out minor features or clarify existing features. Generally, negotiating price is easiest if you are also cutting features.
The proposal should also contain a list of assumptions that describe dependencies and expectations that the development team has that you may or may not share. A common one is that IE6 is not supported; however, if you will depend on large corporate clients still using IE6, this may not be a good idea.
The customer really can benefit from input from an experienced web development professional. When you’re contracting professionals in an industry outside of your own, you need a team that’s going to keep you out of trouble by understanding the technical implications of your requirements and pro-actively pointing out new features or better ways of doing things.
- May 26 2010 – cleaned up markup, added some more tips for the wireframe section
Note: I originally published this post on another blog. It’s archived here because I think it’s useful, and I wanted to keep it updated with new tools and techniques. It is an original work created & owned by Robert Speer.