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

{{:Estimating Time and Resources}}
---- 

==== 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

[[Category:NPSA]]
[[Category:KWNPSA Meeting Notes]]