Showing posts with label Milestones. Show all posts
Showing posts with label Milestones. Show all posts

Tuesday, July 31, 2007

July 31, 2007 – Cultivating a healthy Project Schedule

About a month ago my wife and I went out and purchased some plants, dug up one of the flower beds and replanted it. All the weeds and crabgrass were pulled and all the dead or dying plants removed. We followed the directions and placed the plants the recommended distance apart. We even added topsoil! The results were favorable. The new flowers filled in nicely.

When I walked by it this morning I realized that I have neglected it. Weeds have started sneaking in among the plants and the crabgrass is back. Some of the grass is even taller than the plants. It reminded me of project schedules I have attempted to revive. Neglect resulted in over allocations, missed deadlines and busted budgets. They were all things that should have been taken care of when the weeds first appeared instead of ignoring them.

When I review a schedule there are 5 questions that help verify its health.

1. When was the last time it was updated?

Weekly works the best. The Actual hours expended by the resources should be entered at the task level and a new Estimate to Complete (ETC) given for each task. Ideally this information should come from your team through the time reporting tool but I’ve had to do it by hand from printed individual timesheets, too. Finding out that the most recent schedule is three weeks old flashes a red light immediately.

2. Does the Estimate at Completion equal the Baseline?

The Estimate at Completion (EAC) is the sum of the Actual hours expended plus the ETC. In MS Project it is Planned Work. By comparing the EAC to the Baseline values for each task you can tell if any effort is being put into realistic forecasting.

The temptation is to add Actual hours to the task and allow the tool to subtract it from the original estimate. For a common example assume I worked 15 hours on a 20 hour task. I have 5 hours to go, right? Probably not. I could be done with the task or I might need another 20 hours.

If an individual is reporting that she needs 20 additional hours for a task that ought to be complete, ask questions. Why is it taking longer than anticipated? Do you need assistance? Are you the right person for the task? Do you need more training? Has the scope changed? Get to the root cause of the problem and solve it.

3. Is the remaining effort appropriately distributed?

For this I flip to a resource allocation view and check to see if everyone has just enough work to fill their timesheet for at least the next month or so. This should take into account holidays, vacations, training and other out-of-office factors.

Then I make sure there aren’t any major hills or valleys beyond that. The effort should average across the weeks to their maximum allocation throughout the remainder of the project. Beyond a month it can alternate a little low or high and be adjusted as the tasks get closer. If there are several resources that are over allocated, you may need to add more people in order to meet your deadlines.

4. Are you hitting the milestones?

A schedule that shows a history of missed deadlines is in trouble. Check to see if the misses are getting further apart or staying constant. Usually a project will miss the first on by 1 week, the second by 2, the third by 4 and before long all hope is lost. If they are staying fairly constant there was probably just one deliverable that threw it off.

If predecessors are established that link tasks based on order of completion you can see the impact of missed dates on the remainder of the effort. This is valuable information because you can see where to take corrective actions to bring things back into line.

5. Is the project projecting to be in budget?

With the updated ETC for the tasks and resources added to stay within schedule, odds are the budget has taken a hit. If it isn’t within reasonable tolerances you need to identify areas to reduce costs. Look for activities that can be combined. Consider juggling resources to different tasks. Perhaps a more senior resource can cut the development time in half, offsetting the per hour cost difference. Reassign lower cost resources to perform the testing. Moving work forward to fill in down time (ex. System documentation) may allow individuals to roll off to another project earlier. Get creative.

The answers to these five questions will help you find the weeds in your schedule and keep them from choking out a perfectly good project.

Monday, April 16, 2007

April 16, 2007 – Audit Failures

I have a friend who used to work for the Internal Revenue Service (IRS) as a tax collector for the United States. When this agent performed an audit he expected you to be honest and work with him to determine what was owed. He had the authority to make your life miserable if you chose to mess around. After trying unsuccessfully on one case to work through issues with an individual the agent showed up at the company before 6:00 AM with padlocks and chains to impound all of the vehicles. In concert with this move he froze all financial assets as soon as the banks opened.

On the flip side, he was working with a woman whose husband had run up bills, lied on his income tax and then left her. She met with him to work out some payment arrangement. After reviewing the case he determined that there was no way she would be able to repay what was owed so he wrote the whole thing off. She walked away free and clear.

When I was a project auditor I didn’t have that level of authority. The audits I performed were focused on making sure the projects and teams were following the procedures and that the company was not at risk. It was great to audit the managers who honestly worked with me to understand the project even when there were problems.

To keep from having and causing problems, review the following audit failures that should be avoided.

Lacking Definition. The most important part of a project is the definition. Without clearly defined objectives, deliverables and ground rules you won’t know where you are going, when you are done or how you will get there.

Make sure your defining documents clearly identify the project scope. Problems are usually found in this area just by speaking with the project manager. I review the Statement of Work and then start asking innocent questions like “what is your team currently working on?” When he starts talking about things that aren’t in the SOW I know there’s a problem.

Review your project’s defining documents and make sure you are doing what you said you would and nothing more.

Missed Milestones. Milestones are checkpoints. There isn’t anything magical about them. But if an audit discovers several of them have been missed then the project is at risk of failure to deliver. Don’t try to hide the fact that you are behind. Be the one to point it out. Then outline what you are doing to pull the project back on schedule. This may include bringing in additional resources, issuing change requests to adjust the dates or lowering the scope to meet the deadlines.

The audit reads a lot better if it shows you understand the issues and have a plan to correct the course. It sounds a lot better than “he hasn’t got a clue that the project is in jeopardy.”

Unacceptable Approvals. A good auditor looks deeper than file names to determine if an artifact is acceptable. There were multiple times that I looked at approval emails to discover they were worthless. There are 4 areas that approvals fail:
1. The person approving isn’t authorized. Check the names against the approval matrix or other guiding documents (i.e. SOX) for the right signoff levels.
2. The document doesn’t say what it approves. When issuing an email requesting deliverable approval make sure it spells out exactly what is being approved. Just saying “I approve the document we looked at yesterday” isn’t going to cut it.
3. Using voting buttons. At first it looks like a good idea: send an email and let them pick either Approve or Reject. The problem is the email content is lost on the return and all you get is the word “approve” or “reject.” It doesn’t say what they approved and it relies completely on the file name.
4. Doesn’t actually say “Approved.” I have seen questionable approvals that say “looks good” or “ok.” Not the best, but at least it indicates an affirmative response. The tough ones are the conditional approvals. If they say, “I approve this if Joe approves it” you better have Joe’s approval evidence, too. Or if it says, “I approve if you change these 3 things.” You will need to have it re-approved by everyone after those 3 things are modified.

Take a look at what you are presenting for your audit and don’t try to hide anything. The real reason for performing them is to identify areas that need improvement and then focus the necessary help on solving the problems. Besides, it can’t be as painful as a tax audit.