Just as everyone, you and I are going over the estimates on
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.
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!
Check out our new resource centre for more insightful
work from Yaroslav Pentsarskyy.
Register
now and be part of the European SharePoint
Conference 2017.
