ProjectManagementPatternLanguage
Project Management is a crucial part of organizational design. Many organizations have a project manager role, but in fact project management is a much broader function--so broad that it covers almost a quarter of the patterns in this book.
The patterns here do concern themselves with all the things a project manager worries about. We start out with SizeTheSchedule. In today's markets, time to market is everything. In the classic view of project management that suggests that there are three resources one can trade off against each other--staff, functionality, and schedule--it is schedule that is most often the strongest invariant. Past years have seen functionality fall from this first place position as software development enterprises have come to realize the difficulty in both capturing and meeting detailed requirements. Customers have come to the realization that it's better to get something that works in a finite amount of time than to spend a seeming eternity "getting it right the first time." Instead, we tend to defer correctness to the later releases.
The Pattern Language
The above figure depicts the patterns in the pattern language and the connections between them. The connections themselves are as much part of the language as the patterns themselves. Each pattern provides a possible context for the patterns below it. They depict the dependencies between the patterns that govern the order in which they are to be applied: you start at the top and work your way toward the bottom. If a pattern has several subtending patterns you can apply as few or as many of them as you like, and in any order.
The pattern language is based in empirical study of organizations that do software, most of whom deliver some software artifact to a customer. However, the pattern language has little to do with software per se. We believe these patterns reflect management principles that are deeper and broader than software alone. Software development organizations can learn from these broader principles.
Here is a real story about a real project that features many of the patterns in this pattern language. Think of this story as a sequence of application of the patterns.
A Story About Project Management
In the mid 1980s my group embarked on an ambitious project. We took a successful product and adapted it to new technology. We began by testing the concepts in prototypes (BuildPrototypes), and their success gave us the confidence to SizeTheSchedule.
Because we were building on an existing product, it was easy to have NamedStableBases of code; we continued them throughout the project. This made it possible — and necessary — to provide developers a way to have their own view of the system, a PrivateWorld. There was ample tool support for these views.
Although the project was large, the project was basically centered on the developers. For example, we decided on our own coding standards (DeveloperControlsProcess). It certainly had a feel of WorkFlowsInward. Developers had some latitude about how to organize their work; WorkQueue, InformalLaborPlan, and ProgrammingEpisodes were common.
Unfortunately, we had problems. One of the biggest was that we did not allow CompletionHeadroom. As the technical difficulties intensified, the schedule became tighter. Finally, the head of the project called everyone together and announced a single large schedule slip (TakeNoSmallSlips), and asked everyone to commit to the new schedule (RecommitmentMeeting).
We continued to struggle with technical challenges, and some became crises. We created teams to deal with them (TeamPerTask), and even had to SacrificeOnePerson on at least one occasion. However, no crisis stopped everyone (SomeoneAlwaysMakesProgress); this was in part because the architecture of the system allowed it.
In the end, we met the slipped date. But the technology was moving in such a direction that it made no sense to deploy it. However, pieces of that project were used in later projects for years to come.