Talk:Boxology

=Boxology best practice=

I removed the following text, placed by rpblogger192, because it is not a general description of boxologies but a set of recommendations about a particular type of boxology.

Remember, Wikipedia does not advocate particular things -- it is a description of what things are, not a prescription of what they should be. This text could be inserted in a special-purpose section on boxologies as planning tools, but should be written as a description of somebody else's recommendation, not as advocacy by Wikipedia.

Best, zowie (talk) 20:42, 20 February 2009 (UTC)

== Boxology best practice == Boxologies are best used to guide and define the early stages of a project. They form a visual presenation of project direction, progress and goals that are often much more digestable to project stakeholders than a detailed gantt chart or project plan. A boxology is used as standard on projects run by the most reputable business consultants. As a project sponsor you should ask for one at your next steering group. To create a clear, intelligible, boxology follow this short list of recommendations:

* the horizontal axis of the boxology denotes time. * split the time axis into stages of the project (e.g. design, development, test, deploy) * split the vertical axis into 'swim lanes' to denote the different teams on your projects * use pastel or transparent coloured boxes with 1-4 words inside each box * ensure there is plenty of white space around each box - this helps the reader's eye

Boxology notability
The term is still moderately widely used among technical people "of a certain age", and mainly orally -- although casual web searches do not find many modern written references. Someone flagged the article for non-notability; I removed the flag based on the term's presence in the New Hacker's Dictionary lexicon, which is now referenced.