There are some other good answers here, but "percent complete" is not only tricky to calculate reliably, but it's often implicitly tied to scheduling. That makes it difficult to talk about it without talking about schedule variance, too.
Percentages of Tasks Completed
We've all seen software installers that zoom from 0% to 83% complete in a matter of seconds, and then sit there for a long period of time (minutes? hours?) before moving upwards again. This is an example of task-based completion versus time-based completion.
One way to address this discrepancy is to report your percentages based on "planned man-hours consumed" and "plan man-hours remaining." For example, if a project has budgeted 100 man-hours for a task, and you've spent 75 man-hours so far and have a reasonable level of confidence that you have 25 man-hours remaining, then it would be logical to report that the task is 75% complete.
Personally, I think that if you report percentages at all, you should report them as a task-completion range with a confidence interval. I'd much rather say "Task A is between 68-76% complete, at a confidence interval of 80%" than just throw a single number out there without context.
I'd also take pains to differentiate task-completion percentages from schedule variance, unless you're extremely confident that tasks remaining is accurately tied to time remaining in your project plan. For example, "Task A is 75% complete, but it's estimated the task will require another 7-10 days to finish" is likely to be more useful from a planning perspective than how fractionally-done the task is. After all, unless you can extract value by shipping a feature that's only 75% complete, the feature probably has no value until it's 100% done.
Your mileage (and organizational requirements) may vary. Adjust your reporting methodology accordingly.
Agile Percentages: Done or Not-Done
Agile frameworks like Scrum take a different approach, where tasks are either "done" or "not done." This makes reporting percentages simpler in the sense that you are simply reporting which tasks are 100% complete as a percentage of total tasks for the project. Because of the iterative approach, the percentage of tasks completed is assessed separately from schedule estimates, management targets, and variance.
This avoids the common pitfall of saying things like "60% of our tasks are 80% done." Such statements are often semantically null; they typically don't provide accurate information on tasks remaining, budgeted man-hours remaining, or schedule variance. This can lead to faulty strategic planning based on incomplete information.
Organizations that don't make the distinctions between task completion and schedule variance often assume they are the same thing, and this increases the risk of project failure. Agile methodologies attempt to make this distinction, but the difference still must be clearly articulated and successfully communicated to be useful.