Introduction: What happens before the IT project
In the world of information technology, day-to-day activities usually revolve around gathering requirements, use-case modeling, application architecture, development methodologies, macro design, micro design, development, testing, deployment, and other disciplines and activities in the software development life cycle. These all happen when a project is underway, and there has been a budget allocation by the customer to undertake an IT initiative.
What we frequently forget is the phase that precedes a software development project -- the activities that can transform a business opportunity into an IT initiative through a well-planned, well-executed response to a business proposal. This phase starts with the identification of an opportunity to address with an IT proposal. If you work for a systems integrator, a value-added reseller, an IT services company, a consulting firm, or a technology vendor, you are likely one of several firms in the running to meet a client's needs. If you identify yourself as one among them, you need to put together a proposal -- one that helps your business stakeholders clearly understand the dimensions of the IT project or one that convinces your client to work with you instead of some other service or technology provider.
Just like there is a methodology behind the software development life cycle, there are some key steps you can take when you develop a proposal to maximize the chances of success. This article spells out a process for the development of IT proposals. I take the viewpoint of a proposal leader and try to highlight the major steps that you can follow to ensure the development of a high-quality proposal. What I have to say pertains mostly to project plans written by service and technology providers -- companies and individuals who deliver IT services and products to other companies. However, much of the guidance offered here could be made applicable to teams developing IT project proposals within their own companies.
Create a proposal plan
Developing a response for a request for proposal (RFP) requires a well-thought-out execution plan for developing the proposal itself. Hence, the first step is to create a plan to guide the successful execution of the project proposal. The proposal plan is like any other plan and has a set of high-level activities that are broken down into a set of tasks. It might also include a check list of activities that need to be undertaken for the proposal process to be considered complete. Milestones are defined at critical execution points and key roles for meeting each milestone are identified and assigned. The proposal plan needs to be shared with the business opportunity owner, who provides feedback that you incorporate before the plan is finalized.
Later on in the article, you will find an entire section dedicated toward putting a simple and robust document management system in place for the effective management and versioning of all the proposal-related documents. It is worthwhile mentioning here that the usage of such a document management system can be initiated and demonstrated by placing at least the first two documents -- the RFP document and the proposal plan into the document repository.
Finance and budgeting
Several financial steps need to be undertaken early on in the process, as well. The activities mentioned in this section assists in the identification of the money that your firm is willing to spend to develop a proposal, the basis of which is an initial estimate of how much the proposed IT project may cost. So one of the first steps you must undertake is to bring all your experience to bear in determining a high-level estimate of how much the proposed project will cost the client, and what your margin on that project will be.
Once you have that high-level project cost and margin estimate, defining the budget for the development of the proposal is a crucial early step. Remember, your team will be spending time on the proposal alone, and you need to understand how much it will cost simply to assemble the proposal to be sure it is worth your while and to set a limit for how much time you will spend on the proposal. A thorough understanding of the RFP is the first step in trying to assess the complexity of developing a proposal that realizes the requirements illustrated in the RFP document. At the same time, assessing the complexity of the solution will help you come up with a high-level estimate on the price of the solution that you will propose to the client.
Performing a credit check on the client to determine its financial condition is a safe practice to undertake at this point. Although the frequency and mode of client payment is usually addressed in the "terms and conditions" section of a proposal, you want to be sure that the client has the ability to meet its financial commitments. First off, there is an initial period at the start of an IT project when the client makes no payment, and you need to assure yourself that your investment will be recouped. The salaries of the team members on the ground during project execution needs to be paid by the consulting firm until payments start flowing and there is a constant revenue flow. This step is similar to what happens to an individual seeking to obtain a personal loan from a financial institution. The financial institution performs a credit check on the individual requesting the loan as assurance that the individual has the financial capability to repay the loan. A similar credit check needs to be performed on the client to assess their financial viability to sustain the payment for the project. This can be a show stopper, and hence it should be a standard practice to perform a client credit check before going further with proposal development. Sometimes it is also standard practice for the consulting company to collect an up-front payment upon contract signing just to assure positive cash flow.
Another critical aspect of budgeting is determining the amount of sales opportunity money that can be spent in the development of this proposal. Every consulting company has a sales plan for business opportunity development and determine policies for how much can be spent on proposal development even when a proposal does not result in a contract. The opportunity investment set aside for the team for proposal development is usually a percentage of the total price that is estimated to be quoted to the client. Some companies even identify an amount of the proposal budget to set aside, again to identify a minimum sales opportunity cost. For example, if the total estimated opportunity value of the deal is $2 million (USD), and the percentage set aside for a typical opportunity development in a consulting firm is 3%, then the total budget for proposal development is $60,000. Based on typical company sales policies, a cushion factor of 15% of the proposal budget is also set aside, which in this case would be $9,000. Defining this budget for the proposal development is critical as it dictates the amount of resources that can be used to constitute the proposal team and the amount of time they can spend on the proposal even if the proposal does not result in a contract. This information is then used in the next major step in the process -- identification of the team.
Identify your team
Next, and closely related to what you have just done, you need to identify the team that will develop the proposal response. At the very onset, a proposal manager needs to identify the exact IT skill sets required to develop the proposal. For example, if it is an integration-heavy initiative, it's imperative that an integration architect join the team. If the project is mostly about performing a hardware upgrade, then the proposal team needs to include an infrastructure architect.
However, there are certain roles that are critical and independent of the particularities of the project. These roles must be identified and proper resources identified to fill each role. Essentially, the first step is to create the resource model and assign specific resources to fulfill the roles and form the proposal team. Some of the roles that are absolutely necessary are:
- Proposal manager (project lead) -- Leads the overall proposal and its management.
- Technical lead -- Leads the delivery of the technical solution. Appoints the proper technical resources (for example, application architect, integration architect, infrastructure architect, etc.).
- Pricing lead -- Assists in coming up with the final price for the proposed solution. The solution may involve consulting services and hardware and software products. All these pricing components are calculated and provided as a part of the final proposal. The tax components of the overall prices are also identified by the pricing lead.
- Quality and risk management (QRM) lead -- Conducts the quality assurance assessment of the proposal. This person ensures that risks involved in delivering the solution are identified and a contingency plan put in place to mitigate risk. This person may also involve a technical subject matter expert (SME) to validate consistency, completeness, and feasibility of the technical solution that is proposed. Without the final approval of the QRM lead, a proposal cannot be formally submitted to the client.
- Resource manager -- Assists in identifying the resources that will execute the plan spelled out in the proposal. In complex engagements it may require a global delivery model to build the team that executes the project, where resources are pulled in from geographically dispersed departments. The resource manager manages and coordinates activities with the global teams.
- Proposal reviewers -- Review all aspects of the proposal for thoroughness, consistency, and quality. This may be the other team members just identified or it may include others, as well.
As soon as the key roles for the team are identified and people assigned to each role, it is imperative to distribute a note to the team so that each of them knows exactly what role they are supposed to perform as well as the other members of the team and the roles they play. The review team also needs to be informed when they can expect to see versions of the proposal so that they can anticipate when they will need to provide feedback. In large companies where many proposals are developed simultaneously, review personnel may be hard pressed to allocate the proper time to a given proposal unless they are given a general timeframe of when to expect review requests in advance of receiving the proposals.
Once the proposal plan is defined, the financing and budgeting details worked out, and members of the proposal team identified, teams usually start putting their ideas down into proposal documents. While brainstorming and jotting down of ideas and notes is very important to shape the final solution, different team members often use different writing styles and even different document formats to start writing their portions of the proposal. With increasing deadline pressure, team members often feel they do not have time to comply with a single format and style.
Although it may not seem very critical, my experience shows that it is very important to standardize writing styles and document formats. This becomes even more important when multiple team members update a single document, often simultaneously. The proposal leader needs to identify a document template to be used for creating the proposal and needs to assure that team members adhere to the template. The team also needs to agree upon what needs to be included in the final proposal and customize the template based on that agreement.
The format of the final deliverable (a Word® document or PowerPoint presentation, for example) must also be decided. It may seem quite innocuous early in the process, if members of the team use different fonts, type size, colors, and styles. But by the end of the process, this can cause problems, putting the onus on the proposal leader or another team member to spend an inordinate amount of time during the last moments synchronizing the entire document into a single format and style. It is a matter of best practice to standardize the font, colors, styles, etc. at the very onset of the deliverable creation process and impress on the team members the need for strict compliance.
Another important activity at this stage is to create a central database or other repository to store and manage proposal-based documents. The repository will form the source for all developing documents, reference materials, project plans, customer materials, and any other relevant materials needed for the development of the final proposal. It is easy to identify some categories -- for example, customer reference materials, project plan, and proposal deliverables -- that will assist in effective management and versioning of the documents. With documents being updated daily by multiple team members -- even hourly as the deadline for submission comes closer -- the importance of using a version control system cannot be overemphasized.
There have been many instances in which major, well-written portions of proposals are lost during the merging of multiple versions composed by multiple team members. Using a simple and elegant version control system, that (one hopes) does not add the extra overhead of a steep learning curve is absolutely essential to the proper management of deliverables in a team environment.
Remember, sometimes proposal teams are scattered around the globe. Standardizing on a document template and format and using a version control system becomes that much more important for distributed, virtual teams.
And, of course, consistent and well-structured documents are much more impressive and carry with them a sense of professionalism.
Technical solution development
The crux of the proposal is spelling out the actual IT solution that will meet the requirements stated in the RFP. To arrive at this solution, the team spells out specifics that address the problem statement, either as defined by the RFP or as deemed to be the most appropriate after subsequent discussions with the client stakeholders.The validity of your proposed solution in the customer environment and its viability for implementation according to a reasonable, acceptable cost are usually the driving factors behind the client choosing your proposal over others. A well-architected solution is thus of prime importance. Coming up with this solution is the next step in the process of developing a good proposal.
The technical leader needs to assess and understand the problem statement as clearly as possible. Often the technical leader determines that one does not need to answer the RFP exactly the way it is stated, that it makes more sense to propose a solution that, experience suggests, would be a more viable approach to solving the customer problem. Such a decision is taken by the technical leader in conjunction with the proposal leader and in concurrence with the business opportunity owner.
The technical leader must also be experienced enough to assess the specific skill sets that will be required to define the overall solution. This depends on the nature of the desired solution. Some proposals may be for a hardware upgrade, some may be for a porting of an application suite onto a new software stack, while another may be a purely consulting solution to design, develop, and deploy an application that has a given set of business requirements to fulfill. A technical leader may appoint an application architect in cases calling for full software development or choose to bring in an infrastructure architect if the proposal revolves around a hardware upgrade, for example from Sun Sparc to IBM pSeries. Often the proposal scope is multidimensional, wherein the customer expects both a software product recommendation as well as consulting expertise to develop an end-to-end application. In these scenarios, the technical lead may use both an application architect and a product specialist.
The length of involvement of these experts is dependent on the complexity of the solution; their involvement may be either full or part time. Since the appointment of addition team members is contingent on the total budget allocated for the proposal development, the proposal lead needs to be consulted before assigning additional resources.
Another key input to the solution creation is harvesting of existing assets; that is, previous proposals for similar customer scenarios. Actual solutions that are harvested at the end of client engagements also provide very useful assets that can be leveraged to assist in the creation of the technical solution.
Often the technical team needs a lot more information than what is provided in the RFP before framing a solution. The technical leader works with the proposal lead to identify those client personnel from whom to obtain more information. The team conducts the required number of brainstorming sessions to come up with a list of crisp, well-articulated questions, which are then consolidated and sent to the proposal lead who then forwards them to the client contacts.
It is the job of the proposal lead to follow up with key client representatives to get timely responses. This process can be iterative in nature and can occur multiple times until the technical team feels that they have enough information to help them create the solution. Time is critical and hence, the quicker the questions are resolved, the more likely the proposal team is to stick to its plan for developing the proposal. Executing the communication with the client stakeholders through the proposal leader is usually the best practice for expediting issue resolution.
The level of details offered in the technical solution should be carefully controlled. On one hand, it is pointless to provide a solution that is so high level that the customer fails to comprehend and develop confidence in you. On the other, care should be exercised so that you don't provide so much detail that you give away intellectual capital or an in-depth exposition of the solution. Although doing so is very unethical, it is not unknown for a client to take details of a solution from one proposal to another bidder and ask for a similar solution at a lesser price.
That said, a high-level solution architecture or design must be provided as a part of the technical solution. For each of the design artifacts presented in the solution, there must be a clearly articulated description of its characteristics and how it assists in realizing the end goal. A high-level project plan with clearly defined high-level activities and milestones must also be provided. Identifying specific activities and assigning them to roles on the team demonstrates that you have a deep understanding of the client problem and how to solve it.
The solution should also demonstrate its differentiating capabilities and uniqueness. This will help make a positive impression on the client and may ultimately be the determining factor behind the client's decision to go with your proposal or someone else's. Keeping to a simple and elegant solution is usually preferred to a complex, esoteric solution that is difficult for the client to understand. It is essential to keep the client's background in mind while coming up with the solution.
A critical aspect of a technical solution is an explanation of the deliverables that are produced at each project milestone. Milestone deliverables are the most commonly used mechanisms to define exit criteria for each phase of work. The deliverables can be in the form of documents (for example, solution architectures, best practice guidelines, design models, project plans, user interface designs, and so on), or they can be in the form of executable code binaries. Deliverables can even be the actual deployment of a system on a testing environment or on a production environment. Of course, you strive to produce the deliverables on time and within budget, using them as exit criteria and tying payments to successful completion of the milestones.
A critical part of the proposal development process is to identify the resources to staff the project. As the proposed solution develops and the team gains deeper insight into the solution building blocks, the technical leader and team members need to understand the resources required to implement the solution during different phases of a project execution. The project plan created in the previous step and the roles identified for each activity help identify the skill sets and number of resources required.
For example, a project to help the client come up with an enterprise strategy and architecture will require mainly a mix of enterprise architects, application architects, and infrastructure architectures. On the other hand, a project that requires complete software development following a typical software development life cycle (that is, solution architecture, then macro design, micro design, build, test, and deploy phases), will require a broader team including architects, designers, developers, system testers, and more.
You also need to determine the number of resources needed in each role. To do this, you need to consider, among other things, the following factors:
- The time needed to complete each phase of the project, as well as the complete timeline for the project, broken down into milestones
- The overall budget for the project
Based on these two primary factors, you can develop a time-to-role matrix. This matrix helps you define how much time is required for a specific role to complete its tasks. This unit is also known as a full-time equivalent (FTE). What comes out of this exercise is the identification of the number of FTEs per role that is required to execute the project within the given timeline. The number of FTEs per role is then provided as input to the resource manager.
The resource manager takes the number of FTEs per role to help determine staffing. The resource manager should have full visibility into the availability of consultants during the expected time frame of the project. It is the responsibility of the resource manager to identify the right resources and ensure that they will be available for the project. While the ideal situation is to be able to lock down the exact resources for the project, it is not always realistic to attain that goal. It is highly probable that the ideal resource is engaged in another project and is not going to be available at the exact moment of need. In such cases, you need to identify the best alternative resource. Sometimes, the proposal manager provides a disclaimer that the actual resources may be swapped based on when the project begins.
Global companies with a distributed work force present interesting staffing choices to the resource manager. Global resource staffing is becoming a common practice in situations where the price for the proposal exceeds what a bidder gauges the client may have budgeted for a project. Resource costs can vary between countries of operation. Resources can be obtained from less expensive countries to reduce project cost rate. This is often called a blended rate model, where the cost of resources is blended based on resource costs in different countries. The blended rate model is a common practice for large, globally distributed organizations.
Procurement practices provide another creative option for resource staffing. Many companies have corporate partners who provide skilled consultants at a previously negotiated rate. Usually, the regular consulting rate of employees is higher than the contracted rates of contractors from the corporate partners. The resource manager can look at staffing resources for a project from one or more contracting companies, where less-expensive, negotiated consulting rates can keep project costs lower.
The resource manager uses available options along with the input provided by the proposal team to come up with the right resources to staff the project. The proposal response document includes this resource model along with names of candidates and their curriculum vitae.
Quality assurance approval
Quality assurance review is one of the critical steps in the proposal development effort. Without the approval of the quality assurance team a proposal should never be delivered to the client. It is the responsibility of the proposal leader to provide an initial draft of the developing solution to the quality assurance (QA) team.
In typical proposals at least two QA personnel perform the review. The QA personnel are not a part of the team that develops the proposal. This is done to prevent bias of QA reviewers toward the solution being proposed. As a result, most companies have risk management teams whose personnel provide QA reviews.
The first person to review the project is the quality and risk management (QRM) lead, who focuses on the risks associated with the proposal and its subsequent mitigation. It is standard practice for the proposal team to create a risk assessment of the project and provide risk mitigation strategies for high-risk areas. The team should also provide an overall risk rating as a part of the risk assessment. The risk assessment information is shared with the QRM lead who then assesses the risk for the bidding company in executing the project. If the risk level for the project is not acceptable as determined by the company policies of risk management, the QRM leader informs the proposal team that the risk is too high and that measures should be taken to mitigate the risk. He also suggests risk mitigation strategies so as to reduce the overall risk for the project.
The second reviewer is often the technical and delivery assurance (TDA) leader. The TDA ensures that the scope of the proposed solution has realistic chances of being met according to the time, cost, and resource identified in the proposal. This person also ensures that the proper resources for each activity in the solution plan are identified. The TDA person also ensures that the proposed solution is communicated in a manner that will be easily understood by the client. To that end, he or she may assist in determining the correct level of solution details that should be provided to the client.
The proposal is shared with the QA team as early in the proposal development cycle as possible. It is very typical practice for a proposal to go through multiple iterations with refinements at each stage before QA personnel provide their approval.
Pricing is one of the most complex proposal development processes. The price is a critical factor that either makes or breaks a deal being won. But the most frequent challenge that is faced in a proposal is to keep the price within a reasonable range. Often, a price range needs to be set between the best, most sophisticated solution and a less elaborate, but more affordable one. Multiple experiences in these kinds of situations have convinced me that proposal teams often resort to proposing a less than ideal solution because of pricing concerns.
In many proposal development efforts, the price of the proposed solution exceeds the projected, estimated price set at the start of the process. It may seem reasonable to the team to quote that price as part of the proposal. However, often the team feels they need to bring the price down, and in doing so, they have a few options to evaluate.
The team's first option is to reevaluate the resources proposed to deliver the solution. The team takes a closer look at the project plan and identifies opportunities to consolidate activities or assign additional activities to fewer resources. These options can help to bring down the price.
If a project can employ global resources (see Resource staffing) using a blended cost rate, this can have a significant impact on the cost. Sometimes, replacing a single higher rate consulting resource with multiple lower rate resources can also bring down the proposal price.
Often, the proposal includes consulting services along with either software products or hardware equipment, In these situations, the proposal team can provide itemized pricing. Knowing that the client can choose products or equipment from one vendor and consulting services from another, proposal teams often itemize these prices alongside a single, consolidated price for both products and services. The consolidated price often provides an attractive discount. This can be beneficial to both parties: The client spends less money and the products/services provider gets more business. The discount for the integrated price is usually determined by the pricing leader, who works closely with the company sales force.
Tax implications need to be considered when you use a global resource model. Corporate tax rates varies from country to country. Also, personal tax rates vary for consultants when they work in countries other than the ones where they usually pay income taxes. Consultants with temporary work permits to work extended periods of time in countries other than their originating countries may need to pay taxes in both countries. In such cases the consultants need to be reimbursed for the extra taxes they end up paying. Many companies factor this into the overall price of the contract and the pricing lead needs to calculate this amount.
There can be many other factors that ultimately define the final price for the bid. The ones mentioned here are the most common ones and by no means form an exhaustive list.
Terms and conditions, assumptions
It is also critical that the proposal include a clear, precise articulation of the proposal terms and conditions as well as the assumptions made while developing the proposal. It is the job of the proposal leader to ensure that these are represented properly in the proposal deliverable.
The terms and conditions, often called Ts & Cs, usually refer to legal implications of the contract. The proposal should clearly mention the terms and conditions and legal bindings that will apply once the contract is signed. It should also precisely state conditions under which the contract may be invalidated by both parties, the client as well as the vendor. In most cases your legal department will provide you a standard template for Ts & Cs is that you can customize with proper names, dates, and particulars of your project for inclusion in the proposal.
Terms and conditions usually include a detailed client payment schedule, usually prepared by the sales team. Often the first payment by the client is not made until a few months into the project. Payments are typically milestone driven; that is, the client pays only upon the completion of mutually agreed project milestones. In some large, long-running, complex engagements with infrequent milestones, payments may be scheduled on a monthly or a quarterly basis. Also, milestone payments are used for fixed price projects. For time and material projects, payments are usually made on a monthly basis based on actual effort and expenses.
You need to spell out the assumptions made during proposal development in a separate section of the proposal document. This can help reduce the risk of the project and may also reduce resource requirements, a combination of which can bring down the price of the bid. The most critical assumption you need to describe is the level of effort and level of support that is assumed to be provided by the client as a part of the project execution. Some common assumptions around level of effort participation from the client include the following:
- Stakeholder involvement in making executive project decisions.
- Dedicated client staff member to address questions and clarify doubts.
- An organizational structure that supports escalation and speedy resolution of issues.
- Timely client follow through on their project deliverables.
- Timely client reviews and approval of business and technical solutions before implementation takes place.
- Sufficient client resources to complete the project, as defined in the project plan.
- Office space and equipment for vendor consultants to perform their daily work.
This list is not an exhaustive one by any means, and actual assumptions vary from proposal to proposal.
Last, but not least, it is the job of the proposal manager to ensure that the proposal development is brought to a close. All the activities in the proposal plan should be completed. If the proposal leader has prepared a check list of activities (as suggested in the Create a proposal plan section), the leader should ensure that all the items in the checklist are completed to his or her satisfaction. Obtaining final approval from the QRM leader is absolutely critical to marking the successful completion of the tasks.
Once completed, the final version of the proposal is sent to the business opportunity owner to get his consent before it is submitted to the client. You should professionally print and bind the final bid package before officially delivering it to the client, preferably in person. Obtain an official signature from the client acknowledging the receipt of the proposal; most RFPs include a date of expiration, so this signature can establish that you completed the proposal before that date. In many cases, the proposal manager signs off on the successful completion of the proposal development process and marks it closed in some opportunity development repository.
Summary: Keeping the bottom line healthy
This article points out ten essential steps that need to be undertaken in a typical proposal development process to help maximize the chances of success of the proposal. There may be other steps to follow in creating a proposal, but following the ten described here will help you create a successful proposal.
Creating high-quality proposal responses is a critical step in demonstrating the ability, strength, and professionalism of a vendor in responding to a client's RFP. The bottom line of a company is determined by constant positive cash flow created by successfully carrying out client engagements. The more engagements signed, the stronger the vendor's stock price, value, and demand in the market place. Creating a sustainable and well-structured process around proposal development is one strategy that can help you continue to win project bids and keep cash flowing to your bottom line. Those who have mastered this art are ahead in the race toward gaining market share.
The author would like to extend a personal thanks to his colleague, Sangravee Vipulakom (Vicky), who went to so much effort to tirelessly review the content as many times as requested. Her experience and deep insight has helped the author add many finer points which he admits would have been otherwise missed. (Thank you, Vicky!!!) Heartfelt thanks also go to Protik Mukherjee, whose assistance went a long way in helping to make this happen. And, last but never least, the author thanks Sankar Singha, friend and colleague, whose critical mind helped him to go that extra yard to explain the concepts and steps much more precisely.
- In the Architecture area on developerWorks, get the resources you need to advance your skills in the architecture arena.
- Browse the technology bookstore for books on these and other technical topics.
- Stay current with developerWorks technical events and webcasts.
Get products and technologies
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- Participate in the discussion forum.
- Check out developerWorks blogs and get involved in the developerWorks community.