ThePaperWorkBecomesTheProject - an extreme case of TheMeetingsBecomeTheProject. (I can't recall the citation for this - can someone define it with an ISBN) It's what happens when companies lose sight of the goal. The goal is not a set of specifications, project plans, Notes databases... in almost all software projects, WorkingSoftwareIsTheGoal. "For me, ''shipping'' is the thing." JamieZawinski -from http://www.jwz.org/gruntle/nomo.html [Ah yes - how did SteveJobs phrase it? "Real artists ship" or something like that?] How you define "working" varies, but it's the customer that gets to define it. Project success isn't something the software supplier gets to choose, which is something else forgotten. How to tell if you're on a ThePaperWorkBecomesTheProject: * You get project plans that assign you tasks but no-one can supply definitions of the tasks. * There's a document that tells you what documents you need to write to start a project. Bonus points for: * It doesn't include things like "a makefile", "a directory". * It's more than a side of A4. * There are more paperwork deadlines that coding deadlines in the plan. * There are deadlines for submitting drafts of paperwork. Bonus if those drafts need "approving" by people who've never been to a project meeting. * There are more managers than developers at team meetings. * You spend more time talking to QA to satisfy QA's needs than talking to customers to satisfy customers' needs. {Feel free to add more. There's got to be tons more..} On a personal note, I think this tendency to have SoftwareDevelopmentMadeHeavier is taking us further from an ability to produce working software. --KatieLucas ''This is the classic symptom of a project that substitutes written documents for actual organization. Blaming documentation as an activity instead of looking at the lack of overall planning is wrong thinking. Proper documents and proper documentation are a necessary and vital part of a well organized, well planned project.'' ---- See: TheAlmightyThud, TooMuchDocumentation