“Feierabend, alle Bugs behoben und alle Change Requests sind eingecheckt, der Zug nach Hause fährt in 5 Minuten – und schon wieder keine Zeit, die tägliche Projekt-Stundenerfassung zu erledigen. Morgen wird der Projektleiter erneut auf der Matte stehen und meine fehlenden Reports eintreiben, um die monatliche Verrechnung und das Projektreporting gegenüber dem Kunden zu erledigen. Das muss doch auch einfacher und schneller gehen!”

Genau das haben wir uns auch gesagt und kurzum eine Web-Applikation entwickelt, die folgende Bedürfnisse abdeckt:

• Zeiterfassung komfortabler machen
  > Rasch & bequem
• Unabhängigkeit fördern
  > Örtlich (mobil)
  > Software Client
• Business
  > Alle Stunden lückenlos im Projektmanagement-Tool erfasst

Die entwickelte Applikation weist folgende Merkmale auf:

• Browser-Applikation, für iPhone optimiert
• Live Datenschnittstelle zu Projektmanagement-Tool
• Geführte Auswahl von Kunden über deren Projekte, Tasks und Zeit zur Workreportbeschreibung
• Visualisierung des persönlichen Tagestotals/-Soll
• Länderübergreifend (CH/DE)
• Ajax Technologie (keine Page Reloads)

Somit steht einer zeitnahen und mobilen Stundenerfassung nichts mehr im Wege.

Da es sich um eine interne Anwendung handelt, haben wir zur Veranschaulichung nachfolgenden Screencast vorbereitet.

ReportNow wurde im Rahmen des Namics.Lab 2009 im Team Andi in zwei Tagen entwickelt und erweitert die NOW-Familie um eine weitere Anwendung (vgl. RoomNOW).

Das Lab-Entwicklungteam bestand aus den Personen Markus Koller, Alexander Maier, Ben Roberts, Patrick Graf und Andri Stoffel.

Die Möglichkeiten von eCollaboration und Web 2.0 werden auch sehr häufig für die Abwicklung von Projekten genutzt (project collaboration), sei es als Anpassung einer Plattform wie Sharepoint oder Confluence oder als spezifische project collaboration Software wie z.B. projectInsight .

Im Bereich Projektmanagement werden diese Möglichkeiten noch sehr wenig genutzt bzw. es gibt sehr wenige Systeme, welche Collaborative Project Management oder Project Management 2.0 explizit unterstützen.

Systeme wie ProjectInsight bieten zwar webbasiertes Projektmanagement an, aber gehen noch von einem herkömmlichen Projektmanagement-Ansatz aus. In den verbreiteten project collaboration Plattformen wird das das eigentliche Projektmanagement auf einzelne Aspekte (z.B. dezentrale Kommunikation und Information oder dezentrale inhaltliche Abstimmung) reduziert.

LiquidPlanner ist hier eine erwähnenswerte Ausnahme.

Mit LiquidPlanner werden Projekte nicht zentral von einem Projektleiter geplant, sondern alle Teammitglieder tragen zur Planung bei. Sie können Tasks erfassen und anders anordnen, können Tasks kommentieren und ändern.
Für die Aufwandschätzung werden minimale und maximale Werte erfasst und die Termine werden aufgrund der Ressourcenverfügbarkeit und Priorität gerechnet, sofern keine Start- und Endtermine erfasst werden. Die Priorität wird aufgrund der Reihenfolge der Tasks berechnet.

Liquidplanner kalkuliert auf dieser Basis die wahrscheinlichsten Aufwände und Termine, was in einem statisch korrektem Projektplan resultiert.
Sehr interessant finde ich, dass richtige Schätzungen abgegeben werden, d.h. Wertebereiche und keine Einzelzahlen.

Liquidplanner benutzt diese Werte und errechnet die Wahrscheinlichkeiten für das Einhalten dieser Schätzungen. Dabei wird davon ausgegangen, dass die Wahrscheinlichkeiten normalverteilt sind.

Leider kann diese Glockenkurve nicht verändert werden. In der Realität dürften die Wahrscheinlichkeiten eher eine schiefe Verteilung haben.

Remember the first time your son or daughter held a helium balloon in his hand? What happened? Sooner or later, that balloon got away and s/he was very unhappy, to say the least. One might even say, traumatized. Why? Because s/he lost the balloon? That’s certainly part of the answer, but it’s not the whole story — kids lose things all the time, without the emotional trauma of that first balloon.

That balloon’s flying away contradicted “years” of experimental evidence (generally obtained using food from the kitchen table) that things always fall down. Always. Dependably. Reliably. Certainly. Despite this certainty, that balloon fell up. The world is not in order. And that is what was so disturbing.

So you have just started using Scrum to manage your first development project. You have 6 months to complete the project. The remaining effort on your project is estimated to be 600 Story Points (SP), which means you have to complete 100 Story Points per month. So far, so good.

Then your team executes its first Sprint and completes 50 Story Points. At this rate, it will take 12 months to finish the project ( 600 SP / 50 SP per Month = 12 Months). So you tell your boss you have a problem, you’re going to be 6 months late, on a six month project. What does you boss do?

• Kill the messenger (what else?)
• If that fails, blame the methodology (which is kind of the same thing).

Why is he reacting this way? For him, a balloon is falling up. Typically, early in a project, everyone is optimistic.Serious problems only become apparent later in the project, shortly before a major development milestone. So when a deadline problem escalates, it is serious and doesn’t leave much room to maneuver.

BTW — yes, I have had the pleasure of taking over a project in which the program manager had invested a large sum, only to be told shortly before the target date that it will cost another equally large sum to finish the project. Bad thing. No fun for anybody involved. And the program manager really only had two alternatives: Cough up the money or cancel the project. Either way, he had to explain it to his management (and is not going to look good in the process).

Come back to our Scrum example. Probably this program manager had never gotten such early warning that project was having problems. So how is he going to react? Exactly as he has been conditioned to through every other project that has been late, only more so, because if a warning occurs this early, something must be seriously wrong.

But wait! Only 1 month has gone by. The are still 5 months to go. You can react. You can identify the problem and make adjustments. Why is the development proceeding so slowly? Are there enough people? Are they the right people? Maybe you can reduce the scope and still achieve your business goals. Maybe your developers are being distracted by other tasks. There are a lot of ways to fix a project with over 80% of the time remaining.

Together with the Product Owner, the Scrum Master and other management can take action to correct the problem early and effectively.

Once management has learned that they have control, can react and can prevent disaster long before it occurs, they will no longer be tempted to kill the messenger. In fact, they will welcome the messenger and appreciate the methodology, because early warnings will ensure that management looks good when the project comes to a successful and timely conclusion.

For a long time, I thought project management was a pretty worthless science. At worst, it was a line item on the invoice with no clear deliverables. At best, it seemed focussed on producing mountains of paper which no-one ever read; what little software it produced was bloated, overweight, over-budget and behind schedule. Good for big companies and huge projects, but over-dimensioned for the rest of us.

Okay, I’m being a bit global in my accusations, but let’s be honest: How many software development projects come in on-time, on-budget, and with functions that the users really want? (How much of, say, Microsoft Office do you know how to use? I rest my case.)

In the course of the last year I have been increasingly interested in so-called Agile methodologies: Scrum for project management and Extreme Programming (“XP”), the corresponding engineering discipline. For me, it clicked. These are methodologies that focus on producing working software, give the user what s/he wants, and produce a positive return on investment (ROI) for the company investing in the software.

How does it work? Simple. Define the product in terms the user understands: what s/he can do with the software and why. Together with the team, define the milestone (something that can be demonstrated) and implement it within one month (don’t change the goal at all during that month). Demo the result. Get feedback, adjust your plan if necessary, and repeat until ready to ship.

Why is this better? Under classical project management, the development team works like a taxi fleet. Although centralized planning tries to optimize utilization, each taxi is ordered and dispatched individually. If a taxi gets lost, runs late, or changes destinations, this has consequences. While these tend to be cumulative in their effect, aside from the overall project running late and over budget, it is hard to know exactly what went wrong.

Under Scrum, the development process is like a scheduled freight train. The train departs every hour and arrives 50 minutes later. One person (the Product Owner) decides what gets on the train. One person (the Scrummaster) is responsible for keeping the train on track. The team runs the train. If the train is delayed, everybody waits and everybody is aware of the problem. Once the train has departed, nothing else can get on and the train drives on to its planned destination.

After an hour, everybody knows where the train is. Since the schedule is important, no one is allowed to change the destination en route. Changes can be made, but only when the train is in the station (except in emergencies, of course), and only under the direction of the Product Owner.

Scrum operates through simple rules that can be applied to complex situations. It’s easily understandable. Progress is easily measurable (I graph progress and change in scope every iteration). Most important, the playing rules prevent the bad things which cause projects to go astray.

Technorati Profile