First published in Danish at No Crisis-bloggen.
Today’s project management philosophy is largely about reducing the scope of, and finishing the projects. It seems like if success is to be found in simply carrying out the project, no matter what it actually delivers to the organization.
“We did it! On time, on price and with agreed functionality” is what all project managers are expected to shout exactly at deadline. Mentioning that projects must continue is considered heretical by the project management society, since it is the main feature of projects that they end.
But honestly: which value does it bring to the organization that the project has ended? Doesn’t the value rather come when the project delivers a result, which then allows for a sustained benefit – that the project has created a persistent change, which then also need to be maintained if it should preserve its value?
You know this idea of value creation from many places, not least from product development. Even the cheapest toaster comes with a user guide and sometimes a maintenance manual. Many products additionally come with maintenance and repair manuals. Your car, for instance, has all of these guides. Some for you and some for the mechanic.
Most projects are supposed to deliver lasting value – maybe forever, maybe just for a long time, but typically for at least some time beyond the project. Therefore, it should be considered reasonable that the project at least is established only when you’ve decided what value you expect to get out of it. For only then it is possible to define a useful goal for the project. But surely, it is just as reasonable that part of the project is dedicated to ensuring that the value it is supposed to lead to can actually be achieved, and that it can be maintained.
In systems development projects it has always been considered good style to produce proper documentation for, and as part of, the developed system, sometimes specified as a number of different manuals, as I described above. However, with the increasing focus on project management as a separate occupation – not an occupation related to product development but rather an occupation that only relates to itself – the project itself has become the goal: simply completing it is considered a success. And then the future and achieving the value is ignored by the project manager and will, perhaps (who cares?), be handled by others.
Fortunately, there is a kind of counter movement to this introspective project management trend: value management. Often with an emphasis on pure economic values, but it does not have to be that way. If you always make sure that projects are part of a larger frame, for example called a program or a portfolio, in which analyses are carefully made, along with expectation building for the project’s value, you can from there require certain features of the project – eg. that it should not only deliver a product or change, but also the necessary guidelines and procedures for ensuring the best use and utilization of the delivered, and for sustaining the value created.
And then you get close to what, with the above in mind, perhaps no longer looks nearly as heretical: that the project will have a “perpetual” value, that is is going to last “forever” in that it is going to be a guiding and influential – and useful – activity that helps shaping the future of the organization.