“if you can earn 80 percent of your requirement with current SharePoint features and need to development for other features , SharePoint is your solution.”
SharePoint is a Development Platform with lots of functionality available out of the box. SharePoint MVP, Sahil Malik, also recently did a podcast show where he also quoted the 80/20 rule. So what is it?
When you’re gathering requirements, gather requirements!
One of the tips that Sahil raised was that before saying “yes, no problem” about implementing a Solution in SharePoint, do a quick Proof of Concept (PoC) to guarantee it will actually work. The best approach when gathering requirements from Business Users is to gather the requirements…and not drag the conversation down to how it will be implemented in SharePoint. This can be hard sometimes as you wish to explain how you can leverage SharePoint functionality that may improve the End User experience for the End User and extend the requirements with little effort.
Watch out for the traps
Dragging it down to the implementation will cause you to promise functionality that may not be possible with excessive customisation or development. Sahil used a great example of the limitation around SharePoint 2007 not being able to have a BDC Site column in a Content Type, this kind of thing would not be obvious without actually running a PoC.
There are plenty of these trip wires in the SharePoint platform where you think it would be easy and then realise it isn’t! The 80/20 rule is the guidance around where 80% of the requirements can easily be implemented using out of the box components with the Web UI or SharePoint Designer. There are often requirements (the last 20%) that require customisations or development work to occur.
One step forward, one step back
The other thing to bare in mind is that there are often multiple ways to implement the solution to meet the requirements. Often the last 20% of the requirements to be implemented can mean taking a few steps back from the implementation approach and moving down another approach. With all implementations it is worth putting a PoC together across all the requirements where there are unknowns. This would reduce the amount of back steps taken during the process.
Do you really need this?
Often with a lot of discussions with Business Users, they will mention requirements that they have come up with that may never be used. Don’t be a afraid to push back on these, especially if it is something in the last 20%. A delicate way to do this is to take the Agile methodology approach to requirements and rate the priorities and then schedule implementation based on this. Often Business Users see the functionality roll out gradually as more requirements are reached and realise that some of their requirements are not necessary.
