Just as everyone you and I are going over the estimates on many SharePoint projects; it doesn’t matter how much experience you have. With more experience you might be able to mitigate the outcomes of going over estimates, but avoiding going over the estimates, in a first place, is not so trivial.
I’m sure you already thought about the whole “going over the estimates” problem and even have few answers why it happened; most of those answers are probably related to stakeholders on a project and other events.
The purpose of this post however, is not to tell you that I have discovered the ultimate answer to estimating SharePoint projects, but to share some of the points you may have not thought about applicable to any software project.
The “halo” effect
Scenario: New or existing client comes in and says “I need this really simple SharePoint solution (since we have SharePoint deployed already), it’ll be used by a department of 10 people”. Then they give you the details and you realize this is pretty complex solution; but then you think about it overall – “only 10 users, if I give them an estimate of 100 days – they’ll never go for it; am I overthinking it? of course I am, all it is … ” there is the “halo” effect, where you under-rated the individual component complexity based on the impression of overall “simple” solution. Think about it next time you’re giving an estimate.
Framing effect
Which is harder to deliver?
a) “99% up time” or
b) “4 days of acceptable down time per year”
My answer would be b), the reality is that those are roughly the same but presented differently. Don’t get caught in “simple sounding” requirements
Overconfidence
You know how there is this piece of API you’re aware of and you’re not absolutely sure whether you can integrate with it or not but you assume you can because you integrated similar type of API. Well, SharePoint has many API’s which you can’t integrate with or extend. Next time you have a major functionality you’re uncertain about, try prototyping first before giving an approximate estimate.
Anchoring
Everyone of us had this amazing experience working with this great team on this one project. The client knew exactly what they want and there were no scope changes. Unfortunate part is that you may be basing estimates for similar types of projects based on your experience in that one project. Account for things like skills level, stakeholder engagement, communication and clarifications, incomplete testing etc … when giving your estimates. Get a second opinion.
Expect misinterpretation
Try this … read this sentence 4 times with emphasis on a different word each time “I never underestimate projects” … of course the meaning is different most of the time. Now imagine taking notes from your client describing the business requirements … chances are you might be missing something. Now, what if you don’t work alone, you’re going to pass those misinterpreted requirements on to your team. Try to clarify as much as possible, involve SMEs, UE design, Information Architects. Make sure you know what is your business user’s comfort level with the platform?
I could continue for hours but I’ll stop here are let you think about your particular cases; and if you like, send those to me and I’ll post them here.
Enjoy!
