Geekly Articles each Day
📜 ⬆️ ⬇️

How to write RFP for software development


This article is intended for you, dear customers, future and present, ours and not ours. They say that the right question is half the answer. Properly written assignment by the customer is a guarantee of a good and accurate proposal from us, the developers, and in the end - a well-made project, on time, within budget and with high quality. This initial task assignment, intended to be sent to the developer, is called a request for proposal, or RFP (request for proposal).

For many years I have been working on software development projects. For 15 years, hundreds of requests for proposals of very different quality have passed through me. In many of them, I observe common problems. I will try - to summarize the main bottlenecks and give recommendations on how to avoid them in the future.

So, you have a task - to find a decent contractor for software development. To find the best, you decide to prepare and send a request for a proposal to a list of worthy companies, hold a tender, and finally make a choice. You opened a clean sheet in the Word and ... How to start?
')


Where to begin?



Describe in two or three paragraphs all important . From the goals, objectives, requirements, restrictions. Simple understandable human language. You will return to this block more than once in the course of writing a document in order to correct it, but it is very important to begin with it. And try to make it as compact and informative as possible.

Clearly formulate goals. When writing goals, remember two things:

  1. The goal of any activity lies outside the scope of this activity. That is, the purpose of developing the site is not to sell the product, but to increase the service for customers by providing another communication channel. The goal of developing a B2B system is not to create software for interacting with customers via the network, but to reduce costs and increase turnover through automation.
  2. The goal must be measurable. The goal may be attainable and final (“to double sales in 2016”), or it may just be a direction (to increase sales at least twice each year). But it is always important that it be measurable. For example, the goal “to ensure high customer loyalty to our brand” is strange - it’s not clear what “high” means, maybe it’s nothing now. And the goal of “Raising the level of brand loyalty” is more measurable, although to assess it, you need to do a couple of surveys - before implementation and after.

The formulation of a goal is sometimes a rather unpleasant task for those who are far from business but close to IT. But the exercise is very useful - at the same time there will be real interested persons from the business. Or will not be - then, perhaps, should not begin. Sometimes people reach this step and only on it they understand that they do not need the system. Probably, to abandon the project in time is a good decision ;-)

It’s very good if the goals are to be made hierarchical - from general to specific.

Specifically formulate the task . Tasks - this is what you need to do to achieve the goal. These are concrete works, the result of which will bring the company closer to the goal. This is a very important block, because in its absence these tasks have to be pulled out of the document according to different hints and nonstandards. Typically, tasks are listed in the “Make ...” list, “Develop ...”, “Train ...”

Well, if this list becomes a checklist for the progress of the project in the end. There should be no tasks that do not fight with goals. For example, the task “Develop a mobile application” may have the goal “To increase the conversion from a mobile channel from 0.5% to 1%”.

Very well, if the task turns out to be hierarchical. For example, you can divide the task “Develop Mobile Application” into “Develop Application Design”, “Develop Application”.

Somewhere in this moment you can think of a project name. There are tasks, goals - usually this is not difficult. It is better if it is as informative as possible, but at the same time short.

Further, I will assume that you know exactly what you want from the developed system or developer services (hereinafter, by developer we mean a software development company, and not an individual programmer). Let's look at the main topics related to the specific formulation of the problem. What is worth remembering when formulating the requirements?

Important points on the main content of the RFP


Share work and services . Works are aimed at obtaining a unique result. As a rule, before performing the work, the performer receives the task, and after the execution - reports. Services - regular, continuous activity. Services may consist of a set of jobs, but the result of providing services usually is progress. The customer assesses the progress, and decides to continue with the company with a theme with services or look for a new contractor. For work, the result is a product.

For example, if we are talking about SEO site optimization, hosting, technical support, then this is definitely a service. In this case, the requirements for the product may be requirements for SEO, requirements for hosting and requirements for maintainability. These requirements are aimed at creating a product ready to start with certain quality characteristics, but do not imply the performance of any work or services after the product is ready. If you need to pledge this, call it services and ask for a separate offer for support services or site development after it is launched.

Separate requirements for project development or project management from product requirements . This has more to do with the specifications than the RFP, but it also occurs quite often.

There is a fairly simple division of "duties": the technical task for the technical requirements for the product, the Charter and the work plan for the requirements for the process of creating a product. Any customer wish list can be easily attributed to one or the other.

Example - the requirement combines the development of, say, graphic design and its provision no later than 2 weeks from the beginning of the project. It is necessary to break it into two, leave one in the software requirements, and move the second to at least a separate section of the process requirements.


Separate functional and non-functional requirements . The difference between them is simple: non-functional requirements are requirements for the characteristics of the system, not for its functions.

To share the important from the unimportant, urgent from the non-urgent . Very often, in quite reasonable requirements, there is one which, in terms of labor costs, is comparable to the remaining ones and draws on the whole project. And it is not clear whether the client really needs this delivery calculation module with five integrations and finding the best ways, or this whim from the category “it would be nice if they did”. Set priorities.

To carry out restrictions in a separate section . It is very useful to separate the restrictions separately from the requirements. Sometimes it is not very obvious. For example, use as an Oracle database - requirement or restriction? The answer is simple: if it does not have a “parent” business requirement, then there is a limitation. Otherwise - the requirement. The business requirement must have the same link with the goal. For example, performance requirements, although non-functional, may have business requirements.

Also, the limitations fall, for example, the cost of "iron", which achieved the desired parameters for performance or reliability. Limitations indicate the budget framework or implementation timeframe, if you consider this important.

"What to do" and "how to do"


The request for proposals should, of course, be extremely accurate in talking about what is expected from the potential developer as a result.

A big mistake is to write such an RFP, which each of the developers will understand differently. Then the proposals from different developers in the end can not be compared.

Let's see why this happens. If you do not directly dictate the format to the contractor, then the evaluation of the development of custom software occurs to all developers as follows:

  • The developer reads your documents with a problem statement, i.e. receives an answer to the question "what to do . " For now, let's skip the fact that at this stage a lot of information about the real expectations of the customer is already lost.
  • The developer estimates the architecture and implementation , i.e. answers for himself the question "how to do . " I pay attention that usually this stage is not formalized in any way ..
  • The developer evaluates the work (“for how much”), which lead to the result (“what to do”) through the architecture and the implementation invented by him (“how to do”). At this stage, the estimate is born.
  • Developer submits estimate and plan. . The rest of the document is 90% composed of copy-paste and standard words. At best, he writes a little about the chosen approach.


As a result, you get an estimate that is derived from the developer's view of the implementation, which is not formalized anywhere.

At best, you can only compare time and cost estimates (“for how much”). Although it is possible and necessary to compare implementations expertly (“how to”), almost no one does.

Firstly, most likely, there is a specialist in your ranks who is able to understand all the details from a half-word - a rare bird. At the best, commercial offers contain hints of technical implementation.

Secondly, even if we assume that all the documents are well-developed and there are specialists in the company, a large amount of documentation is written on you, written in different styles in different languages, by different people, and often consisting of half of copy-paste. I have seen many good examples, but in general they are an exception to the rule.

Require verbal protection of sentences . Let the proposal be small, but the protection is necessarily oral. You will appreciate the level of specialists, not the level of documents. You will meet with those who will be a participant in your projects.

Pictures and schemes in commercial and technical offers are mostly copied from other offers. The most valuable schemes - drawn on a flipchart right at your meeting. The most valuable arguments are in response to unexpected questions.

Real people who wrote and painted everything that was sent to you may not work in the company for a long time. Meet the key experts before the project. Otherwise, you will be surprised to find that no one except sales has been involved in the preparation of the proposal.

How to compare different sentences? It turns out that according to the same requirements (“what to do”), different contractors come out with different implementations (“how to do”), and invented and evaluated “in a hurry.” In order to be able to compare the proposals of various contractors for formal criteria, you are asked to make an assessment of the labor costs (and / or cost) of individual requirements. This is found in almost every tender.

Assessment of individual requirements



A real project on custom development deals not so much with individual requirements as with the work packages prepared by the software architect and the project manager in response to the customer’s technical and business requirements. The process of composing and decomposing package requirements is a rather creative process, in some cases rather complex and slow. It is not always clear at the zero stage what set of work will be in the package, but it is often quite well understood which work packages will need to be provided for and evaluated.

For example, a work package may be a layout of templates, a separate package - a set of tasks for the feedback form, a separate package - testing. But it may be different: a work package is the task of programming the feedback form, its design, and its testing.

In the latter case, the work package is a scenario of using the system of the type “The buyer must be able to contact the administration by sending her a question and his contacts”. That is, in this case, the work package is a complete system unit, ready for use upon completion and implementation. In the first case, a work package is simply a grouping of tasks for a single type of work. This is quite useful for building a pipeline, when similar work is grouped together for the sake of development efficiency.

So, the unit of evaluation is the work package, i.e. a set of requirements / tasks that it makes sense to consider together, not one by one. And as I showed in the example above, splitting into packages can be done in various ways. Each contractor will do this partitioning in a convenient and familiar way.

Correctly evaluate not the requirements, but the work packages. Non-functional requirements (i.e. related to quality - performance, reliability) are especially difficult to evaluate separately, since they are not easy to separate into a separate work package

If you ask contractors to evaluate the requirements, not the work packages, then the majority will at best be evaluated by the method “from a rough assessment of all the work“ spreading ”according to the requirements in accordance with their estimated complexity”.

For example, requirements may duplicate each other, may imply common tasks, and may imply tasks that the customer has not been allocated to separate requirements, and not to do them - there will not be the desired result. As a result, the amount of labor costs for your requirements, although it will be the assessment of the project by the contractor, but will be “stretched” and “fitted”.

The division into work packages is carried out after the design, at least superficial, with the implementation, invented by the contractor. As I wrote above, there are many implementations (“how to do”) for the same requirements (“what to do”), and which of them will be chosen depends on the experience of the contractor, existing developments (including analytics), from preferred approaches.

But if each contractor groups the requirements in its own way, and, consequently, makes different assessments, then how to compare their proposals among themselves?

How to choose the best?

There is no universal answer to this question, but there is the closest one to the ideal.

Two projects instead of one


I propose to split the project into two successive stages: design and implementation , and conduct requests for proposals for each separately.

First, get proposals for design, make appointments to protect their proposals with contractors, choose the best contractor, get a design solution, pay him for it, and then put this set of documents into the second stage as a problem statement.

In this case, by the way, an interesting effect will work: the contractor knowingly knowing that his works will be opened at the next stage to his colleagues will be more scrupulous about the details.

So, we distinguish in this case two projects that are carried out sequentially:

Project â„–1. Design


It is divided into two major stages: "Collection and formalization of requirements" and "Development of a technical project . " The “Collecting and Formalizing Requirements” stage answers the question “what to do” and ends with a document including
  1. goals, objectives, business requirements
  2. functional requirements
  3. non-functional requirements
  4. system usage scenarios
  5. restrictions.


It also describes separately the set of services and requirements for them (quality level agreement) that the customer wants to receive.

At the stage “Development of a technical project”, the development of a set of documents that answer the question “how to do” is carried out:
  1. specific work
  2. job package partitioning
  3. used software
  4. intended server infrastructure
  5. testing methodology (load, integration)
  6. data migration approaches
  7. ... and much more depending on the specific project


The typical document at this stage is the “Technical Design” document.

It also develops a work plan and estimate from the contractor performing the project.

Project â„–2. Implementation

.
This stage can be more or less accurately estimated, having the result from stage 1. In the development process, the “how-to” approach will almost exactly change, so you should immediately plan to obtain documentation on the architecture of the system, which will be based on the Technical Design, but with corrections and changes.

Cost management


You may ask, what if the implementation of the results of the first stage would be unnecessarily expensive? Suddenly, we will carry out a paid design stage, according to which we will receive a document for which all contractors will give wild estimates?

For this, the estimates and the work plan from the contractor who won the first tender are in the results of the first stage. How to limit it in appetites? Put the maximum amount and / or effort and / or project duration in the RFP limits immediately. If the contractor does not feel strong, he will not participate in the design tender at all.

This two-phase approach also has the advantage of optimizing costs and reducing risks. Since your potential contractor initially knows that
  1. the client has signed up only for the design phase, and for the second phase he will need to fight, and that
  2. his document is likely to be relatively public in the second stage,

... he will be especially motivated to work well, it will be important for him to create a good impression and to do his work “perfectly well.”

Of course, you have the right not to announce the second tender, but to continue working with the first company further, if everything goes well.

Waterfall or Agile?


This question is raised by almost every customer. The project approach (“Waterfall”) is a predictable approach to development, when a technical project is first created, a work plan, and then work is performed on these sketches. The iterative approach (“Agile”) is a lot of very short, simple in structure projects, lasting 2-3 weeks. In an iterative approach, it is assumed that the customer is very involved in the process, he literally has to live with the team, and in case of failure to meet the deadlines, share risks with it. The project approach implies greater autonomy for the contractor - there is a risk of finding out that the contractor is unable to make the system too late.

There is a lot of information on the Internet comparing these two approaches, this topic is very holivar. Therefore, I will not repeat, just share a short tip:

Choose Agile if :

  • you personally and several of your colleagues are ready to give 80% -100% of your time to the project with full immersion
  • you have sufficient competence and you are ready to dive into the development together with the technicians,
  • you are ready to share the risks for meeting deadlines or for the low quality of the contractor’s work with you personally,
  • both you and the contractor understand that at the moment it’s normal not to collect the requirements, because they are not yet invented until the end, but work has to start, because the market, business, and all that



Choose Waterfall if:

  • you go to a relatively standard project that you have already done,
  • you quite well understand what you want now
  • you are not ready to give a significant part of your time to control and close communication with the technicians
  • it is important for you to know how much development will cost now, and it is important that this was a contractor’s headache, how to get quality into a limited budget
  • it is important for you to know when the development will be completed, and it is important that the contractor is financially responsible for disrupting the deadlines



Functional requirements



If to formulate functional requirements, even familiar ones, you do not resort to the help of specially trained people, try to follow the following simple rules:

Obvious and unverifiable can not write . It will save time for you and us. For example, it is not necessary to write in the requirements that the online store should be comfortable and modern, and the pages load quickly and easily.
Group requirements into sections by topic . Break groups into subgroups. Try to make the structure logical and understandable so that it is convenient to use.
Completeness . Try to maintain a sufficient depth of the requirements for the primary document.
Atomicity One requirement - one idea ..
Unambiguity . Avoid repetition and controversy. All working with him must understand him equally.
Without jargon . Try to use generally accepted vocabulary understandable to a wide audience.
Brevity Try to do a minimum of words. Remove all unnecessary and leave only the most important thing.
Testability Imagine that you have a ready-made system in front of you and you need to tick off your items. Can you check them out?


It is convenient to follow the following patterns when writing requirements:

  • The most common case is on behalf of users: “Requirement”: <User such and such> should be able to <action> <object> [ object / circumstance ]. Example: "The buyer (type of user) should be able to postpone (action) product (object) to the list of favorites (object / circumstance)." " The order manager must be able to invoice
  • From the “product face” : The product must [be able to] <action> <object / concept / refinement>. For example, “The order processing system must notify (action) the order manager when a new order is received
  • “Assumption” : <User such and such> should not <action> <object> [ object / circumstance ]. Example: “The buyer (user type) does not have to confirm (action) his order (object) through the call center (object / circumstance)”
  • "Characteristics of the object" : <Object> must have the following characteristics : (list) . Example: “ Order i> (object) should have the following characteristics: information about the user who made the order, delivery address, list of goods.”
  • Background (not user-initiated) processes : You need <action> <object> <clarification / circumstance>. Example: “ It is necessary to unload (action) orders (object) in ERP every hour ”
  • … and so on. The number of possible formulations is unlimited.


All objects and all users somewhere in one place in one place and give them a definition. In the example above, the “item” and “favorites list” objects should be described.

Services



Services are regular work performed on request or on schedule. Services about the process, about the regular delivery of measurable results, while the project involves one result - the product.

An important characteristic of services is progress. For example, a decrease in the number of incidents or an increase in presence in the search results. You pay mobile operators to expand the coverage and quality of mobile communications. Because, once having got into an uncertain reception zone in the center of Moscow, you will certainly ask yourself the question “why am I paying money?”. Same with your system. Demand for services to demonstrate progress, albeit small, but progress.

The proposal for services should be separate from the proposal for the implementation of design work.

Evaluation of the budget for services is a list of possible or mandatory regular works and methods of their evaluation. It is important to agree on the following key service parameters:

  • The order of interaction (how tasks are set, how fast a response is expected, what channels of communication)
  • Payment formula (monthly fee, payment on the fact, rates, prepayment, transfer from month to month)
  • What are the measurable results (reports, documents, code, layouts, external audits, etc.)
  • What guarantees (do they have financial responsibility, it is important to distinguish between “can” and “should”)
  • Penalties and penalties (actually, what are they, are they added up or not, how are they determined, what are the terms)



Document format



For a developer, it is very convenient when functional requirements are transmitted at least in a spreadsheet format, and others — non-functional; restrictions, goals, objectives, descriptions are written out in a Word or PDF document. Spreadsheets allow you to add questions and comments to requirements, statuses and labor costs, filter and group requirements. And if there is a need, it is much easier to transfer requirements from a spreadsheet to Word format than from unstructured text to Excel.

Ideally, the format of the requirements table should include the following columns:
  • The author . Initially, the “customer” is written everywhere. If the developer considers that some implicit requirements are specified, he adds new lines with the author “developer”
  • Section . Convenient to filter
  • Subsection Convenient to filter
  • Unique number requirements . Convenient for Excel formulas such as COUNT or SUMMESLIMN
  • Requirement text . In free form. No pictures. One paragraph.
  • Package of work, which includes the requirement . Filled by the developer.


Ideally, the contractor should wait for the completed table above, as well as sammari:
  • Work Package Name
  • Evaluation of the work package in h / h A developer has the right to split the assessment into types of work (see below). For example, separately highlighting the watch manager, analyst, developer, tester.
  • The number of requirements included in the package (for control, may be 0) . Optional. Calculated automatically through Excel formulas "ACCOUNT".


The developer can give free rein to each evaluation of the package into types of work with different rates of specialists so that these estimates can be converted into money by multiplying the hours by the rate.

What is intentionally not included in this article and why



The following points related to the preparation of requirements were not intentionally included in the article, since it was originally designed for non-professional analysts. If you are interested in the topic of developing requirements, then studying these additional topics will not be superfluous.

  • Traceability requirements: ideally, functional and non-functional should go back to business requirements, those to tasks, and tasks to goals. To build a system in which you will have everything so beautiful without the proper experience behind you is very difficult. But if there is a desire and opportunity, it is better to immediately organize the requirements into a hierarchy.
  • Ways to visualize business processes and relationships between objects : in many ways, the scheme is more eloquent than many words . For the description of business processes and relationships between data there are standards UML / Aris / IDEFx, BPMN, ERD, sequence diagrams, etc.


I didn’t write anything about Use Cases, since for RFP, this is a very heavy format.You can expect such a document on the basis of the results of the pre-project study, but it is necessary to do it as a primary description of requirements with caution. In addition, this approach requires specific analytic experience.

Conclusion



So, summing up all the above,
  • In RFP:
    • Formulate measurable business goals , why this development is being done
    • Formulate measurable tasks that need to be done to achieve the goal.
    • Make a separate request for services (support, hosting, SEO)
    • Take out a separate request for work (product creation, document, training)
    • According to the requirements:
      • Highlight the specific requirements for the development process
      • Highlight the specific requirements for the project management process

    • ,


    • , (1) (2)
    • , ( — )
    • ()
    • - ,

  • : , .
  • : , , , , , , . , .
  • , : Waterfall Agile
    • Agile: , , , ,
    • Waterfall: , , , , , , , ,




Aliyev Rauf,
Director of e-commerce TEAMIDEA (development on SAP hybris)

Source: https://habr.com/ru/post/269111/

More articles:


All Articles