Not project management technique, nor tools nor talent are proven to guarantee success. As a wise friend taught me, promise control is everything.
Simple rules that work:
- Every RFP is reviewed by a person on the technical staff who by practice and background can recognize features required and match them to development features required.
- Every item is recorded in a database with citations and a succinct technical response including a time estimate based on the feature type. It is a lie that all development is custom or new if there is a base product set. What is a new feature has to be evaluated not for it's value to the customer but for it's value to the base product.
- If marketing or contracts changes a bid based on that response, they are held to account in the review for bid/nobid. Do not bid a project that can compromise the rate of maintenance over the cost of new development (feature creep).
- Never bid what you cannot demo. IOW, if it isn't already under development, it is probably outside your base product strategy. A demo is not a fully-developed feature of necessity.
- Never commit to a feature that doesn't have value to at least 80% of your customers. NO one offs.
If you do not have a base product, you do not have a core market. You are creating custom one off software. This is a bad business to be in for the majority of technical businesses. That's your fault. The idea here is you should be in a market where you understand the customer's technical requirements to a depth that you can anticipate what they will need.
Use the RFP db to keep track of requests for a feature. When one customer asks, do your research. When two ask, put it on the list of items for possible development. When three ask, schedule it EVEN if you did not win the bid. You will.
Greed is the reason most projects fail in ANY business. Risk is the reason most businesses succeed if they manage it.
