Our purpose here is not to replace Google or Wikipedia, which provide extensive and (shall we say?) lengthy descriptions and definitions of project work. Rather it is to provide a more succinct explanation of various project management terms, to explain some insider jargon that may be intended to obfuscate (who would do that?), and to expand our project vocabulary of related techniques, all in a way that does not take the topic too seriously.
Visit our Language Gallery and scroll through more project language!
Rot, decay, putrefy, crumble, fester, molder, these are the synonyms for decompose, so it is no wonder this term is not understandable. Who on earth picked this word? In project terms, the word “decomposition” is usually bandied about during the planning process of developing a Work Breakdown Structure. What it means in this context is that project work is segmented into smaller and smaller pieces within the schedule so that tasks may be assigned to one owner and for a reasonably short period of time.
The owner part is so that we know who has accountability; the short period of time is so that once the project starts we can assess a task for completion without losing a lot of time if it has slipped. And what is a short period of time? Two weeks and 80 hours is a good starting point.
Work Breakdown Structure (WBS)
This is a project management planning method used to identify, assemble and organize all of the work tasks that will be necessary to complete the scope of the project. The work is organized in logical groupings. It is decomposed to a level that seems sensible to the project team and is planned at a level that progress can be measured in line with status report requirements. A WBS is usually completed before and as an input to the project schedule. There are lots of methods out there for developing a WBS, but the best one is a deliverables or product oriented WBS.
A term coined to describe the notion that all software development work runs on the edge of chaos and that the chaos cannot be controlled or planned out. Supporters of Agile development methods argue that the chaotic nature of software development suggests there is no point in planning software development projects or predicting outcomes. Of course, waterfall development advocates disagree. And business executives pretty much hate this as well……