Project vs. Product – Organizational Focus

Sometimes, my clients ask me which are the best organization structures that support a move to agile approaches. There are many ways to characterize their organizational structure and focus, but a common view I use is this:

Are they aligned as a Project-based organization or a Product-based one?

You can move to agile methods with either focus, but I think a Product-based focus makes it easier. Let’s explore the dynamics of each. This will help you determine where your organization currently resides AND how you might want to shift your focus if you’re thinking about agility.

What is a Project-Based Organization?

To start the conversation, let’s focus on some of the aspects of a Project-based org:

  • You view your work as a series of projects to be delivered. They have a finite beginning, middle, and end. They have a budget. Usually, they have fixed scope and dates with perhaps limited flexibility for spending to add people.
  • Often the teams or people are considered and termed “resources” in this way of thinking with the team being cobbled together specifically for the project. Even more often, the “resources” are multi-tasking across other projects or heavily interrupted in general. (I.e. there is little focus.)
  • The organization is simply looking for someone to say, YES, we can name that tune in 5-notes. I often see pressure for internal teams to commit to a project because of a threat to get another team/organization to do it. These are often offshore / nearshore / contract firms.
  • When the project is finished, all of the people are reassigned to the next bit of project work. Typically, teams don’t stay together for very long. Another side effect of this is that ongoing project maintenance, for previously “completed” projects”, isn’t very well understood or managed. It interrupts the next set of projects.
  • In larger scale environments, there is usually a Project Management Office (PMO) and project managers who are assigned to manage, track, and report on project progress. Once the projects have been “approved,” there is the notion of staying on track or getting back on track, so variance is seen as controllable.
  • Projects are often considered as independent, with little to no cross team or cross organizational dependencies or impacts. This is a naïve view.
  • From an outward expectation’s perspective, these dates are typically communicated to customers and stakeholders by the PMO. The PMO is often abstracted from the execution reality of the projects or they might be obfuscating the project status in the false hope that things might recover. Either way, expectations are often mismanaged and misinformed until very late in the project.

I must say that most of the above is how I’ve worked with projects for much of my career. Terms like waterfall projects, traditional projects, and command & control organizations typify this sort of focus.

What’s surprising is that I often see this Project-Based mindset applied in agile contexts. Organizations are adopting agile practices at a team level but are still clinging to a project-based mindset across the organization and within the leadership team. You see it most strikingly within the PMO and within the mindset (and practices) of the middle management team.

In the next part of this series, we’ll explore what it means to product-based in our thinking and execution.