Google hat nun im Google+ die Communities freigeschaltet.
Der Blog wird damit nun hier fortgeführt:
Google+ Community IT Management

Stages towards business orientation for it-organisations

I think there are some more stages than component orientation and service orientation in IT organisations which makes it easier for organisations to make progress on this long road visible:

1.  Purely technical orientad organisations don't manage IT really. They operate technical items as good as they personally can.
2.   Product orientated organisations know the connections between products (e.g. applications) and there specific operation envirements.
3. Component orientated organisations are able to manage less operations envirements than products exist. They manage technical services as a technical serviceprovider.
4.   Customer focused organisations often try to fulfill the customer expactations, but "forget" the technical abilities and costs. Selling is everything...
5. Service orientated organisations are able to close this gap between customer expactions and provider abilities.
6. The most challenging model is in my opinion the business orientation: The IT organization is able to manage services by maximizing the efforts for customers and the business.

Follow the discussion on Linkedin.com

Auswahl des geeigneten Vorgehensmodells im Projektmanagement

Scheitern Projekte am schlechten Vorgehensmodell oder an der fehlenden fehlende Adoption und Verankerung der  Methoden des Modells in den tagtäglichen Arbeitsweisen?


Posting auf XING: Ausgehend von der Grundannahmen, dass 87% der deutschen Unternehmen ein Vorgehensmodell einsetzen und nur 32% aller IT-Projekte erfolgreich abgeschlossen werden, kann man zu der Erkenntnis kommen, dass dies u. a. an dem falschen Vorgehensmodell liegt. Dies führt zu meiner These, dass es einer Entscheidungsunterstützung bedarf, die individuell für jedes Projekt das geeignete Vorgehensmodell wählt.
Mein erster Gedanke: Wenn fast alle Unternehmen ein Vorgehensmodell für Projekte haben und trotzdem nur eine Minderheit Projekterfolge verzeichnen, muss das nicht am "falschen" Vorgehensmodell liegen. 

• Was nützen mir die besten Vorgaben eines Modells, wenn Sie nicht konsequent angewendet werden? 
• Was bringt mir ein Modell, wenn Bausteine des Modells wie Planung, Zieldefinition, Teamauswahl etc. in der Praxis weder durchgeführt noch eingefordert werden? 
• Was bedeutet eigentlich "setzen ein Vorgehensmodell ein" konkret? 
• Ist das Modell dokumentiert, bekannt, akzeptiert und angewandt oder handelt es sich um die berühmte Paperware oder Schrankware - wurde das in der Untersuchung ermittelt? 
• Würden dann nicht mehrere zur Auswahl stehende Modelle eher noch mehr Schrankware bedeuten? 

Nach meiner Beobachtung ist weniger die fehlende Kenntnis oder Geeignetheit von Methoden und Vorgehensmodellen im Projektmanagement Grund für ein scheitern von Projekten als vielmehr die fehlende Adoption und Verankerung dieser Methoden in den tagtäglichen Arbeitsweisen - getreu dem Motto: "Ich weiß schon, dass ich es anders machen sollte, mache es aber trotzdem nicht so...." 

• Ist die Grundannahme einer Korrelation von vorhandenem Vorgehensmodell und Projektmisserfolg richtig? 
• Ist  ein Scheitern von Projekten auf ein ungeeignetes Vorgehensmodell zurückzuführen? 
• Gibt es Aussagen, ob die Ursache für eine fehlende Adoption und Institutionalisierung von Methoden der Vorgehensmodelle im "schlechten Modell" liegt oder an der herausfordernden Aufgabe, Arbeitsweisen und organisations-kulturelle Prägungen zu verändern?