Extreme Project Management for Architects
After a project is broken down into tasks, and tasks selected, the pair working on a task must be able to determine, with confidence, that the task is complete and correct. XPers do this by writing software tests. They write a test, change the code to make the test pass, then add another test and repeat the cycle. When all the tests pass and they can't think of any more tests, the task is done.
Most XPM tasks can't be tested with software, so we must devise alternatives to give us that same level of confidence. Here are some examples of testing alternatives:
Similar to checklists, we can develop a list of tests for each task. If the task satisfies each list item and we can't think of any more tests to add, the task is done. Where possible, we should automate specific tests. For a more complete discussion of testlists, see
Examples are a step up from testlists in the testing hierarchy. They show the result of applying all testlist tests. If faithfully adapted to a task, examples can provide the same level of confidence as testlists.
Standard Details are a step up from examples in the testing hierarchy. A standard detail is an adaptation of an example to a specific instance. Ideally, standard details have been tested in practice, so we know they work as expected. We may need to supplement standard details with testlist tests to determine if the standard detail is appropriate for its intended use.
Based on Japanese "poka-yoke" manufacturing practices, we can perform tasks in such a way that errors are amplified and thus easily observed and corrected.
Tasks that require meetings can be based on meeting agendas, adapted from testlists.
Many tasks involve collecting information or material. Standard forms help assure that all appropriate material is collected. Standard forms can be adapted from testlists.
Develop a prototype, and use it as the standard on which other drawings are used. See using prototypes.
Tasks that require written communications can be based on form letters; the form letters based on testlists.
If testing alternatives are insufficient and we are not confident that a task is correct and complete, we can, as a last resort, rely on peer reviews. Peer reviews, and pairing, which is a form of peer review, are usually not adequate by themselves to provide a confidence level equivalent to actual testing.
Improving Testing Alternatives
The testing alternatives described above are effective because, like software tests, they provide feedback almost immediately. On the other hand, in architecture, there are other, delayed, feedback loops involved: during construction, after completion of construction, and after long-term use. During each of these time periods, we have an opportunity to evaluate whether or not our work is performing as expected and to improve our tests accordingly.
This site has a section dedicated to providing testing alternatives for specific tasks involved in architecture: See the
project checklists home page.
for a version of this page that's more suitable for printing. After printing, click the back-arrow of your browser to return to the original format with an index alongside.
I welcome your comments and suggestions.
for more information.
Original post: November 26, 2003, written by Dennis V. O'Neill.
Last revision: October 7, 2004.
Copyright 2004, Dennis V. O'Neill