Methodologies across the Organization
Notwithstanding the appropriateness of extracting the project management strategies from the corporate methodology, and the recognition that some tailoring is needed within each project, executives quite reasonably want their projects to have
conventions in common. They want people to be able to understand what is happening when they transfer to another project. This requires having
conventions across the organization:
I was called in once because every team used those terms differently, and they could understand
what other people meant nor what they were doing on their projects.
Definitions of common formats.
may not have to create the same work products, it is useful if they use common formats for whatever work products they do have in common.
Every project should probably have a vision and scope document.
Every project needs a way to report its status. Finding ways to represent status for all possible projects is very difficult (see "A Governance Model for Agile and Hybrid-Agile Projects" (Cockburn 2005c) for a progress-reporting format that covers a lot of projects).
The Unified Modeling Language (UML) is a common language for drawing a domain model or sequence chart. The organization may add rules for how those models are presented (naming conventions, complexity in a single drawing, use of vertical and horizontal placement, and so on).
The testing and marketing departments need advance notice of upcoming product releases. The organization may set policies in place about how much advance warning they get ("two months"), how reliable the schedule should be ("when the schedule is estimated to be within 10% accuracy"), and what
of information they are to be given.
Baseline project management strategies.
The organization may require every project to run an Exploratory 360° (see Cockburn 2005a) before receiving committed funding. It may require each project to deliver system
to real users every three months or less. It may require automated testing and perhaps test coverage policies. These policies may be challenged on a project-by-project basis.
Among the strategies most often mistakenly put within the methodology are the sequence and timing of gathering information. It is common to require that all requirements be gathered before any design is done, or that all user interface design be done before any software architecture is done. By now it should be clear that any strategy calling for "all-of-one-before-another" has severely limited applicability.
Even sophisticated developers and managers fall into this trap. In teaching how to write use cases, I describe how to select
to write and the format
to write. Peopleeven
peopleimmediately jump to the conclusion that I want all of the use cases to be written before any design is done, or that each use case should be written to completion at one time. Neither is true.
The choice of how much of one use case or how many use cases to write at one time should be reevaluated continually during a project. The alert team will come up with different answers at different moments on a project and
different answers on different projects. This is in keeping with the cooperative game model.