Saturday, June 20, 2009

Notes to Sharepoint migration estimation model

Updates: I have recently enhanced the Estimation model which will help people come up with more effective Notes to SharePoint migration estimats. Click here to refer to and download the new version of Notes to SharePoint migration estimation model

Its been a long time, since I am actually writing up on Lotus to Sharepoint migration.

A friend of mine called me up to ask for factors that one needs to consider in order to estimate a Lotus Notes to Sharepoint migration project.

I prepared an excel sheet and gave it to him which he found out to be immensely useful for estimating his sharepoint project, you can download the excel sheet at the end of the article, I request you to first read through the below mentioned guidelines:

a) Jot down the key features:
If you have 10 Lotus notes applications to be migrated, consider each application separately, jot down key features that you will have to develop for each of these application in the excel sheet.

b) Identify the Common features:
Find out features common to all applications, like for e.g:
Set-up Configuration of SharePoint environment server farms, Administration, Search User profiles synchronization etc

Set-up the Data migration environment, install third-party tools like Quest Notes Migrator for Sharepoint, test connection to Lotus Notes applications. (this can be a common activity for all the applications to be migrated)

You need to estimate for these common features only once for the entire migration project. In case you have many applications to estimate, record them only once in the excel sheet for correct estimates.

c) Effort estimates: Identify effort involved against each feature in terms of number of days that a person will take to develop it. This will depend upon the current skill level of your SharePoint resource, nature of requirement and past experience.

d) Actual effort involved: It is always good to find out whether you had correctly estimated the effort or not, this helps you to make better estimates the next time.

That is why my estimation sheet consists of another column to be entered, i.e the Actual effort in terms of days, this should be filled in as the application feature listed in the sheet gets completed and not when the application gets completed, as there are chances of wrong effort recordings.
The team should be disciplined enough to actually make proper time recordings during development activity.

e) Learning from the past estimates: Since, we are also capturing the actual time taken against the estimated time per activity, the variance % will help us whether we have a positive or a negative variance, this in turn will help us make better estimates and predict our team's productivity and output.

f) Buffer: Always add buffer to each item in your estimates, as you can't predict what can go wrong, a team member may leave the organization in the midway or may fall sick, without any knowledge transition, additional requirements or change requests may creep in, you never know...

A good buffer also helps during bidding, where the client bargains on the effort, you can actually cut some buffer time and still deliver.

So give a good solid buffer in your estimates, if you see my estimation worksheet, you will notice that I have added a lot of buffer for each feature that I am going to develop.

Download: Notes to Sharepoint migration Estimation sheet