Estimating Time and Resources/Meeting Notes for 2017-01-16

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 Time and Resources/Meeting Notes for 2017-01-16

Announcements

Laptop Rescue Mission this Saturday, 21 February 2017, 4-8pm
Does somebody want to take over the group?

Taking Over the Group

Is there a venue available?
QSC is noisy
Other TWC spaces need staffing
Meeting at Steve's house?
Will anybody take the mailing lists?
New organizers: Bob Jonkman, Marc Paré.
Should we be on meetup?
- mailman does some of this
- NetSquared does not help with promotion
- meetup has a large user base
- there is a blog and a wiki already
- there is a twitter account
They want the group to be face to face
Bob likes the peer to peer conversation

March meeting's at Steve's house
Marc will look for other venues
Communitech has space available to tech groups: Marc

Moving the mailing lists: Steve
Marc can host on his server and get a domain name

Future topic: Project management software

Meeting Notes

Discussion Points

What are strategies and best practices to get better estimates?
Under what circumstances does estimation become easier?
Under what circumstances does estimation become harder?
When should we spend a lot of effort making estimates?

Discussion

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

Estimating Time and Resources/Meeting Notes for 2017-01-16

Contents