My business partner and I have been building websites for small businesses since we began our company. Out of the blue, we were approached by an HR company to provide a quote for a software project they are looking to have built. Most of our work to date has been front-end work, however, this is the kind of project I've been interested in working on.

Here's what they've described so far:

We are looking to create software that can generate employee handbooks for all 50 states? We are an HR Company and create custom handbooks. We need custom detailed software to house all policies and laws. Dropdowns, filters, and easy printing. We are looking for a user-friendly software to be developed and house customizable information to create our handbooks.

Please note, that I have done a fair amount of research on this subject. However, I know StackExchange is full of brilliant, qualified engineers who have gone through the process of consulting with clients and submitting project proposals. So I wanted to get your take on it.


Based on what they have described so far, what are good and essential questions that I should ask the potential client in order to estimate the scope of the project and adequately draft a proposal?

Additional Details

  • I assume there is a high likelihood of ongoing maintenance and hosting.
  • Our primary toolset is currently: Node, Express, HTML, CSS, JS, and a no-SQL database like DynamoDB (or MongoDB), AWS.
  • If they desire a standalone application we will use Electron.
  • 3
    "what is your budget?"
    – Ewan
    Oct 16, 2018 at 18:34
  • 1
    Given your lack of experience in this field, I would suggest an incremental delivery based on fairly small specific stories. Rather than try to deliver everything in one go, get them invested in the project and manage expectations. Create Policy, Edit Policy, Create Handbook, Add Policy to Handbook, Print handbook, etc. At each stage for each story, ask Who, What and Why. Firstly focus on the stories that will deliver the most value. Once you have them committed to the project they will grow increasingly confident in your promises and you will gain confidence in knowing the obstacles. Oct 16, 2018 at 18:59
  • "What level of confidence should we target in the estimates?" E.g. 95% confidence will be a much larger estimate, and 50% confidence will quite likely be wrong. Oct 16, 2018 at 19:48
  • @gnat yah well, i revised the question and its still on hold so I don't know what to tell you.
    – holaymolay
    Oct 17, 2018 at 15:23

1 Answer 1


This question is very broad. There are full books on this topic. Nevertheless, here a couple of ideas to start thinking.

Is the new system close to what you have build in the past ?

If the request for proposal (RFP) is for a project that is similar to what you usually do, then you shall focus your questions on what could be different, and make an estimate by analogy, based on similar projects that you've performed in the past.

Can you decompose the system in familiar parts ?

If the RFP is for something that you don't usually do, but you think that you could do it with the technology that you're used to, then you need to decompose the problem in smaller pieces. The idea is to ask questions how the client imagines the system, until you can envision how your product could look like and what parts you must deliver. Then, again, you can reason by analogy with similar parts build in the past. Attention: assembling the part also requires work.

So in your case, you may for example ask: how are the manuals currently prepared? who intervenes in the process to do what? is it only the production of the manuals or also the validation ? How are the manuals authored and how are they maintained ? What kind of differences are there from one state to the other ? how are the building blocks of the manuals (template document, stantard paragraphs, etc...) managed.

You also need to know how the client can contribute to the efforts: will they provide the content ? in which format ? can they provide the description of their current process/algorithm (even manual) will they do extensive testing, or will you have to organise quality insurance as well ?

And if it's still not clear or very uncertain ?

If you are very unsure about your offer, then, instead of making an offer for the whole system, you should consider to explain the uncertainties that you face (and others will face as well), and propose your customer to share risks with a phased offer.

A phased offer is the agile principle applied to commercial offers. So you make a first offer for delivering a basic product with a limited and well scoped set of features. After the first delivery, the customer will have the choice to continue or not. Then subsequent phases will deliver refinements of the initial product if the customer decides to continue.

Important remark: phased offers or non-phased offers is independent of the development lifecycle. So if you work in an agile manner, you would have several sprints before delivering the initial release, and subsequent phases could either be release by release or for a block of releases. But even if you have only one global offer, you'd be free to organise development in successive iterations.

Not the answer you're looking for? Browse other questions tagged or ask your own question.