This blog post is written on the back of lots and lots of quoting recently and the slant on this blog post is one of a consultancy firm providing clients with a quotation on the back of a requirement or set of requirements.
The requirement(s) could be something very simple or very complex but nonetheless its still a problem that needs a solution.
So I’ll pick something that should be familiar to those who work with or are familiar with SharePoint and work around explaining the title of my post in relation to this example. So we have been requested to create a web part for SharePoint. Lets just say for example the web part has a free text field where when a value is entered it looks up employee ID. This information is stored in a SQL database.
So with the above classed as a requirement there are one of 2 ways you could approach this:
1.Make lots of assumptions which the client may not understand and potentially not deliver within the timescales provided
2. Gather further information regarding the initial requirement to gain a more accurate understanding thus more closely meeting client expectations
Before discussing these options there are also additional considerations when quoting that the client may not have considered or budgeted for when the client receives the quotation. These things include (to name a few):
- Testing
- Project management
- Documentation
Referring back to my two options, choosing option 1 may get you near the end result you were looking for (if you’re lucky) but on the other hand you could have wasted a lot of time and money and only be a little further forward but wiser nonetheless.
Option 2 will give you a clear idea of what can be achieved and the timescales to do so and in the process if you’ve structured the consultancy engagement in such a way of fixing the delivery agreeing scope beforehand the risk is offloaded onto the external consultancy firm. Yes I appreciate that gathering requirements in more detail will cost you a little time and the outcome maybe that what you actually expected to be delivered needs adjusting to what you can actually afford, wouldn't you want to find out beforehand?
As a bit of advice before going into an engagement make sure you have thought through what you actually want in detail thinking about not only what the requirements are but also what you would to happen on the screen or outputs to be in every eventuality you can think of (functional requirements). As an example for my specific scenario consider how you would want the web part to behave when the SQL database storing employee ID’s is unavailable – what should be displayed when the user enters a query? If you don't assumptions will be made for you and you could end up with a different output to what you expected.
The conclusion here is that the more information you can provide and the more understanding (where possible and appreciate this isn't always possible) of the problem this may narrow down the time required to deliver the solution, after all in the current climate we all want to be careful with how spend budgets. As regards the tax that go on top of delivering the functionality (project management, testing etc.) as consultants we do this everyday so we know what's involved, cutting corners on this just means you are going against the experts who you have asked for advice from and in the process adding lots of risk to delivering a successful outcome.
