Location: The Working Centre 58 Queen Street South, Kitchener, ON (plan)
Date: January 16th, 2017
Time: 7:00 PM
In IT we are often asked to estimate the time and resources assorted tasks will take. Often these time/cost estimates are tied to funding, grants, and resource allocations. Unfortunately, many of us struggle at coming up with estimates more accurate than “it will take longer than expected”. What are some strategies and best practices we can use to come up with better estimates? Under what circumstances does estimating things become easier? Harder? Under what conditions should we spend a lot of effort making estimates, and under what circumstances should we not?
When have you had good experiences making estimates? When have you struggled?
As always, bring your experiences and questions. Also, please spread the word about this meetup so that more people who do nonprofit systems administration will become aware of it.
=====
Estimating Resources
——————–
– Horror story: server installation
+ building a server room that needed dedicated cooling
+ he estimated power consumption of each device
+ UPSes only need to be sized for the running current (they are built to
handle startup current already)
+ He ended up overestimating by three times
+ The air conditioner would freeze the pipes and everything would shut
down
+ He looked up currents instead of measuring them
+ How do you deal with the exhaust heat?
+ The UPSes had meters for measuring electricity draw
+ But then they dismantled the server room for other reasons
– When is it easy?
+ Figuring out spending is easy?
* In the horror story they sized based on existing equipment
* Looking up specs can be difficult
+ Never?
+ When you have done this project before?
* There are differences between software and hardware
* But sometimes you make software similar to the stuff you made before
+ When you can look at projects similar organizations have done?
* How do you get that information?
– Mythical man month comes into play
+ You cannot predict how managers will manage the project
– Example: replacing a network was the single largest line item
– It is harder than you think always
– There is always effort associated with making estimates
+ When is it worth the effort?
+ When projects are expensive
+ When projects are tied to specific grants
– Waterfall vs agile software methodologies
+ Don’t estimate everything at the beginning
+ Can you make estimates a little at a time?
+ But budgets are always waterfall, not agile
– But we tend to overengineer things
+ But then your results are rejected
– Projects always have unanticipated things
– It is expedient to underestimate costs to win contracts and political support
+ What will future maintenence costs be?
+ If you lowball costs then you get approved
+ Who pays for the overage
+ But operational budgets are overestimated so that you get a surplus later
+ End of year rollovers are political
+ Surpluses are seen as weaknesses, not frugality
+ This applies to nonprofits as well
+ Bureaucrats look good when they give large amounts of money
+ There are not good incentives to share funds across departments/projects
– Does that mean IT is always having to convince management for funds?
+ IT is always a cost sink
+ But technologies can reduce labour costs and stop people waste time
+ Workers should enjoy the additional gains from productivity gains
– How do you position yourself so that you get buy-in?
+ Get the people who are affected to talk to management too
– Sometimes estimates are done to argue for funds and sometimes they are used to find projects that should not go ahead
– If you know that you are going to need something then just go and do it
+ But senior management does not trust the estimates, so they hire
consultants, which causes conflicts
– It is less important to estimate when you have projects that can be done in small stages (instead of projects that need to be done all at once).
– If the project is small it makes less sense to make estimates
– Pilot projects can help figure out long term costs
– Projects can be broken down by scope
– Sometimes estimates are not honest, but designed to underbid the competition
+ Who pays for the overruns?
+ There can be penalty clauses in these contracts
+ Getting the lowest contract can be a problem
+ If you incur penalties you get taken off the list of approved contractors, but you just change your name and try again
+ This can result in lawsuits
+ There can be completion bonds, etc
+ As soon as lawyers get involved costs go up dramatically
– It can be a problem when sales team promise things without telling engineering
– Doing estimates can give you a ballpark about the costs
+ but now you may have to have consultants vetting other consultants
– To some extent you can play vendors off against each other
+ Big software companies will have pre-sales engineering teams to help you figure out your costs
+ They can also outbid you if they want
– How do you deal with projects where you have blown the time constraints?
+ You can hire subcontractors
+ Drop parts of the project
– RFPs can tell you what they have to offer
+ They can help you anticipate some of the pitfalls
– Do requirements documents of what you need
+ Talk with the vendors/engineers from the companies
+ But the vendors will not tell you the horror stories
– People’s behaviours can change once the ystem changes
+ eg people beginning to use email as file storage
– Breaking down projects into chunks
+ This shows you things that you are missing
+ Then you can better understand what the project is
+ Start aspects of the project that you can learn from and what different tasks are involved
+ But you cannot do this with monolithic systems
– Fixing technical debt is more work than starting fresh
– Don’t be tempted to give the estimate right away
+ Be prepared to charge extra when the estimates increase
– Sometimes competitive bids boil down to who you know?
+ This is not necessarily bad because of trust
+ But the well-known vendors have more experience winning these bids
+ If you start out at a big vendor and branch out on your own you can receive trust
– Talk to other people who have done the same thing