Rethinking Typical Project Management Approaches
"Don't work on projects, work on products!" is a rallying cry often heard in the agile community, but it’s not supported with any specific information as to what it really means. In a product development environment, the statement makes quite a bit of sense. If you have a team pulled together to support an ongoing product, it doesn't make sense to use typical project management techniques to drive that work forward. After all, project management and product management are quite different and intended for different purposes.
But what about the case of internal IT, where the organization does not sell software products but uses software assets to support activities of other departments in the organization? Projects may make more sense in this situation because organizations will occasionally want to change or update their software assets in support of some strategic effort or business initiative, but constant refinement of those software assets is really not desirable.
Paradoxically, of course, some software assets that are the most intertwined with the business of the organization are also the ones that change the most because they are impacted by just about every change the business makes.
Mike Cottmeyer suggests that projects aren't the problem—organizational structures built around a project mentality are. These organizational structures are characterized by placing people in functional silos and labeling them "resources." When a project comes along, people are plucked from the functional silos and put together as a "project team" (actually more like a project group).
Many of these people are also on four or five other projects, each with its own team that may or may not include the same people. When the project concludes, that project team is disbanded and any work done to figure out the dynamics of that particular team is lost.
Disadvantages with this approach include the context switching that people are forced to do between the multiple projects they are working on, and constantly having to progress through the four stages of team development with every new project. One way to solve these problems is to make project teams permanent and bring the work to the team instead of the resources to the work.
Another argument against the “product over project” mantra is suggesting a change in the way an organization's portfolio of work is managed. Project portfolios typically fall into an annual cycle of deciding what will happen, lining up the teams to do that work, and then measuring the projects in ways that reduce likely change to that plan. In contrast, many in the agile community are suggesting that incremental approaches to portfolio planning may be more effective, similar to how some organizations perform product planning.
Implemented properly—using efforts with a specific beginning and end to accomplish a discrete goal—projects can be very beneficial to organizations. The key is understanding how to combine the good aspects of projects that have been around for a while with newer ideas about how teams work effectively and how organizations can coordinate work.
