SharePoint Projects Part 1 - Solution Design
Many 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 Design
From 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.
2 comments:
Just to throw something out there...do you believe that the waterfall approach works with such locked phases of the project. Design is always revisited...why not try and agile approach to the project?
I believe that this approach is definitely the way to go. I have worked with the agile approach and if there is not a common understanding amongst the team and the client, it can do more harm than good (mainly absorbed by the client's budget).
I would agree though that the agile methodology would be more suited to large scale development customisation to the SharePoint system, however I would recommend conducting such customisations as a separate project.
Post a Comment