Writing a good headline is key to getting someone to read your article. For instance, “Project management: A surefire way to kill your software product” is an excellent title. He even starts off with a good sentence:
For many years, I have observed that the quality of software produced by organizations is a decreasing function of their emphasis on project management over business value creation-that is, their obsession with predictability and efficiency over learning and adapting.
Or in “Don Speak”, the more obsessed you are with following the plan, the more likely the product is going to suck. (Yeah, I really talk like that.) I encourage you to read the article.
Surprisingly this was not the only project management focused article that crossed my desk in the last few days. Forrester also released an article on “Agile PMOs Focus On Portfolios, Not Projects“. It is along the same vein in that both articles think that strict adherence to a plan does not guarantee success (unless success is measured by dollars and dates and not business value and truly useful products) and that both articles insist process re-engineering needs to occur internally as well as with business clients.
The “rules” and “best practices” from even 10 to 15 years ago are now responsible for the horrific ball-of-mud monoliths that so many enterprises are struggling to escape.
Let me say that again: The best practices of the last decade-plus project-centered thinking-produced the legacy mess that developers rail against. Today’s seemingly elegant architectures and practices will probably be regarded as poorly in a decade or two. That’s what progress is all about: finding better ways.
We need to constantly evolve. The systems that we produce need to constantly evolve. We need to develop processes that can change. We need to develop systems that can change. We know this. We should know this. Every line of code we write today will likely be re-written within 10 – 15 years. If it has not, then we have a problem in that the system has not evolved and that is a problem. Services, microservices, decoupling of interfaces, object-oriented programming, functional programming, agile, devops, service virtualization, the cloud, and a billion more terms and phrases are all responses to the idea that things change, that they have to change.
So should project management. The focus on the dollar, the date, is causing us to develop applications in a less than optimal manner. Instead of doing the “right thing” we do the “cheapest thing”. Cheap does not necessarily mean right. If you are asking for one centimeter ball bearings with a specific metal composition and smoothness, then you can probably go with the cheapest. But software development?
Software development is fundamentally an exercise in learning, while the traditional command-and-control style of project management seeks to optimize the execution of known, repeatable processes at scale.
For software development, no significant developer activity is predictable or repetitive; if it were, the developers would have automated it already. In addition, learning is essentially a nonlinear process; it involves trying things that don’t work in order to discover what does work
To be creative project managers need to understand the shackles around the project and do their best to give the developers the autonomy they need within the boundaries. And if that means dismantling existing processes, then I say go for it.
(And now let the complaining roll in.)