A fine example of this is the change management procedure. Sometimes more energy is spend in analyzing and discussing changes then in actually creating the changes. The change could have been realized in less time then was spend on discussion and creating paperwork. 

Sometimes this is caused by the complexity of the product but more often it has to do with the misalignment of the stakeholders interests and a lack of trust. Somehow a project that has started with a common goal has become ugly. How come and how to prevent this from happening?

I think a lot of projects have an intrinsic win-win scenario. That’s why the parties decided to work together in the first place. It is very important to state each stakeholders interests in the project explicitly from the start. How can there be trust when the intentions and stakes are not clear? 

The initial project plan should use the win-win mentality as a basis for procedures and responsibilities. This is not naive, it is very effective. 

Sadly often the project manager feels the need for some ‘leverage’ and creates a plan which does not balance each others interest and responsibilities.
Of course what happens then is that the customer is pushed from a collaborative mode into a formal mode with a lack of trust.

Also each time something ‘bad’ happens effort should be put in aligning the stakeholders. This is also often not the case which makes collaboration harder and makes the project team less effective.

There is a very powerful tool to create and maintain focus on project and that is the progress report. The progress report is used to communicate the progress to the project board or senior executive/supplier/user; on scope, budget, time and risks (and sometimes quality). Implicitly it is a kind of measurement system. The success of the project is measured by this progress report. Of course people tend to deliver what is measured, in other words, projects tend to align to the measurement system.

The big question is “does the measurement system reflect the project goal“?
In my experience this is often not the case.

The project’s goal is expressed in the underlying business case. If the business case is not defined explicitly then it still exists implicitly. (There is a reason why the project was funded). The business case should not only describe the development phase of the product (the project itself) but also the production phase of the product (maintenance, support). A common business case is that process improvements lead to a decrease in costs in production.  The costs of the project will then break even in X years.

The problem with a business case is that very often it is defined only once, before the start of a project. When the project commences the business case is never looked at again. That is a shame because the business case not only defines the validity of the project, it is also a very good tool to keep the project aligned on the end result.

In fact, in fixed-price projects, there are at least two business cases. One for the customer and one for each supplier. The customer wants a new product or process improvement. The supplier wants to make a profit on the project. Depending on the amount of “transparency” the project manager should have two progress reports, one on the customers business case and one internally for the supplier. The first focused on the customers goals, the second one on profit.