Project Mis-Management: TaskJuggler Drops the Ball

At work the other day, I was bemused when one of the IT staff walked into a boardroom, took a marker, and wrote with large letters, "WHY DOES EVERYTHING HAVE TO BE SO DAMN HARD." When I asked what his problem was, he said, "Project managers."

Project management--that is, the attempt to organize resources and people to meet a common goal--is a bit of a sham. Although traditional project management is about Gantt charts, spreadsheet breakdowns and allocation of resources (human lives), these techniques are more about looking organized than being organized ("The Underlying Theory of Project Management is Obsolete", Lauri Koskela [PDF]). Statistics tell us that the majority of managed projects in IT are delivered late and defective and almost a third of all projects are cancelled before they are delivered ("Why Software Projects Tend to Fail"). Even Windows Vista arrived many years late and with most of the promised features missing ("Go Home, Bill", Cringley).

We know some things from experience. That adding more manpower to a late project will make it later (Brooke's Law, Wikipedia). That longer hours and stress do not improve software productivity (Tom Demarco). That developers are not generic "resources" or skill sets ("IT Hiring: We Don't Want the Best", The Tyranny of the Label", Lone Coder). But in the end, many project managers still insist that a project merely consists of coming up with reliable milestone estimates, accurate breakdown of subtasks by the 100% Rule, mathematically-provable critical paths and assignment of generic resources--plus 50% or more in fudge factor time since none of these things possible in the real world. Such a project plan is not, by definition, a plan at all.

As Koskela puts it, "All in all, systematic project management is transformed to a facade, behind which the job actually gets done, even if with reduced efficiency and lessened value to the customer." And "in the present big, complex and speedy projects, traditional project management is simply counterproductive; it creates self-inflicted problems that seriously undermine performance."

In Information Technology, I think there is something more going on. The real work of project management, or management in general, is dealing with the intangible human elements that are difficult to qualify. Why is Fred frustrated with his job? Why are different departments not communicating? How come our hardware or software isn't performing as expected? Why are we not meeting our quality goals? How do we bestow a vision for our developers to accept and follow? These kind of questions cannot be quantified on paper or entered into a workflow program.

Nevertheless, many project managers insist that the plan is more important work than dealing with the tougher, human questions of management. Perhaps there's a "Geek Factor" here. Inventing numbers and entering detailed data, especially for anti-social people with a background in software development, is an easy retreat from doing the real work of dealing with real people.

I once had a manager who scheduled a weekly "collaboration meeting" but marked it as low priority. When I asked why, he merely responded that spending an hour a week on issues not specific to any project--issues such as post-mortems on failed projects and solving personality conflicts--was not as important as creating new schedules and getting projects out. How do you get the projects out without solving these underlying human problems first? This one hour weekly meeting to improve the culture, work environment and communication can be more important than traditional project management for improving project delivery, as suggested by some consultants such as Karl E. Weigers (Process Impact).

This retreating from real-world issues, I believe, is one of the reasons many IT projects aren't delivered on time and on budget.

These principles came to mind as I began to examine TaskJuggler (www.taskjuggler.org), an open source project management tool. I've become cynical over the years of any project that describes itself as "powerful". Powerful compared to what? It is often a defensive word to cover up a project that is actually very weak. The home page goes on to add it's powerful if you can get used to using it. Ah, this is a very bad sign.

TaskJuggler is available for most versions of Linux. I tested TaskJuggler 2.2 on Ubuntu 6 in coLinux and TaskJuggler 2.4 on Fedora Core 9.

My initial impression of TaskJuggler was "Yuck! XML?!" Well, not really--everything is declared in a manner of C-style declarations with curly brackets--but it's essentially XML reformed as C: a nested declaration grammar that the user has to edit by hand. In fact, TaskJugger was originally a console-based tool that compiled hand-entered project files. The addition of the GUI interface sounds impressive...except that the GUI interface is basically the KEdit widget (KEdit, Wikipedia)) for editing your XML files. Don't expect a nice user interface with an "Add Task" button here.

task bigProject "The Big Project" {
  task start "Start" {
     milestone
     maxend 2008-08-31
  }
}

Beyond the awkwardness of designing a project in XML, TaskJuggler approaches project management as a mathematical exercise: if you can describe every tiny piece of information about a project--every day, every person, every task time estimate, the risks and tolerances allowed--then TaskJuggler should produce a perfect project plan. Of course, we're living in the real world where such numbers simply don't exist.

For example, to specify priority, TaskJuggler uses arbitrary numbers between 0 and 1000, not criteria such as financial cost or project risk. What exactly does priority 600 mean and how do you determine if 600 is a reasonable value? TaskJuggler doesn't explain how to tie such abstract numbers into real-world meaning.

Then there's the documentation. Team members can be collected into sets of developers by nesting XML tags. But if you assign a group of developers to a task, does TaskJuggler assign all the developers or just one? How do you allow TaskJuggler to assign a developer from a pool? The documentation doesn't say.

resource developers {
  resource ken "Ken Burtch" {
    limits {
      dailymax 6h
    }
}

I finally figured out how, examining the examples on the web site. The only way to do this basic task is through a wordy structure with hard-coded resource names. You can wrap that into a macro, but then you're leaving the structure of the project design langauge for a hack using something that looks like shell scripting. From a language design standpoint, it is like trying to combine two different, unrelated languages into one file. Clearly the marcro is used to cover up a serious flaw in TaskJuggler's design.

macro one_c_developer [
  allocate abe { alternative bill, charles select minloaded }
]
...
task develop_phase1 "Development phase 1" {
  effort 5d           # 5 days
  ${one_c_developer}  # assign anybody
}

Even reports must be designed in it's awkward, C-like language. There's no buttons to press to get even basic reports. Once you design the reports, such as Gantt charts, you can display them on TaskJuggler's GUI window.

The TaskJuggler language is a language that describe most projects...but being get the information that TaskJuggler requires, with sufficent accuracy to get a realistic project plan, is another matter. With TaskJuggler, you may end up taking longer to describe and test your project design than the project itself would take. It represets the pinacle of the traditional project management approach, an approach that is well-known not to work. After all, your plan is only as good as your margin of error, and the margin of error has been shown by studies to be very high.

If Koskela is right, that project management isn't about meeting deadlines and making good use of resources but really about putting a smoke-screen in front of management so they won't bug you, then perhaps TaskJuggler has some value as a butt-covering tool. And if you're an introverted IT manager, you can spend hours twiddling the project design and never have to talk to a single person. But don't expect TaskJuggler to help you enter your progress or help you get that critical project done on time to save your career. It takes traditional project management to the level of fanaticism.

Other open source project management tools, like Dot Project (http://www.dotproject.net), are far superior to TaskJuggler. At least, they let you input data through a visual interface. I can only hope that the upcoming TaskJuggler 3 will deliver on the promise of "powerful" and "modern". For the moment, it would be best described as:

taskjugger {
  design misguided
  effort ridiculous
  results bad {alternative unreliable}
  benefits questionable
  rival_projects superior
}

July 15, 2008