The main goal of PrjPlanner is to give an idea of a project's status very quickly and intuitively. I believe the information radiator does this. While we can quibble about definitions, it is obvious and agreeable by all that tasks start at 0% complete and 0% correct and when a task is deemed finished by a developer it is 100% complete and 100% correct in the developer's mind. So with a quick glance, one can determine a project's overall state: Are all the tasks near the origin, somewhere near the middle, or near the upper-right? This is enough for task management for developers, small teams and their immediate managers.
Now, what the professional project management tools attempt is to define these for you. Completeness is generally the percent of work done on a task to the developer's total effort estimate. The developer said it would take 6hrs to complete this task and she has worked 1.5hr on it so it is 25% complete. Correctness is generally the percent of tests passing out of the total number of tests. The developer has written 14 tests and 3 are failing so the task is ~80% correct. When put this way (eg. simply) those are arguably (though by few developers) reasonable metrics. When implemented within the massive systems already discussed they become noise to developers. They become weapons for managers to beat up on developers. Developers begin to hate the systems, management, and project management in general (preferring to just be left alone and wishing they could tell their management: I will tell you when I am done, dammit!). The systems are no longer an instantiation of a methodology to help developers do their job or inform their management, but become excuses for one level of management to defend to their management why the project is slipping.