Estimating Time and Resources/Meeting Notes for 2017-01-16
Estimating Resources
========
Announcements
- Laptop Rescue Mission this Saturday, 4-8pm - Does somebody want to take over the group?
Estimating Resources
- 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?
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
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
