I recently read a pair of books that talk about project management shifting into product management, particularly in areas of business where there is frequent change - not only software, though this is where many of the ideas here have gotten their start. One is Mik Kersten’s Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, and the other is more of a work-in-process book (and free) #noprojects: A Culture of Continuous Value by Evan Leybourn and Shane Hastie.
I should start by acknowledging that I have been doing project management for many years, both as a practitioner and as a consultant, helping other organizations improve the flow of value via projects. On the surface, these books sound like they are challenging some fundamental elements of what I do. But on reading them, I find a lot of ideas that make sense.
What is the problem these books are tackling? One quote from #noprojects summed it up pretty nicely, “The defining feature of a project is that it is temporary, but software is permanent.” I like this framing, and it particularly helps to justify many of the comments that the #noprojects book claims are to blame on project management. Essentially, the issue is that projects end and people are dispersed to other projects. But software (or other changing deliverables) gets out into the world and there are ongoing tweaks and adjustments and requests made. In a project-based environment, enough changes need to accumulate before it becomes a new “change” project; likely a different team gets engaged; they have a learning curve; and the new product is delivered. This creates episodic deliveries, where the market is more and more demanding frequent (or even continuous) delivery of improvements / changes. In addition, “projects” often become ends in themselves, rather than a means to create value for the organization. Many of the measures and metrics are geared around project success, rather than value delivery.
And this is where I also started getting frustrated. Yes, this concept makes a lot of sense. But many of the challenges of project management discussed in these books are really deeper problems. Mik Kersten seems to describe this a little better in that the project organization gets so tied up in knots over proving its own value that it becomes disconnected from the rest of the business value proposition. His proposal is to not only change this to become product focused, but to also go beyond a refocus the entire company on value delivery. The “projects” are just one element of this - and maybe they become smaller and smaller until it looks like there are teams devoted to value streams that continually look for opportunities to deliver more value to the business AND watch for the situation where they can deliver more value by working on other products.
Another element where I agree with the sentiments in these books is the idea of discipline, skill and involvement. The observed effect in many organizations is that there is a fascination with the artifacts and ceremonies - be they project management or “agile” or anything else - that people forget why they are doing things to begin with. We have daily standups because that is what “agile” teams do. We have big-batch delivery because that is efficient. We have annual budget cycles, so every project is a year long and costs the same. This is not the fault of project management (or agile or …). Sadly, it’s the fault of lazy thinking.
Can “project management” still exist after raking over the coals of this kind of damning writing. I suspect so. But I also suggest that people who do project management should look at these kinds of books and think what can be taken from them. Do the things that are done in your project management environment actually help the organization grow and improve? Keep that. Find ways to discard or de-emphasize the things that aren’t working. This is one of the things I love about the the learning cycle that both books describe - take some action, review what it achieved, adjust based on what you’ve learned. Learn. And learn again. Sometimes this is a hard pill to take all by itself - it might be easier to stay in what is familiar.
So what is the direction of the solution? Essentially, emphasize value and flow. Find ways to deliver value early and often. Ensure that there are ways to STOP when the value diminishes. Always seek opportunities to improve value and flow. This will mean different things for different organizations. One of the harder things for people to do is NOT do something - there must be ways to help decide what NOT to do or what not to do NOW, and they have to be relatively easy to see and understand or people will subvert the mechanisms. A big aspect of value delivery is understanding the entire flow of value: Value does not come out of hyper-optimizing everything and everyone in the organization, it comes from finding what is limiting the flow of value and opening it up (and doing it again, and again, and again). These ideas should sound familiar to anyone who has studied Lean or Theory of Constraints.
As to the books themselves, I thought Projects to Products was better written and more cohesive than #noprojects. The latter seemed to be heavily focused on justifying why “projects” are the wrong way to manage software delivery. In Projects to Products I very much enjoyed the description of visits to a BMW Group Leipzig manufacturing plant and the connections Kersten made between flow as seen on the manufacturing floor and the Flow Framework that he has devised and described in the book. I struggled to follow the suggested flow metrics - some made sense and others weren’t as clear. An example might have helped.
Overall, these books present some interesting ideas on how to think of delivering value - whether it is in a project environment or not. And they present a few frustrations for me in that I don’t think the core problem is due to “projects.” I think it is deeper embedded into organizations that are so fractured that the flow of value has been lost. Lets get that righted, and project management AND product management work much better.
Here are some other interesting tidbits I found in the books.
Project to Product
“There was something so fundamentally wrong with the way business people and technologists worked and communicated that even leaders with the best of intentions could still lead their companies into predictable delcline.”
Activity-based proxy metrics (of Agile or PM activity) have nothing to do with business outcomes.
When cost reduction is the goal of projects, you are in danger of cost-reducing yourself out of a job. Or even cost-reducing the company right out of business.
Epiphanies (that set the story for the book). I particularly like the second part of Epiphany 2 - it is the misapplication of the PM model that is contributing to disconnects.
Epiphany 1: Productivity declines and waste increases as software scales due to disconnects between the architecture and the value stream.
Epiphany 2: Disconnected software value streams are the bottleneck to software productivity at scale. These value stream disconnects are caused by the misapplication of the project management model.
Epiphany 3: Software value streams are not linear manufacturing processes but complex collaboration networks that need to be aligned to products.
Noting a supposed successful Agile implementation, “What struck me was the degree to which the activities and adherence to the model were being measured without a clear sense of the outcomes surfacing through those activities.” This is a very familiar challenge I have seen: if we are using the tool, we must be following the process.
In building the story of the disconnect between business and IT: “There is something fundamentally broken about the decision-making framework or organizational visibility that enables a business to get in this state over, and over, and over again.”
Some lessons described in Chapter 2
Lesson One: To avoid the pitfalls of local optimization, focus on the end-to-end value stream.
Lesson Two: If you manage a transformation according to cost alone, you will reduce productivity.
Lesson Three: Engineering/IT and the business must be connected.
#noprojects
Reframing the “iron triangle” of project management (time, budget, scope) as merely the “constraints” corner of a larger “value triangle” of Functional Capability, Quality, and Constraints. (taken from a Jim Highsmith concept)
A nice story at the end of “Value over busy” chapter where the emphasis seems to have been on checking and challenging assumptions about the project, rather than on running the project. I find this to be a very important aspect of developing a justification for projects that is often missed entirely. “We have to do this project because they want us to.” No wonder projects often get a bad rap.
“Stop saying that you need to multitask. All that means is that you don’t know how to say no, plan your work, or define clear and independent outcomes.” - bingo!
“#noprojects … is successful because it takes advantage of (rather than controls) this unpredictability.” This is said with a strong belief that PM attempts to control unpredictability and variability. While it certainly happens, it is not required of project management. We all must life with uncertainty and variability - it exists. Our way of working must work even though it is there.
“The most important question that #noprojects challenges you to ask is, ‘what’s it worth?’” - instead of how much does it cost or anything else.