This is the first part of a multiple part series regarding
SharePoint projects and the processes involved.
SharePoint Projects Part 1 - Solution DesignMany
SharePoint projects have fair issues when it comes to time estimation. Due to the nature of 'Fixed Price' projects becoming ever so popular with clients (and with the sales team) it becomes extremely easy to over promise and under deliver. It is far easier to tell a client something will cost $100k and then finish under and let them know they have an addition x number of hours for further development and/or support then to tell a client $85k and then have to ask for another $10k due to
unforeseen circumstances.
The problem is that
SharePoint projects need to be treated almost as custom application development projects, although
SharePoint is a fixed product
essentially, the variables involved in each deployment is difficult to gather and can therefore skew your initial comprehension of the proposed solution. Therefore, whenever possible (and reputation allowing) it is a good idea to work on all
SharePoint projects on a Time and Materials basis, this means that the project 'is finished when it is done' so to speak. Obviously for your own sanity you would have a project plan with assigned tasks and time estimates for your own reference.
However, if the client will only accept a fixed price (Which is often the case) and you don't have an option to decline the project, take these factors into account:
Scoping, Planning and DesignFrom what I have seen this is one of the most ignored steps in
SharePoint projects. Microsoft have developed the
SharePoint Deployment Planning Services (
SDPS) to tackle this very issue. I would strongly recommend reviewing some of the available material to understand the
SharePoint planning process.
The more planning and requirement gathering you do, the greater success you will have when it comes to quoting. One important aspect to note is that this is actually part of the project, you need to make the client aware that this type of 'discovery' phase is a vital part of the project. If the client
chooses to not continue with the project after this discovery time frame, I believe that the client is accountable for the time spent during the design consulting phase.
For example: if you take your car to the mechanic and the mechanic tells you 'It sounds like you have a problem with your clutch, but I need to inspect it to be sure' you will pay the mechanic for his time to
inspect the vehicle. Not allowing this 'inspection' and just 'going ahead' with the 'project' can result in the 'mechanic' replacing your clutch but in the process discovering that your gearbox and drive shaft are also damaged and therefore costing you a lot more than a 'clutch replacement'. This is essentially the same thing as a
SharePoint project.
Things to remember (
CAMSUD):
- Capacity: How many users, how much data will be stored, what kind of data
- Availability: SharePoint disaster recover and server availability, performance monitoring
- Modification: Any SharePoint modifications, site creations, site collection creation, search scopes etc. Also would include look and feel modifications through Master/Layout pages.
- Scalability: Future growth, future capacity, Future Development
- Usability: Performance consideration, server architecture, network infrastructure, virtualisation, server farm configuration
- Development: Customising SharePoint from a development perspective. Solution deployment.
I will be back next week to post the next part to this series: Implementation.