The following appeared as a comment, by "Steve," in response to "Problems with project estimation," Advice Line, 2/5/2007:* * *I feel really guilty. I live in that ideal company, small (90 people), outrageously fast paced, but ALWAYS looking to IT to find better, more effective ways to accomplish more work (and higher loan volumes) with the same number of people.IT has a staff of five (one department head who al The following appeared as a comment, by “Steve,” in response to “Problems with project estimation,” Advice Line, 2/5/2007: * * * I feel really guilty. I live in that ideal company, small (90 people), outrageously fast paced, but ALWAYS looking to IT to find better, more effective ways to accomplish more work (and higher loan volumes) with the same number of people. IT has a staff of five (one department head who also does web development, a network guy, an analyst who also is an expert in our CRM package, a web designer and a data administrator who both help with floor support). We have two major commercial packages that we use and those databases are used to extract and consolidate data for presentation in web pages, which reduces how much data collection we have to do. We do minimal project planning (high-level only and only for larger projects…a six man-month project might have ten line items) and most of what passes for documentation occurs after the fact. After a quick specification-gathering meeting, we respond with an email that describes what we heard to make sure we said/heard the same things…usually the toughest part of any technical project. After that, we put together a prototype, demonstrate what we have, then go into revise/test/demo iterations until our users are satisfied. Afterwards, we write instructions, do training, and users come back over time with enhancement requests. Because they eventually get almost exactly what they want, they are very forgiving about bugs (our rule is that bugs are OK as long as they don’t damage data) and delays in delivery when higher-priority items bump them down. We don’t ignore project planning entirely (I’m actually a certified PMP…but only so I can be employable elsewhere…you never know), but we keep most of our projects small enough that we don’t need it. Our company president is totally in support of IT (although several of our second-level managers are somewhat suspicious of it), but the majority of the company treats us like rock stars. I agree that much of the desire for in-depth project planning comes from CYA environments (and I’ve worked at many of those). I’ve been in IT for 25 years and have found that folks don’t give a d@mn about project planning, if you get them something they can use quickly and get it right soon after (and work with everybody to decide priority). * * * Steve … You demonstrate a point I’ve tried to make over and over again for the better part of a decade: Documentation exists to remind people of what was said in face-to-face interactions, not to substitute for it. Also that the best way to create software that satisfies end users is to show it to them often while you’re building it. I sure appreciate the testimony of someone else who has done it this way. Thanks. – Bob Technology Industry