Yet more notes as I clean up my computer. My favorite is this one, and remains true.
Eighty percent of project duration is getting agreement.
Glancing over the rest of these, there are several I agree with, and some that I don’t. A lot of my software methodology notions have been answered by Scrum. But not all. Not all. :-)
software projects * estimating * relate size to duration? How about size to price (regardless of cost/duration)? (small, med, big, huge) * what are common elements? * how much info is needed to make estimate? * what info is needed to make estimate? * estimate hours for cost and duration for schedule.
* tasks * just a few (ten) top level deliverables/milestones * estimate resource hours against tasks * the more parts there are to a task, the less accurate the estimates for those parts have to be, as long as the task estimate is accurate. * what about weekly Monday releases as tasks, with a supporting document (release features) for each task. This is easy to understand.
* confidence * the biggest fear is that something will break * when a client starts asking for documentation, they’re losing confidence. * however, when useful documentation is supplied as part of the project, confidence increases. * clients like it when you seem prepared. They like it even better when you really are.