SharePoint 2010: Best Practices to Estimating and Benchmarking Project Efforts
Why?
It can be hard to estimate how much time it will take to complete a SharePoint project. The usual approach is to do an "expert count", in other words, have an expert (or more) estimate how long it will take to complete a project. Depending on the quality of the expert(s) and his/her team members, this can be a fine approach. It has one disadvantage though: it'll make it really hard to do benchmarking and try to compare one project to another.
A more formalized way to go about it is to use a standard methodology for establishing the functional size of a SharePoint project expressed in function points. Although there are other methodologies, we'll use the COSMIC Full Function Points methodology as the basis for analysis of the functional size of the project, as it focuses on the bare essentials. This is a difference from the more well known FPA methodology, but rest assured, COSMIC is also one of the 5 recognized ISO standards for functionality sizing software: http://en.wikipedia.org/wiki/Function_point.
After establishing the project functional size (and the great thing is, even if you apply COSMIC wrong, as long as you do it consistently, it's still useful), the problem remains how to map these function points to a realistic amount of implementation hours. This knowledge can only be gained the hard way, based on experience. That's where this Wiki page comes in, it relies on the feedback of SharePoint community members and offers an overview of what the community thinks is realistic.
Brief introduction of COSMIC
COSMIC breaks functional processes down to data movements. Each data movement corresponds to 1 COSMIC Functional Size Unit (CFSU). Each CFSU corresponds to a number of hours, i.e. it might take 8 hours to implement 1 CFSU. COSMIC discerns 4 different types of data movements:
- E, Entry, a data movement that moves a data group/moves from a user/moves across a software boundary/moves into the functional process.
- X, eXit, a data movement that moves a data group/moves from a functional process/moves across a software boundary/moves to the user that requires it
- R, Read, a data movement that moves a data group from persistent storage (i.e. a database) to a functional process.
- W, Write, a data movement that moves a data group from a functional process to persistent storage.
E and X data movements include formatting, presentation manipulations, simple validation, and processing required for routing. R and W data movements include simple processing, computations and other manipulations.
For more information, please refer to:
Learn by example
It's probably unnecessary to point out that you're not reading a comprehensive learning guide about Cosmic FFP. But still, let's see how it works by learning from a simple example.
Suppose you have the following requirement: You need to build a visual web part that allows end users to enter an employee id. After that, the web part will look up all information it has related to this specific employee. Further suppose 1 CFSU for a visual web part takes 2 hours to implement. How much time will it take to implement this specific visual web part?
- Entering the employee id counts as an E (Entry): +1 CFSU.
- Retrieving employee data counts as an R (Read): +1 CFSU.
- Displaying employee data counts as an X (Exit): +1 CFSU.
- And probably you didn't see this one coming: there's also an X (Exit) for displaying any error and/or confirmation messages regarding the entire process.
This totals to 4 CFSU, which, in this example, leads us to believe that an estimation of 8 hours to implement this web part is reasonable.
Please note: As said before, no worries if you get a different answer. Even if you're calculating it wrong, just as long as you do that consistently (meaning: you have your own approach to counting CFSU's) Cosmic will still be useful to you.
CFSU Cost Overview
Here's the overview of different types of SharePoint software development artefacts and their associated cost in CFSU. The community is highly encouraged to contribute and make changes to this list. It only accounts for the associated development time, and ignores other associated costs such as the time needed for documentation, testing, and project management.
Please note: The minimum cost of a CFSU is 1 hour, we won't go below this threshold. Also note that you're very much invited to make additions and modifications to this table. It's not written in stone, the more people participate the closer we'll get to the truth.
| SharePoint Development Artifact |
Development time (in hours) of 1 CFSU |
| Application Page | 4 |
| BCS Custom.NET Assembly Connector | 6 |
| BCS External Content Type (ECT) | 4 |
| BCS ECT with SharePoint Designer | 1 |
| Custom Claim Provider | 2 |
| Event Receiver | 2 |
| InfoPath form | 4 |
| JavaScript Client Object Model | 4 |
| Managed Client Object Model | 3 |
| SharePoint Designer Workflow | 4 |
| Silverlight Client Object Model | 4 |
| SSRS Report | 1 |
| Visual Web Part | 2 |
| Web Part | 3 |
| Custom workflow | 4 |
| Custom Workflow Activity | 3 |
Please note
Also check out the SharePoint 2010 Best Practice Overview page at http://social.technet.microsoft.com/wiki/contents/articles/8666.sharepoint-2010-best-practices-en.aspx http://c.statcounter.com/7924459/0/dd5c0e49/1/