Aligning The Schedule

Aligning The Schedule

Congratulations. The schedule is now complete, the resources are fully balanced, and you are ready to proceedexcept that the project will end in June and the client wants it in January. You are now faced with the job of aligning the schedule to the client's requirements.

Why is aligning the schedule a separate step? Why not simply take the client's requirements into account during the initial planning? The reason is that those requirements will influence your plans and will hinder your ability to develop a true picture of what the project really needs. When you prepare the schedule independently of what the client wants, the alterations you will have to make become visible. Then, when you chop estimates or alter dependencies or reassign resources, you are acutely aware of the effects.

If you have built an honest schedule, as opposed to one with a lot of fat built in because you knew you would have some aligning to do, you do not have much flexibility. Nevertheless, there are some things you can do.

Absolute vs. Desirable Dates

Some required dates are absolute. For example, if you are building an election system that must be ready by election day, you have no choice: The project must be finished when the client specifies.

On the other hand, some dates are merely desirable. If the client wants the system in January, "in time for the start of the fiscal year," the date is flexible: If the system is not available until March, it could simply mean that the client will have to enter two months' history.

There are two problems: determining whether a date is absolute or desirable, and, if it is merely desirable, convincing the client of this. The best approach is to ask yourself, "What would happen if this date is not met?" If the answer is something like, "We'd have to do a lot of work to catch up," then catching up is possible and the date is desirable rather than absolute. But if the answer is closer to, "We'd miss out on a major business opportunity and lose a $10 million investment,'' then the date is absolute and cannot slip.

Segment Into Releases

You may find that although the client's date is absolute, the entire project does not need to be finished at the same time. For example, although the on-line processing must be done by January, the client does not need management reporting from the database until March.

You need to plan how to present this approach to your client. If it appears that you are proposing to enter production with an incomplete system, be prepared for some strong objections; nobody wants to risk a company on something that is not finished. Instead, talk about release development, a process in which a system is developed and implemented in self-contained chunks. In the above examples, release 1 consists of the on-line processing and release 2 provides the management reporting facility. Release 1 is not unfinished; it is a complete release of a system to which subsequent releases will add further functionality.

You can use the concept of release development to align the schedule by defining release 1 to include whatever is required by the absolute date. Anything the client agrees can be deferred goes into release 2 (or release 3). If you can complete release 1 by the required date, you have successfully aligned the project to your client's requirements.

Reduce Functionality

If the date is absolute and you cannot segment the system into releases, it may be possible to compress the schedule by reducing functionality. This is another type of release development in which release 1 contains all the components of the complete system scaled down to a lower level of functionality. Subsequent releases will enhance the system to the functional levels that were originally planned.

This approach is different from the segmentation described above. Consider a project that is to deliver a system with components A, B, C, and D. Release segmentation might deliver A and B in release 1, with C and D in subsequent releases. Reduced functionality will deliver all four components in release 1, but each will be less comprehensive than was originally intended.

To reduce functionality, step through all the deliverables with the client and identify sections or pieces that are not absolutely necessary. It is vital that you enroll the client in this process. First, the client must understand why the system is being cut back. Second, only the client can identify functionality that can be deferred.

Additional Staff

Another approach to aligning the schedule is to assign additional staff. This depends upon the availability of other people as well as the nature of the project and the extent to which the activities are independent of one another.

Adding people is more realistic at the planning stage than after the project has started. At the planning stage, you can add time for increased communication and the distributed and overhead activities.

Subcontracting

One way to spread the work over more people is to subcontract part of the project to another company that specializes in systems development. This method is especially valid if your company is not one in which extra effort is the norm. The productivity of focused companies can be as much as 100 percent greater than that of their larger, more structured counterparts. In a tight project, they can sometimes provide the boost that the project needs. This approach can be expensive, but meeting the schedule may be worth it for the client.

Corporate Permission to Flout Regulations

Another approach is to get your company's permission to ignore office standards, conventions, paperwork, or any other corporate demands in a focused attempt to get the job done. If, for example, bringing the team physically together would help, but the company policy is for individuals to work at their assigned desks, request space dedicated to the project and bring the team together. If Fred is more productive working from 2:00 P.M. to midnight wearing jeans and a T-shirt with a beer logo, give him your blessing and block any attempt by the company's clothing police to intervene. If team members are active on the company's social committee, ask that they be excused for the duration.

This approach calls for a team commitment. You are saying to your team, "We've been asked to get this critical job done, and I will ax whatever gets in the way. If you will commit to this tight schedule, I will commit to insulate you from whatever company policies or standards slow you down."

Warning: If you do not get full team commitment and complete company cooperation, this approach will not work, and you should abandon the attempt. Otherwise you will be fighting two continual battles: one with your management (who did not think you meant that), and one with your team (who thought you did).

If All Else Fails

If you cannot change the date, defer functionality, cut components, assign more people, subcontract, or ignore company procedures, then, assuming your schedule is accurate, the job cannot be done.

One of your responsibilities as project manager is to ensure that project goals are achievable. If you are convinced that you cannot meet the schedule, you have just two choices: Decline the project or accept it. If you decline the project, make sure your management understand that your reasons are for their good. It is a disservice to mislead them into believing you can meet the schedule when you know you cannot.

If you decide to accept the project, make sure that your management understand the magnitude of the task and the likelihood of failure. Above all, make sure that you understandand are willing to acceptwhat will happen if you fail. Then tackle the job with all the creativity, talent, energy, and commitment you can muster.