March 3, 2017

The do's and don'ts of specifying projects

Some time ago Eagle Genomics published a white paper on outsourcing bioinformatics, which was well received at the time. I thought now would be a good time to update this by providing a list of things to watch out for when specifying a bioinformatics project - equally applicable when working with internal developers as to outsourcing to an external solutions provider such as Eagle.

1. Create mock-up user interfaces and include them in the spec before the project reaches the quotation/estimation stage. In most projects a lot of the work is related to the user interface and not to the business logic, and a seemingly minor change request late into the development process can seriously impact on delivery deadlines and costs.

2. Don't assume that the developer will know every detail about your field or the tools that you are asking them to use. They'll do their best, but unless you specify exactly what you want, you could be in for a surprise later and wonder why the developer didn't consider including something that to you seemed obvious. 

3. Similarly, don't expect to get a fully-detailed spec ready before development starts. Bioinformatics projects often change and it is important to get key details right and leave minor ones for later. Good developers will know what is key and what is minor and they'll know the right questions to ask to discover the hidden but obvious features - as per the previous two tips. Get it wrong, and you're in for a headache.

4. Sign-off the specs, especially any relating to user interfaces, with your senior management and your end-users before starting any work. Last minute disapproval from your boss is frustratingly impossible to do anything about if the project has got too far down the line to be able to change direction.

5. Read the statement of work (SoW) carefully before accepting a quote and signing a contract. Ensure it really meets your needs. Don't expect to be able to add new features or to significantly modify any existing features that the SoW specifies without incurring extra cost or impacting on the delivery timelines. 

6. Don't assume that the person writing the SoW has just replicated verbatim what you told them during the requirements gathering process - you really do need to check and make sure! A good SoW will be written in language that you, the customer, understands. If there's anything it doesn't mention or that you don't understand, ask for it to be clarified. Don't assume that its a mistake or will be included anyway even though it is not mentioned.

7. If there's anything unusual or difficult about the project, e.g. the developers require root access to your server, or VPN access to your network, then make sure that these issues can be overcome before signing any contract. Trying to work around these things only after a project has commenced consumes valuable time out of the allocated project budget and can leave your project short of sufficient time to actually complete to the original spec.

8. Agree on the definition of 'complete' to save argument when delivery time comes. A good SoW will specify a list of requirements that, if met, will define the project as complete and able to be signed off. Do not expect to be able to add extra requirements at this stage if you've realised that you missed something out of the original SoW or have discovered new things you'd like along the way - the SoW's definition of completion is the only one that can apply, so make sure you agree with it before signing the contract.

9. Some projects are better defined in terms of amount of time spent rather than a fixed price for a fixed deliverable. Insist on proper time-keeping so that the hours can be tracked and you are forewarned when they're running low. Avoid anything that can cause delay and use up your hours unnecessarily - e.g. failed attempts at gaining server access as described above - by being prepared for these eventualities before the project commences.

10. Projects that incur third-party costs, e.g. cloud compute resources, will either include that in the fixed price or will recharge it as an incidental extra. Before signing the contract ensure with your accounting department that you are able to accept such recharges and if not, insist that they are incorporated into the fixed price. Often it is not possible to quantify the exact amounts in advance, so set a limit and insist on requiring permission to be obtained before the project goes above that limit.

I hope these are useful. They're not exhaustive, but they do offer an insight into the way bioinformatics projects need to be defined - particularly when using a third-party vendor. Follow these tips and your projects will run very smoothly indeed!

Topics: Bioinformatics