Selecting and Organizing Geek Work
The work of geeks is generally divided into two categories: projects determine what is to be done, and processes define how it is to be done.
Projects
The term "project" is bandied about quite a bit to describe any definable chunk of work, but they have a number of distinguishing characteristics:
- The project is a singular event, and ends when its objectives are achieved (it is not an ongoing process)
- The project has specific goals - to accomplish a specific objective (or solve a specific problem)
- Conscious creation - A project does not happen by accident or happenstance, but is deliberately created
The author names a few things that are also true of projects, but are not IMO a distinguishing characteristic: uncertainty (we are not sure what we need to do, resources are "borrowed" from other work, etc.). He also goes into detail about what a project is not (a standing department or team dedicated to maintaining a state)
Processes
A "process" pertains to ongoing actions done according to a pre-defined method. Generally, a process is designed to keep things running smoothly and follow a prescribed remedy should things go off the rails (and even when problems arise, the goal is restoring the previous state).
Processes exist in IT work, but they deal more with maintenance issues (care and feeding of a system that has been built) - and it's worth mentioning that processes are generally tended to by a different species of geek. However, process owners are often called into action on projects that impact or involve their systems.
Managing Structural Ambiguity
The author skims along the surface of project management - it's very random and superficial, and more complete and in-depth information is available from other sources, so I'm skipping this.