Poject Management In Dimensions

In the heat of a project, all three factors-time, task, and resources-are ever changing, constantly interacting variables. The job of the project manager is to constantly balance these three factors. Suppose management transfers a key team member to another project, restricts access to equipment, or cuts the budget. As a result, the project either takes longer to complete becomes less ambitious in scope, or both. Likewise, if the design is scaled back project can be finished faster or with fewer people. The main goal of project management is to constantly balance these factors in flux.
By manipulating these factors, you can exert considerable control over the project. Your command of their interplay will help you:
*Explain schedule delays.
*Say ‘no’ to design changes and ‘feature creep’ with good reasons.
*Justify increased personnel and equipment requests.
*Recognize opportunities to improve project dynamics.
Only by examining these factors on an ongoing basis can you identify trouble spots and proactively address growing problems. Once a crisis hits, your analysis will help you learn from your mistakes, but you will fall short of saving the project at hand. Prevention always works better. Project management software can help you monitor progress. When you watch these factors on a daily basis, you can make minor adjustments along the way and avoid crises before they develop.
For example, our project developing an e-commerce website for an association publisher was slow getting started because of a resource problem. The plan for the site required a full feature set, including an online catalog of books and promotional items with cross-referencing ability, user surveys, a guest book, customer reviews, and multiple searching options. The project was adequately funded and scheduled accordingly. As development began, however, it became apparent that not enough people were working in content development. This limiting factor set a slower top speed for product development, lengthening the schedule requirements in other project areas. Next, the effect of the lengthened schedule lowered the project’s priority in the eyes of the external programming team, compounding the scheduling problem as the work took a backseat to more active projects. As development drifted on at this slow pace, the site was at risk of stalling entirely. With little to show in the way of progress and the deadline approaching, the project managers feared that their funding might be withdrawn. Saving the project called for drastic measures.
First, the project manager trimmed the task by narrowing the feature set to the minimum necessary. Next, a new content lead came to the project and staff was brought over from other projects to quickly populate the backend database with content. The project manager rescheduled the due date with the external programming staff and sought their commitment, with assurances that the project was on track and would move quickly. The abridged first version was ready to go live in a few months. In terms of the three factors, a shortage in the anticipated resources was addressed by lengthening the time factor and decreasing the task.
A natural reaction in such a situation, however, is to make up for lost time by pressuring programmers, while avoiding any adjustment to the project. Although this approach may improve appearances in the short term, it is usually not effective in the long haul. You may inspire spurts of super-productivity, but this pace is difficult to sustain. Work patterns gravitate toward their equilibrium. If you must apply pressure to change programmers’ behavior, then you may have to keep the heat on for the remainder of the project. As the programmers become desensitized to such pressure over time, you will need to become increasingly firm.