The Project is Forever

maintenanceFirst 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.

This entry was posted in Analysis, Change Management, Portfolio Management, Program Management, Project Management, Systems Development, Value and tagged , , , , , , , , , , . Bookmark the permalink.

6 Responses to The Project is Forever

  1. The role of a project manager is to lead its project to achieve its objectives with the assigned resources, or to reach the objective on time and within budget.
    If the intention and objective of the project is to produce a software and to deliver on time and within budget, then the project is successful when it does so and the project ends.
    The value of the software will be realised later when the project is finished for a long time.
    Project’s objective and product objectives are different. This is, in some way, a problem because
    there is a difference in responsibility that plays a role:
    – A project manager is responsible for the project (temporary organisation, process, work environment and resources)
    – Architects, analysts, engineers are responsible for conceiving the solution (project’s product).
    Both have thus conflicting interests within the project!
    But …
    It make sense to formulate the project’s objectives as a business objective to be reached, or, to define the project’s objective as being the same as the product’s objective.

    • Thank you, Axel. Yes, that is a way forward in cases where there really are some objectives.

      I have seen many projects where the project manager was simply supposed to do his or her magic and invent a project on the fly. Usually there were not enough resources allocated (and how could there be, when noone knew what the project was all about?) – and, hence, it was really not easy to say how long this should take.

      So, with PMBoK or similar as an excuse, the project manager would then try to define the scope to be such one wich would match the resources and time constraints. And while being correct by the book, this often resultet in a useless – and unused – outcome.

      The problem is often that the project manager is seen as someone who can simply “fix this problem”, including finding out the details. Therefore you can easily find project managers who feel that one of their main resposibilities is to do analysis. But this is often not for the sake of the product, not meant to bring value to the end customer, but simply for ensuring that the project manager can leave the battlefield afterwards without being accused of anything (which often is a real risk!).

      I suggest a more mature handling of projects, end-to-end, focusing on uncovering end customer value and then designing a project that can bring this value. And only then start the project. At the same time, make sure that the project really does bring the value, not just in theory but in real life. Claiming that it is “somebody else’s responsibility” is not good enough – especially if that somebody isn’t aware of it.

      Take a bus driver who is being given a bus, a lot of passengers and an almost empty fuel tank and a brief instruction on “going somewhere”. You would expect a reaction from him, wouldn’t you? Even if he did go somewhere random within the reach of the fuel given, stopped nicely at a bus stop and shouted happily to the passengers that now they were here… he would probably be met by confusion or even anger.

      Yes, they were obviously “here”, but where was that, and why had they been taken here when they expected to go “there”, and there and there? If all passengers was expecting to be taken to each their different place but noone said anything about it, they of course will get disappointed – and they are all to blame. And the bus driver really is to blame as well for not requiring better instructions. And why didn’t he tell about the situation to the passengers, his boss etc.? And so we have a disaster, have wasted time and money and ruined the good people’s relations to each other, because everybody failed. But technically speaking, the project was a success as the objective was met, and the project stayed within the constraints. In real life this example project would not end until the fuel tank was filled and the passengers brought to wherever they needed to go. But projects are often detached from real life.

      A company/organization mostly has a good chance to do better than that. Let’s make sure that it does!

      • Well, I encountered projects were “we all know what’s the purpose of the project. And we formulate objectives, just to have some. So let’s do what we have in mind.” Nobody cared about the objectives. And goal modelling is something for the planet Mars.

        I see in PM as well as in BA that there is a nice BoK and other standards, but that the customer/client/organisation and maybe others simply tell the PM or BA what’s his job is and what’s expected from him. IMO, we, in IT, absolutely need to educate our clients.

        Normally, a business case, a feasibility analysis or any other form of preliminary analysis should be done before a project is started. It will then provide input for objectives and scope. Nevertheless, the product is defined during the course of the project. And estimations can only be more or less reliable after the design phase.

        Just like you, I prefer business objectives as project objectives and providing priority number 1 to create business value and a ROI that is greater than 1. Then projects will be managed differently: It is more important to create something useful, the greatest possible value, than to reach a deadline. IMO, deadlines are incredibly destructive for quality and business value. the project is finished, when the product is finished or mission accomplished (or when the project is stopped), but not when a date is reached.
        Defining projects as business objectives, will probably help all the people to work together to those objectives and it may promote a multidisciplinary approach.

  2. Pingback: Your Passport to Sustainability | Lean Six Sigma for The Blue Economy

  3. You make some very good points, Axel.

    Btw., I have looked at your blog and it seems like you have thought about – and told about – many important issues in IT, so I have put a link on my blogroll (in the footer of this blog).

  4. Pingback: Change is a direction – not a goal | The No Crisis Blog

Leave a Reply