Project Management Analysis – Class Three

The third class focused more on the processes of project management and how strong process management can facilitate project success while process breakdown will undermine success. The environment for failure doesn’t come from the process itself, but rather, those involved in the process and their ability to execute it well.

Chose the right processes for the right tasks and endear those involved to embrace the process and it breeds success. The right process is the one that fits the needs of the project with the tendencies of how your team interacts and communicates.

A Work Breakdown Structure (WBS) helps you identify all the tasks (activities) required to build the specific deliverables. I don’t use these personally, but in more traditional structured systems these make sense for keeping team aligned. Within this there are a couple of rules to keep in mind when defining the tasks themselves:

The 8/80 Rule – no task should be smaller than 8 hours or larger than 80 hours.

The Reporting Rule – no task should be longer than the distance between two status reports.

All tasks are related to one another. three types of task relationships:

Finish-to-Start is the most common; Where one task finishes before another task starts.
Start-to-Start and Finish-to-Finish

Project schedules are made up of milestones which key in on important points withing the schedule:

task finish;
Mark input from one part to another;
Represent significant events not already represented in a work package.

The schedule is based on a series of task estimates. Creating accurate task estimates is vital to success. Incorrectly estimated tasks create false milestones and lead to waste or project failure.

In estimating task packages, there are a few common was of deriving an estimate

Expert Judgment is a method that is guided by using historical information the organization, the environment and prior similar projects.

Bottom-up Estimating is a method that is based on the estimates of work packages that are rolled up to the total costs. These estimates are usually provided by the people actually doing the work.

Analogous Estimating is a method using values or parameters from pervious similar projects.

Reserve Analysis (or padding) is a method for including a contingency reserve to allow for uncertainty in the overall project.

Any estimation process will take you through a series of steps to help you to continually refine your project budget and delivery dates. The levels (L0 – L3) will bring you close to calculating the actual cost (+/- 15%) and the implementation date (+/- 15 calendar days).

A project network diagram will help you do the following:

Define a projects path
Determine the sequence of tasks
Determine the dependencies
Highlight the critical path.

The critical path of a project are all the task with zero or negative float – the longest path (duration) through the project. These tasks cannot be shortened to decrease the duration of the overall project.

The float (or slack) refers to the fact that some tasks have flexibility in when they can be started or when they need to end in the overall project schedule.

Failure to understand both your CP and your Slack can create unnecessary problems within the team. No one enjoys sitting around due to poorly timed tasks as a result of underestimating slack and no one likes the excessive pressure of unexpected deadlines because zero-slack tasks weren’t fully identified.

Personally, creating network diagrams by hand is so old-school it’s almost painful. It reminds me of calculating statistics by hand even though I have excel there to plug formulas into. Part of me feels like using a Gantt Chart or other resources that can be generated by programs like MS Project, Ace, Pivotal, Trac and other software is a more effective solution in identifying all of the components anyhow even if it might be perceived as lazy, you’ll potentially make less mistakes with the assistance if you are intelligent enough to double check the computers work.

Last note on CP and Slack is use common sense.

When creating documentation remember two things:

Rely on templates when possible – they’re usually well tested and can be easily customized
Documents are living things – don’t assume because it’s written down that’s the same as carved in stone

Finally, the old carpenter’s rule: Measure twice, cut once. When it doubt, double and triple check at the beging to ensure clarity – clarity of requirements, clarity in estimations, etc – because if you get it wrong there’s a huge cost, namely, it could mean your job!

go back and read PM Analysis from Class Two


About thedoormouse

I am I. That’s all that i am. my little mousehole in cyberspace of fiction, recipes, sacrasm, op-ed on music, sports, and other notations both grand and tiny:
This entry was posted in business commentary, Product Management. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s