-1

I have new clients requirements. I wanted to estimate for each components. What standard process should I follow.

1

Here is a very good explanation, how SharePoint project can be estimated. There are two approaches:

  • Expert estimation (this is a nice way of saying that I think about how long it will take to implement something and then come up with an estimation).

  • Use Cosmic http://www.cosmicon.com/methodV3.asp

Cosmic will solve 1 huge problem for you (as other similar approaches such as FPP, Function Point Analysis do): you won't forget simple tasks as the estimation approach only focuses on the essential stuff the application does (I/O to screen, I/O to data repository). If done consistently a piece of functionality should always cost the same amount of points.

At that point, things become harder. How to decide how much a point is? For asp.net apps, this is relatively easy, you could say: 1 cosmic point = 8 hours dev time + 4 hours testing + 1 hour documentation (or something similar). For SharePoint, this is more difficult for a number of reasons:

  • A company probably has less experience doing SharePoint projects compared to ASP.NET (as is the case in your company).

  • A certain type of SharePoint activity has a different cost than another. You can't really compare the cost of the creation of InfoPath forms to web parts to BCS ECTs to claim providers to SSRS reports to custom search extensions to workflows etc. etc. You will have to establish the cost for each type of activity independently.

  • Although a developer may have extensive experience doing SharePoint projects, SharePoint is huge. It's hard to say something generic as "the typical SharePoint developer will need x hours to complete a feature of y". You'll find your typical SharePoint dev will be comfortable with a range of SharePoint topics, but lacking in others. This will make it really hard to come up with an accurate cost per function point.

So what can you do? Start establishing baselines for each different type of activity and slowly learn from that.

Source of the above information:

Methods for estimation in SharePoint

Agile scrum approach (Modern approach) :

Instead of going with the Waterfall model where estimating the whole project at a time go with and propose to client Agile methodology.

The success ratio of Waterfall model is less compared to Agile scrum model.

In scrum, estimation works based on the sprint basis where we just need to plan and the work just for next two weeks or some cases four weeks. Here, customer and as well as developer has the flexibility about the requirements and change requests.

While planning the scrum, need to estimate the story point of each user story which is calculated based on the task complexities and number of hours of efforts needed for that.

To manage the scrum, we can use devops (vsts) tool, it has very good planning management system,if you explore this product for project estimation - this will take you to the right direction.

The bottom line of this discussion is, the estimation of SharePoint project is not same as other development project like asp.net projects.

So, while estimating the SharePoint project first flag is we need to check, are we going to use any customization? or just out of the box solution?

Again, while going with the customization need to check what type of customization is needed because based on the customization cost and time will vary. For example, if we customize the list in infopath form and if we develop a new form using SPFx framework, in this case SPFx will be more time and cost effective.

Not the answer you're looking for? Browse other questions tagged or ask your own question.