One good resource for estimating projects is Steve O’Connell’s wonderful “Rapid Development” – my favourite IT book of all time. It discusses two ways of estimating projects – past experience and estimation methodologies that can be encapsulated in software tools. I prefer the former, although if you like the latter, O’Connell offers a free tool on his website: www.construx.com
Estimations based on past experience requires all team members keeping accurate records. In my last job, the organisation introduced a rule that required everyone to enter their time into the time database daily – the customers were allowed to log in over the web at any time and get reports of their projects up to the previous day. Well, a huge fuss ensued (and I was one of the loudly indignant ones!), but it died down pretty quickly. It really only required five minutes per day.
This method worked well for us, as there are only so many permutations of project types that we engaged in. It also works well for because our projects tended to be quite small – two to 10 members per project, 3 to 12 months in length. We know how long it would take to gather requirements, and write the tech spec. Then after we divided the work into the number and complexities of GUI screens, stored procedures, Perl/shell scripts, migrations, OS/DB installation etc, we could calculate the work based on how long it had taken us to do the same number of items in the past . This proved to be reasonably accurate in terms of determining billable hours/cost to the customer.
In addition we used to build in a contingency – typically 30% when we had to liaise with 3rd party suppliers (there are so many unknowns and gotchas), less if it was all in-house.
After all the dependencies etc are worked out using MS Project equivalent we can then work turn our billable hours/estimations into delivery estimations. If the deadline is more important to the customer than having the wizzy features, we may simplify the requirements/spec and the estimates would be adjusted accordingly.
Once the project was under way, each team member had ownership of their own work. Everything was based around weekly status reports which are submitted to the customer - which would include a breakdown by team member of the following
hours spent on each project component
what was accomplished
what the member intends to accomplish in the next week
what they intended to accomplish the previous week, but didn’t
what they worked on that was not planned for at all.
The advantage of this is if anything was encountered that would adversely affect the project, we could take immediate action. So if we knew the budget was wrong, or the time lines weren’t right, we could alert the customer early on, rather than waiting until the problem became unmanageable. This is anathema to many people – they never admit problems, and just hope that with a bit of overtime or a few extra contractors that the issues will disappear. I found customers actually liked these issues raised as soon as they were discovered, but maybe we’ve been lucky with our customers.
This estimation system works well for us, but may not be everyone’s cup of tea. If your organisation’s culture isn’t amenable to this level of scrutiny, then you’ll probably have a hard time with it. (Believe me - if I had my way, it never would have been introduced at my last company). I doubt it will work for large projects. It may not work well if you have a wide variety of expertise. If you suddenly have a junior whose productivity is quite low, then you can’t use the time database to estimate their work, and it becomes a suck it and see for their work.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.