What is complete?

In real life software development, a project task's completeness is often determined more by the due date then by the completeness of the task. We are often lured into a comfortable sleep at night with a base understanding of what complete means and we assume we all share the same assumptions - well IT'S TIME TO WAKE UP! In a project plan we happily enter tasks that are required to complete a project and assume that once all tasks are complete, with the occasional newly discovered one, that the project is complete. What does complete really mean? And how do we track it in a project plan? Complete is defined in Webster's dictionary as 1 a : having all necessary parts, elements, or steps - all? all? here we can enter into a fuzzy logic discussion that will never end. The weakness in MS Project and most PM applications is that it does not provide, at a task level, what complete means. A tasks is typically defined by start/end dates, name, ID, description, person/group assigned and work/duration. BUT what defines when the task is complete? or complete enough? or over completed? Hopefully we're all beyond tracking percentage complete (gee, I'm 99% complete - that only took a day, so within another 5 minutes I'll be 100% - yea, right) - but is there anyone tracking the exact meaning of completeness at a task level? For example: a task could be the delivery of a simple report, is complete the delivery of the report? the delivery of the report and test plans showing it works? the delivery, test plans and acceptance by the PM or User? Shouldn't we be defining this in the task somewhere? Let's not get carried away about having to be COMPLETE - let's think about the benefit of delivering something complete enough. Let's take a requirement document. There is not such thing as a complete requirement document, not even at NASA. There's always some question, some white-space, some un-noted item - the question is, at what point is the value of the document sufficient and any additional work applied to it move it in the direction of diminishing returns?

I think the short answer is that a tasks completeness needs to be defined and noted, in the project plan with the task, and the level of completeness determining the end of the task needs to be defined by a combination of the PM, the end user, the sponsor and the person/group performing the work. The defining of the task completeness needs to occur prior to the task starting to remove any pressure to either reduce the work effort to complete on the predefined date or extend because the assigned person is 'nervous' about the quality of delivery.