Not too long ago, I attended a meeting in which the discussion turned to the proposed schedule and a question was asked as to how we could ensure that IT would stay on track and meet the major milestones. Per my view, the issue was not whether the staff would make every attempt to meet our goals - within the expected time line - but whether the schedule itself was simply realistic and possible for the team to complete all development tasks as expected.
It is difficult sometimes to make the point to senior management that the careful planning, estimating, reviewing requirements, and risk evaluating all contribute to the creation of a sound schedule that is reasonable and can be actually be achieved. Too often, management targets a date and promises delivery without significant review with key stakeholders - at which point, the project manager is left scrambling to find sufficient resources to complete the necessary tasks - sometimes with little or no increase in staff or funds.
Schedules involve so much more than inputting dates into a scheduling program. Project schedules need, at a minimum, a work breakdown structure, careful review of the scope and specifications, and input from each member of the team. But, trying to explain dependencies or risk mitigation is met with blank stares or bored postures, not to mention activity duration estimates and resource calendars seem irrelevant - that is until you need to explain to executives that a project may need to be delayed or released in phases due to resource constraints or conflicting priorities.
Introducing a schedule management process is necessary. However, it needn't be a major overhaul; to your existing procedures since it is really part of the overall project management process. Senior management generally understands that in order to make process improvements and improve basic methods of accomplishing tasks, change is needed and will be very beneficial, but they may tend to forget that those same changes may also impact them and their goals as much as any of the business units. IT is not the only responsibility area in the organization when undertaking a software project. The business owners must be able to work together with IT and be viewed as partners, not as the folks on the next floor who keep making new requests that take even longer to complete making us appear to not meet our dates and reach schedule milestones.
That brings me to the topic of project change management - but that is to be saved for another post.
