Often there can be a disconnect between what management thinks will happen and what actually does happen in the development cycle due to many common scenarios. These include:
- management bringing forward the real deadline in order to build in a buffer for overrun;
- management not understanding the required effort to do certain things (a communication failure between technical and non-technical folks);
- engineers adopting the ask-for-clarification-when-I-get-to-that-part approach (this is often an unfortunate byproduct of agile development methodologies);
- a project stakeholder not being available for timely feedback when clarification of some component of the task is required by the engineering team
- engineers giving time estimates that do not include time for adequate testing, and/or are based on an incorrect appreciation of the scope of the work (another communication failure); and
- the ubiquitous scope creep.
If not dealt with correctly these factors can add considerable pressure to the engineers in the trenches doing the technical work and greatly inhibit your ability to deliver on time.
To maximize your chance of meeting the deadline:
- tell the engineers what the real deadline is (if known), and advise them of the desired deadline for "code-complete", with the subsequent time being used for review/testing/patching.
- ensure that the developer understands the task at hand. The days of writing detailed specifications are long gone, but there's no excuse to not provide a basic verbal briefing followed up by a bullet-point summary email or wiki page so the decision process is documented and the task scope is clear to all
- prioritize the sub-elements of the task, and have the engineer do them in priority order. If the deadline is hard then you have the option of dropping the non-essential components of the task. If the deadline is flexible you can decide whether it's best to push it back whilst the remaining features are done, or ship without them.
If this all sounds like Project Management 101 then that's good, but there are many cases where the basic survival principles are ignored by technical managers. And ignored at their peril !