Always, always investigate what happened. Find out
what prevented employee from achieving said dateline. More often than not, it is actually the process, the way things are done/managed, that prevents workers from accompishment. Immediately concluding as an "employee problem" is a typical response of management - it's
never their fault. To which I say, "yea right...."
Some questions:
1. What was the project/tasks that need to be done anyway?
2. How do I (we) know if 4 weeks was even reasonable for the project/task?
3. It is enough for a single person to handle?
Some advice (off the head; by no means comprehensive):
1. Why monitor employee only after 4 weeks? Why can't progress be tracked weekly, or even daily?
2. Break down the tasks of the project to achievable milestones. So if the first milestone is not even achievable, you know completing the entire project is then wishful thinking.
3. Maintain
Healthy Code - what Adam Cogan defined last night as "code that can be compiled and released for use
immediately", meaning you always have a build that is releasable (meaning stable and useable) even if not complete.
4. Risk Management - active identify and
act to elements of danger that has serious potential in contributing to project failure. This list must be updated regularly, and made known to all (including customer).
The main problem I see is
Progress Visibility - regular updates to show everyone just how much has been accomplished since the last showcase. Don't wait until its "submission time" to give it the one and only presentation; that usually ends up in immensely negative outcomes. Steven McConnell's
Rapid Development has a section that covers this topic, and the ethos of
eXtreme Programming serve to improve visibility of the progress of the project so everybody is in the loop and have the ability to feedback whether they are headed in the right direction.