You, being a project manager, assign a task to a technical specialist. You don't understand exactly what he/she is doing, since you don't have his/her skills and education. How do you define a task completion criteria? In other words, how do you know when the task is really completed?
This is called Verification and Validation
Verification: The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610].
Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610]
Functionally this means:
From testing perspective:
Fault - wrong or missing function in the code.
Failure - the manifestation of a fault during execution.
Malfunction - according to its specification the system does not meet its specified functionality.
To actually know that the task is completed, then testing will need to be done on the product.
The way that I address this issue is the following. Usually I will have a lead in each specialty team.
Example: Developer Lead.
The lead for each specialty will be responsible and accountable to qualify that the task is completed in accordance to our initial criteria. They will run what Kieran made reference as verification and validation.
Now, you have to go a step further and confirm that the task actually meets customer expectation (aka. Requirements). This step you can accomplish in many ways, the most common on big projects, bring your business analyst together with the developer doing the task, every x amount of hours progressively to monitor requirement compliance. Another way, is to have the developer present to the PM in a quick standing meeting how his piece meets requirements.
For sure, you have to make sure that your task is linked to your SRS # and that your SRS # is tied to your BRD #.
I hope this helps.
When you develop the task with the team member, have this discussion. It's often true that the PM doesn't know enough about the actual work to assess the doneness of the task. If the requirements don't tell you then someone should be able to describe it in measurable terms. A Subject Matter Expert? The person doing the task - they will need to know more about the whole project to do that.
As a project manager, you have to understand better the tasks your team are doing.
For a short term solution, have a meeting with your technical specialist (and more member, if necessary) and ask them to about the task and how it will fit to the rest of the project.
Trace with them a way they can present the task after completion (e.g. a prototypic, a functionality added, even the software code). (Kudos for Kieran for the Validation and Verification tip)
The main goal must be something that can be measured or presented and make sure the requirements are being accomplished.
What seems crucial to me is that it needs to be clear what "finished" means in your particular context.
Especially in the field of software development, I sense a big tendency towards "been there, done that, finished (because the QA/PM/whoever will test afterwards anyways".
I think it is very important to clarify that "it is not done until it is done", meaning that 1st level testing is definitely part of what the assignee should accomplish already (even though that is what common sense might be telling you already, I experienced serious deviations from that).