Q: How do I estimate a SharePoint development project?

A: Like most projects, most developers tend to be optimistic with their estimates of time and resources. There are no simple answers or rules that one can follow to assure accurate estimates, but an experienced developer might consider the following to help drive more accurate assessments and estimates:

  • Vague and changing requirements lead to inaccurate estimates. Although this is a general rule for all development projects, SharePoint can introduce unique complexities. At times the simplest shift in requirement can cause great discrepancies in estimates. Remember, developers are working with an already established product and "small" customizations can turn out to be a "large impact" customization in SharePoint.
  • There are several approaches to help solidify vague requirements. A Gap Analysis is where one highlights how SharePoint, out of the box functionality, fulfills some or all requirements and where custom development will be needed to help flush out requirements. This way, each requirement that is addressed by out of the box functionality can be solidified up front by the existing functionality of SharePoint. Requirements that need custom development can be explored further and solidified.
  • Take time to evaluate and prepare a development environment. The goal with development environments is for them to resemble production environments as much as possible. Any security setting, account access, server configuration, or discrepancy in SharePoint or software license can cause major drawbacks in the later stages of development (that is testing and deployment). Part of the estimate should include setup or verification of development environments.
  • Part of any development project is not just estimating the actual development time but also estimating the testing and deployment time. Testing and deployment will occur in multiple environments (that is development, staging, and production environments). Just because a customization passed all tests in development does not mean it will pass in staging, let alone production. Make sure you estimate time to test throughout the environments and not just test customization. Regardless of how much you try to mirror environments, it is unattainable.
  • An understanding for the technical environment and the access privileges that a developer has been granted is necessary. If code is off loaded to a Delivery Manager person, they may not be fully aware of how to deploy and test and time is wasted.

    Note

    There are few more frustrating experiences for a developer than to explain how to deploy their code to the live environment and troubleshoot it to another person who is not knowledgeable about the code and functionality. This is a major time drain on a project.

A complex production environment is simply not feasible to recreate in development or even in a staging environment. The complexity of environments introduces factors that were non-existent and impossible to simulate in development environments.

Tip

With delays, expectations must be managed. Remember the business sponsor not concerned with release problems or the governance implementations. All they really want to know is when the project will go live and deliver business results.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.48.135