IT-Projekte, Projektmanagement, Softwareentwicklung

Wieviel Geld läßt sich mit einem Blog verdienen?

2009-01-30T12:03:00.008+01:00

Es ist soweit. Seit heute ist GoogleAds scharf geschaltet. Ich bin gespannt, wie sich das Konto entwickelt und verpreche hiermit zu posten, wenn die erste Überweisung ansteht.

Wieviel Geld läßt sich im Internet oder mit Google Adsense verdienen?

Diese Frage haben sich bestimmt schon viele gestellt. Ein Blog ist meines Erachtens erst dann finanziell attraktiv, wenn er sehr viele Besucher zu verzeichnen hat. Es gibt sicherlich einige Tricks, wie sich die Besucherzahl erhöhen läßt. Entscheidend sind aber die Beiträge. Sind genügend informative Postings und sonstige Inhalte beisammen, steigt auch die Besucherzahl und dadurch automatisch die Einnahmen. Ein ganzes Netzwerk an Blog's ist dazu bestimmt auch hilfreich. Ich glaube aber nicht, dass sich mit einem deutschen Blog wirklich nennenswert viel verdienen läßt (sehr seltene Ausnahmen bestätigen diese Regel).

Dennoch bin ich gespannt, denn Kleinvieh macht bekanntlich auch Mist!

Auswirkungen von Druck in den Projekten

2009-01-30T11:59:00.006+01:00

In IT und vermutlich auch in allen anderen Projekten kommt es sehr oft zur Ausübung von Druck seitens des (Top-) Managements. Diesen Eindruck habe ich in meinen mehr als 10 Jahren Berufserfahrung in diesem Umfeld gewonnen.

Es gibt lobenswerte Ausnahmen, jedoch ist die vorherrschende Meinung, dass nur durch Druck Menschen zu höherer Leistung angespornt werden können. Ist das wirklich so? Jeder Vorstand, CIO, Projektmanager, Produktmanager, Programm Manager und auch alle anderen an Projekten beteiligten Personen sollten sich das fragen und dabei auch das eigene Gemüt mit einbeziehen.

Meine Meinung zum Thema „Druck ausüben“ ist klar. Zum einen werden Menschen nicht schneller denken, nur weil seitens des Managements Druck gemacht wird. Zum anderen wirkt häufiger Druck eher lähmend und verlangsamt somit sogar langfristig den Fortschritt der Arbeit. Druck und damit einhergehende Mehrarbeit über einen längeren Zeitraum hinweg ist also eine Methode zur sicheren Senkung der Arbeitsproduktivität. Über eine kurze Periode hinweg kann etwas Druck und Mehrarbeit auch hilfreich sein (z.B. vor einem wirklich wichtigen Termin). Entscheidend ist, dass der Druck nur kurzfristig und auch nur bei wirklich wichtigen Terminen ausgeübt wird. Die Konzentration wird dann auf diesen Termin und auf die eigene Arbeit gelenkt. Es entsteht ein Gefühl für die Wichtigkeit der Arbeit. Langfristiger und ständiger Druck wirkt jedoch lähmend und wenig motivierend. Solche Methoden führen dazu, dass Mitarbeiter/innen geistig abstumpfen und zum Dienst nach Vorschrift übergehen.

Seitens des Managements wird Druck oft eingesetzt, da die Alternativen wie Mitarbeitermotivation, Bildung von Hochleistungsteams usw. sehr schwierig zu realisieren sind. Daher kann ich mich der Annahme, dass ständiger Druck und Mehrarbeit oft als Alibi dienen, nur anschließen. Nach dem Scheitern eines Projektes wird dem Management kein Vorwurf gemacht. Es wurde schließlich alles getan. Das Team wurde doch stets unter Druck gesetzt und auch Überstunden waren an der Tagesordnung. Mehr kann doch ein Manager nun wirklich nicht tun! Oder etwa doch?

Interessantes Interview mit Tom DeMarco

2009-01-27T15:44:00.004+01:00

Tom DeMarco wurde vor allem durch das Buch "Der Termin - Ein Roman über Projektmanagement" bekannt. Seiner Aussage, dass der Mensch und nicht die Technik der entscheidende Faktor in der Softwareentwicklung ist, stimme ich uneingeschränkt zu.

Link zum Interview:
http://www.sigs.de/publications/os/2008/06/interview_DeMarco_OS_06_08.pdf

IT Projekte scheitern sehr häufig. Warum ist das so?

2009-01-27T10:42:00.001+01:00

Nach diversen Studien wird etwa jedes fünfte IT Großprojekt vorzeitig abgebrochen und fast jedes zweite Vorhaben dauert länger oder wird teurer als ursprünglich veranschlagt. Diese Reihe von Berichten geht auf die größten Probleme in den Projekten ein und zeigt mögliche Lösungsansätze.

Teil 1: Aufwandsschätzung

Bevor Auftraggeber und -nehmer ein Projekt zur Entwicklung von Software angehen, ist ein gemeinsames Verständnis zur Entwicklungsmethodik von großer Bedeutung. Der Software Lebenszyklus geht in der Regel mit der Dokumentation der Anforderungen durch den Auftraggeber los. Anschließend werden die Anforderungen vom Softwarepartner auf Machbarkeit. Bevor die Verträge unterschrieben werden können, müssen sich die beiden Parteien unter anderem über die anfallenden Aufwände einigen. Es ist notwendig, sich intensiv mit den Anforderungen zu beschäftigen, bevor eine Aussage über den anfallenden Aufwand - meist in Manntagen ausgedrückt - getätigt werden kann. Hier liegt eine erste sehr große Gefahr.

Eine Aufwandsschätzung „aus dem Bauch“ heraus mag für viele Auftraggeber ausreichend sein. Meistens ist nicht einmal die anfängliche grobe Schätzung das eigentliche Problem. Vielmehr sind es die teilweise nur „stichpunktartig“ beschriebenen Anforderungen, welche erst im Laufe eines Projektes näher dokumentiert werden. Je nach Reifegrad müssen die Anforderungen unter Umständen umfangreicher beschrieben werden. Dadurch lässt sich der Aufwand genauer beziffern. Durch die erste grobe Schätzung sind jedoch Erwartungen des Auftraggebers hinsichtlich des Projektumfangs und den damit verbundenen Kosten entstanden. Es besteht die große Gefahr, dass bei Nichteinhaltung dieser Erwartungen die Enttäuschung sehr groß ist. Das Vertrauen zwischen Auftraggeber und Auftragnehmer nimmt ab. Misstrauen, ständiges Kontrollieren des Projektfortschritts und andere ursprünglich nicht geplante Aktivitäten sind die Folge und erhöhen zusätzlich den Aufwand und geährden unter Umständen auch die Meilensteine. Es kann hier eine Eigendynamik entstehen, die sich negativ auf den Gesamterfolg des Projektes auswirkt.

Die Entwicklungsmethodik muss von Anfang an eine hinreichende Dokumentation als Grundlage für die Aufwandsschätzung vorsehen. Ist diese nicht vorhanden, sollte der Softwarepartner zunächst selbst die Anforderungen ausformulieren und erst anschließend die geschätzten Aufwände in Verbindung mit einer detaillierten Anforderungsbeschreibung kommunizieren.