If you recently signed a project or you are preparing a request for proposal document, I would say a discovery phase it’s mandatory for any project. If it’s not done properly or not considered at all, you may lose the project because of a brief RFP, or if you indeed get the project, you can bring it over-budget, you can mess up the project deliverables and probably you’ll make your client very angry.
Now, what it’s a discovery phase you might ask? I would define it like this: a discovery phase it’s a period of time that it usually takes between one week and 4 weeks (depending if your client wants to acknowledge it or not) in which you or your organization try to understand the project requirements in order to provide the customer with an accurate implementation cost.
One of the most important challenges of a discovery phase is trying to have all aspects under consideration, especially when your project implies a lot of customization and custom development rather than implementing something very well known.
I have created below a list with some of the things you should have in mind when you estimate the work of a project or when you compile a proposal document to be sent to your customer in order to reduce the risks for a signed contract:
- When the only documentation a project has is the old source code, do not sign a contract without requesting a document explaining all the project functionality. From my point of view, this is one of the biggest traps you can step into because the existing application can have bugs, can have poorly written code, cumbersome architecture and almost always the customer will also want some other customizations. What’s the point of just migrating the website to a new technology if you also don’t add some other functionality tweaks? This of course will lead to a very extended research phase over the existing logic and some very long QA sessions to determine if the new logic actually works as the old one.
- Do spend a considerable amount of time on defining your proposal assumptions. Even if you define in greater detail your project estimate and project proposal, make sure that you are backed-up by the right implementation assumptions. For example, if you design an e-Commerce solution, you can state how many payment gateways you agreed to integrate, because if the customer expects you to integrate an additional 3 payment gateways than you theoretically assumed to implement, then your project deliverables are in danger.
- Do not leave big chunks of implementations undetailed. In order to get faster over a discovery phase especially when the customer doesn’t want to pay for it, you might throw some numbers on some specific implementation modules. Don’t do that! Do not put numbers on implementation items bigger than 3 or 4 days. Try to split that module as much as possible to avoid the risk of overseeing something.
- Be descriptive over your proposed implementation. Although you might be tempted to say your proposed implementation is reflecting the requirements document the customer sent, try to offer more details about how the project will be designed. It will give more confidence to your client that you all are on the same page and also it will give you a head start in terms of requirements when the project will kick off.
That’s all that I can think of at the moment as top things to have in mind during a discovery phase. I would really appreciate your feedback on this topic. Maybe with your help, we can grow this subject with even more valuable tips that can help you during a discovery phase.
One more thing though, please keep in mind that for the sake for keeping this blog post on topic, I might be very selective with the comments.