Section 9.10. Solutions Fast Track

9.10. Solutions Fast Track

9.10.1.

9.10.1.1. Creating a Work Breakdown Structure

The Work Breakdown Structure is created using the project's major deliverables or objectives.

Project quality must be built into the project and you can implement quality control through the WBS.

Duration is the amount of time you'll allow for a task, while effort is the amount of actual work or time the task will take.

Project tasks should follow the 8/80 rule. Any task or work package that is less than 8 hours in duration should be rolled up into a higher level task that will be more than 8 hours in duration. Any task or work package that is longer than 80 hours should be broken down into smaller, more manageable tasks.

The tasks defined in the WBS define the total work of the project; therefore, the WBS defines the project scope. This is an opportunity to compare your WBS to your project scope statement(s) to ensure they are describing the same work.

Completion criteria describe what a completed task looks like or is comprised of. This is one way quality is managed in a project.

Entry/exit criteria can be used to define when tasks or phases can begin and end. This is another quality control method.

Tasks should be placed in optimal sequence at this point. Resource constraints and other limitations should not be introduced at this time.

Numbering tasks using a numbered outline format (1, 1.1, 1.2, 1.2.1, etc.) can be helpful in tracking tasks.

Review functional and technical requirements to make sure they are addressed by your WBS.

9.10.1.2. Creating a Network Diagram

The network diagram is a visual depiction of the sequenced tasks in the project.

Duration is the amount of time the task is allotted for completion. Float is the amount of flexibility in the timeframe for completion of the task. These can be used together to help sequence and schedule tasks.

The network diagram will help you see the project's critical path. Identifying tasks on the critical path will help you make better decisions about various project constraints.

9.10.1.3. Creating the Project Schedule

The project schedule is developed only after you've created an optimal sequence.

The project schedule takes into account resource conflict, limitations, and constraints.

Project management software is very helpful in creating and managing the project schedule.

Schedule based on task duration, not effort.

Identify needed resources for each task, then resolve sequence/schedule conflicts based on resources constraints.

The reserve is like a savings account. If a task takes longer than planned, the extra time is subtracted from the reserve. If a task takes less time than planned, the amount of unused time is added to the reserve.

Add reserve amounts to high-level tasks, not to each individual task. The reserve amount (days or percentages) should be clearly spelled out, not embedded in other time estimates.

9.10.1.4. Creating the Project Budget

The project budget is developed by adding the cost of each task. The cost of each task can be developed using historical data or through calculation.

A cash flow estimate helps show when large project expenditures will be needed so you, the team, and the company can plan accordingly.

Cost control measures are important in any project to prevent costs from spiraling out of control. The larger, more complex, or more expensive a project is, the more important these controls become.

If cost is your least flexible project parameter, cost controls should be very detailed to afford you the ability to closely manage project costs.

Reserves for the budget are developed just as they are for time reserves in the schedule. Additional amounts (dollar amounts or percentages) can be added to high-level tasks. The reserve amounts should always be clearly spelled out, not embedded in other costs.

9.10.1.5. Identifying Project Risks

Every project has risks unique to that project. Spend time as a team to identify these risks. Pay particular attention to risks that affect tasks on the critical path.

Risks should be sorted based on both the likelihood of occurrence and the impact to the project.

Decide as a team how far down your risk list you should plan.

For each risk chosen, investigate ways to reduce or avoid the risk by changing the project plan or the risk element. Typically, the best option is to try to avoid the risk in the first place. The second best option is to have a contingency plan ready to go should the risk occur.

For each risk, develop an alternate plan that you will implement if the risk occurs.

For each alternate plan, develop a trigger so you will know exactly when the risk has occurred and exactly how (and when) you'll put your alternate plan into action.

Review each alternative plan for potential new risks and plan accordingly.

9.10.1.6. Planning Project Communications

IT project communications are vital to the perceived and actual success of the project.

Ensure that you and your team have a solid communications plan and make adjustments as necessary based on the detailed project planning you've done.

If you and your team are not good at communicating, look for resources within your company that can assist you.

Communicate regularly about the project, even if you don't have definitive information.

Communicate with the appropriate frequency and method for the audience.

Assign an owner to communication tasks so you can be sure they get done.

9.10.1.7. Finalizing the Project Plan

The final project plan contains all the elements we've discussed to this point in the book.

The final project plan should be brought to the project sponsor for approval.

If the project sponsor requests or requires significant change, discuss this in depth to ensure the sponsor understands the implications of change at this point.

Sometimes projects reach this stage and are delayed, put on indefinite hold, or cancelled altogether. While this is disappointing, it is better to cancel a project in the planning stage than in the work stage.

Keep a separate copy of the final project plan for your archives. You can use it later to compare plan to actual results. This will help you improve your IT project management skills.

An archived copy of the final project plan may be useful for later use. Reusing project processes, procedures, or part of the Work Breakdown Structure can help you avoid "reinventing" the wheel.