Jump to content

Talk:Boxology

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Boxology best practice

[edit]

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)[reply]


== 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

[edit]

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.