This is the first in a series of articles comparing Agile Work with the knowledge and practices “generally recognized as good practice on most projects most of the time” as described in the Project Management Body of Knowledge Third Edition (PMBoK) published by the Project Management Institute.
Definition of “Project”
The PMBoK starts out with a discussion of the question, “What is a project?” and immediately answers: “A project is a temporary endeavor undertaken to create a unique product, service or result.” (page 5) The PMBoK then elaborates on the ideas of “temporary” and “unique product, service or result”.
The PMBoK also contrasts projects with operational work. It states that “operations are ongoing and repetitive” (page 6) in contrast to projects. Further, the PMBoK states:
Projects are different because the project concludes when its specific objectives have been attained, while operations adopt a new set of objects and the work continues. (page 7)
Agile Work: Project or Operation or …?
If we accept the definitions given by the PMBoK for project and operational work, then we can conclude that Agile Work divides a goal up into many small projects (iterative delivery), that are managed operationally (adaptive planning).
Do iterations really count as projects? According to the PMBoK, they do indeed! An iteration is certainly temporary as it is a time-constrained effort with a definite beginning and end. And an iteration also creates a unique product, service or result by delivering valuable results.
And do Agile Work endeavors really count as operational efforts? Again, according to the PMBoK, there is little doubt: Agile Work adopts a new set of objectives between each iteration. In fact, like operations, an Agile Work endeavor continues for exactly as long as it is valuable to the organization or sponsor.
The Roots of Agile: Software Development
Software development is often conceived as project-based work. However, there is much evidence and commentary to suggest that this is not really the case. A software product company like Microsoft, or a software development community like that associated with Linux, both work in a fashion that is much more like an operational model than a project model. The core value that these organizations deliver is rooted in the actual software they build… and they never stop building it (unless it turns out to be a market failure).
In the book “Software Craftsmanship: The New Imperative“, the author, Pete McBreen, describes the lifecycle of software as being on the order of several years and sometimes decades. This extended lifecycle is long enough that the project perspective does not fit very well, particularly since the lifecycle only ends when the software is no longer delivering value (as opposed to projects which end when they deliver value).
The Value of Projects
To be clear: operations end when they stop delivering value, and projects end when they do deliver value. Project work is all non-value-added until the very end, whereas operational work is (as much as possible) all value-added.
The consequences of this are clear. Make projects as short as possible!!! If all the work of a project is NVA up until the delivery date, then in order to maximize value, we should be finding ways to make projects as short as possible, eliminating every last little bit of unecessary non-value-added work.
Agile Work, using iterative delivery and adaptive planning, describes a means to treat an endeavor as operational work and therefore as delivering value early, continually, and for as long as desired.