“I always get a little grumpy on hearing someone say project”
Marcus Raitner currently invites interested parties to join the blog parade on “Beyond Project Management” in his blog “führung-erfahren”.
“Beyond Project Management” is also the motto the orga team of the Dornbirn PM Camp agreed on for the 2014 PM Camp. As I see it, this is a great motto.
Now I am reading my way through the blog parade “beyond project management” and discovering that I find plenty of correct and reasonable ideas in all the articles. And I am truly enthusiastic and would recommend for all of you to read the nice blog parade contributions.
🙂 The more I read, however, the more thoughtful I get. In fact, I already wrote two blog parade articles – and here comes the third one.
In fact, I already wrote two blog parade articles – and here comes the third one.
In one blog parade article, you will, for instance, find that project management is basically about practice, simplicity, people, leadership and, above all about making sense.
I find that truly great!
Except:
What exactly do practice, simplicity, people, leadership and making sense have to do with project management in particular and management in general?
Also, I read a wonderful story in the blog parade. It shows how absurd project management in the private sector can be. And I ask myself how something that does not work in real life is supposed to be a success in an enterprise? After all, we are always dealing with human beings, aren’t we?
- Projektarbeit bedeutet Ergebnisse unter Unsicherheit zu liefern und
- Projekte werden nicht genehmigt, sondern finanziert.
In another article, I find important sentences, such as
- project work means delivering results under uncertainty and
- projects are not authorized, they are financed.
Well, this is certainly true. But what does it really mean when all is said and done? Here is how I understand it:
The results of (project) work that made sense must – at the latest – “work constructively” from the time the customer uses them for his enterprise. How is that supposed to work out if you realize something that has been planned a long time ago and is then still used at the planned (and then probably unsuitable) time?
Here is my personal experience:
In my (IT) projects, it never ever happened that I delivered the project result as specified at the beginning of same project. The final result was always something that differed considerably from what we had expected to get at the outset. Sometimes it was reduced or massively changed even before the original deadline. Fortunately (?), the result was always something the customer actually desired and consequently, it was always appreciated. This was very important, since you should not forget that the customer is usually the one who pays a lot for the final product. Besides, we also wanted our customers to come back later with more orders.
This is how I learned that both the time of delivery and the solution have to be what the customer wants if you want him to be happy. If I had delivered exactly what was originally agreed upon at the desired time even once, the customer’s goodwill towards me would soon have dwindled to nothingness.
Consequently, we have to deliver a true added value to the customer if we want him to gladly pay us and return later with new orders. And usually, this will not be precisely what he used to believe he needed and ordered several months or even longer ago.
Of course, this also means that you have to decide together with the customer why you deliver something other than was originally desired. Such a process is not easy and costs more than just strength. It actually calls for many talents.
As I see it, happy customers cannot be gained through the currently still valid meaning of the word project:
A project is a planned process which starts at a determined time, has a precise goal, fixed parameters (cost, time) and a non-negotiable end.
To be sure, this definition sounds nice. But it originated at the time of Taylorism and industrialization.
Here is what I believe:
A project is not a project with a clearly defined goal. Instead, it has an open ending. And those who are “responsible for the project” must be a team of entrepreneurs who are competent in many roles, among them “understanding” and “persuasion”.
I never knew a “project” that ended up with exactly what had been planned at the beginning. Even the best “requirement engineering” never managed to do that. There were always huge modifications in the functionality, costs and delivery date. Especially with huge projects, I often witnessed differences that sooner or later became gigantic.
Following these ideas, one might well substitute the word “enterprise” for “project”. That would give us a definition looking more like:
An enterprise tries to shape the future attempting to match yesterday’s assumptions with today’s reality and tomorrow’s requirements. And the process is a continuous task, with neither beginning nor end.
The reason is that, basically, you will always imagine things totally different from what they will later turn out to be. And you will always learn in the process.
RMD
(Translated by EG)
Loading ...