January 24, 2010 – Driving me Crazy!

Having a GPS in the car drives me crazy. I do not operate well with directions that come one step at a time. It may be the Project Manager in me, but I want to see the big picture and know where I’m heading. Besides, at 65 miles an hour, I can’t judge “300 yards before taking the next left.” I’m not even sure if “Miss Voice” means her left or mine.

I realized this last week as I was traveling to a client site with our main sales person. She was driving and I was trying to navigate. We were attempting to go from Orange County, CA near Disney to the Pasadena area, home of the Rose Bowl Parade. The final destination was between the 60 and Interstate 10. I know how I would go and assumed the GPS would use the same route, straight up the 605.

Imagine my confusion when Miss Voice said, “In ½ mile, take exit to Interstate 5 North.” Before I could wrestle the screen to show the projected route, we had swerved onto the exit ramp to follow the directions. It was either that or face the dreaded “Recalculating…Recalculating” reprimand….or worse, the “Make a legal U-Turn” snide remark.

Through a comedy of errors, we managed to get back on track. We missed the 60, but found Interstate 10. Following Miss Voice’s advice, we passed the exit bearing the name of the street the client was on and took the next exit. I had a general sense of where we were heading by then and expected to head south and then east. Miss Voice, however, took us north and then west until we realized the ending address had changed.

I personally think Miss Voice was so disgusted with us that she was thinking, “Fine! If you don’t appreciate me, I’ll drive you to a back alley where you’ll get car jacked. They’ll strip this vehicle down and sell me to someone that can follow directions!”

Some project managers run their projects using a GPS. They punch a predefined address into their Charter and start driving. They fail to look far enough ahead to get into the right lane before missing the turn. Ultimately they allow the project direction to be altered without their knowledge, ending up somewhere else entirely. Even if they avoid a devastating collision, the sponsor usually ends up with car sickness.

Here are the top 10 ways to reach your destination without throwing your GPS out the window.

10. Lay out the full map. Understand where you are headed. You don’t need to know the turn by turn details, but you want to be able to sense when you are going in the wrong direction.

9. Verify your destination. Review the scope and requirements with your stakeholders and obtain their approval.

8. Keep an eye on the gas gauge. Budget, time and resources have to be planned and used appropriately.

7. Listen to Miss Voice. If you have laid out your plan and schedule accurately, follow them.

6. Track your progress. A GPS uses your current speed and position to calculate arrival time. Analyze your progress and spend rate to make sure you are on schedule and budget.

5. Look for landmarks. Set milestones in your schedule. Use them to validate your direction with stakeholders and gauge your timing.

4. Check the map frequently. Verify progress against the scope and requirements in order to stay on course.

3. Recalculate. As the project progresses, more information is available. It may be refined requirements, new technology, resource changes or other factors that impact the end product. Use formal change processes to re-evaluate and alter the direction and cost.

2. Check the traffic. Analyze the risks in your project. If it appears there is traffic ahead, take action to avoid it.

1. You have arrived at your destination. Recognize when you have completed the project’s scope. Don’t allow random course changes to be slammed in at the end of the project. These tend to be less structured, lack adequate testing and overrun the budget.

We arrived in one piece, but it is a good thing we left early.

February 1, 2009 – Going Covert, Part 4

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 16, Friday – Wow! It’s Friday already. Payday is always nice. Technically it is already spent, but it is nice to have it pass through my bank account. It makes me feel like I’m doing my part to stimulate the economy.

The follow up schedule review meeting with the team went well. I wouldn’t have guessed thinking in terms of hours would be such a culture shock to them. Given the hours they estimated and their availability on my project I was able to project a realistic timeframe for delivery: 112 days. That’s a bit longer than the 83 days originally planned and certainly not happy news for Management on Monday.

I ran a couple of different scenarios, checking the critical path, and came up with some options to present to Management. It isn’t rocket science. We can (1) extend the date; (2) decrease the amount of work; (3) increase the number of resources or some combination of the three.

We’ve already been told the data is fixed. When the CEO sets a date, it stays set.

Since we haven’t finalized the requirements we may be able to adjust the scope of the project.

Adding new resources would slow us down on an already crunched schedule. Our best bet is to get more time from the resources assigned to the project.

Day 19, Monday – Meeting with Management went almost as expected. Why is it that something that seems obvious to me is a mystery to Management? Calculating the length of a project is simple mathematics. If the number hours your resources have doesn’t equal the number of hours left to complete the project, the date is going to slip.

Fortunately, after the “I’m so disappointed in you and your PMP certification” speech and then getting grilled with questions, management opted to pull my resources off their other projects. If, in fact, they are allowed to, it will effectively cut our duration by a third and place us in range to meet the deadline.

The surprise additional action they took was to add a Finance report for invoicing purposes. They need to know the total number of records sent to the Clear Mind Counseling Center. Not a big report, but I’ll put a Change Request in within the next couple of days after we estimate the effort.

The other PMs picked Tuesdays to informally get together and talk through our projects and problems. Our first meeting is tomorrow

Day 20, Tuesday – Finished off the estimate on the finance report and sent it out for approval. I wrote it up and attached it to an email, asking them to respond with an “Approved” or send it back with the reasons why not. I receive two phone calls asking what I meant: one from the Business Project Manager and one from the sponsor. Evidently the business doesn’t normally get involved at this level.

It was a great conversation starter, though. I suspect I’ve opened Pandora’s Box. After I explained that a Change Request outlines what is requested and how it impacts the cost and schedule, her interest level was raised. The business is likely to start asking for more involvement going forward.

The phone call from Management started with, “What are you thinking?!?!? We don’t send Change Requests to the Business!” I guess that was another one of those written procedures they got rid of without telling anyone in the PMO.

The PM meeting over lunch went better. Since they still think of me as belonging to the PMO, I was expected to head up the meeting. I started by recapping my first 20 days. My whining consisted of:

• No documentation on management of project including the Project Schedule and Charter.
• The fact that the deadline was set before anyone really estimated the effort.
• Requirements were incomplete.
• Lack of resources and those that I had were over allocated.
• Management status meetings more like firing squad.
• Unrealistic expectations set and held by management.
• No opportunity to re-estimate based on more knowledge of the project.

They agreed with my list and added:

• Project managers running too many projects (one guy had 7!).
• Developers adding “little” items to the project that are found in Testing as defects because they don’t match the requirements or design.
• Business not offering any input until User Acceptance and then they want to change everything.
• No agreement on requirements.
• Failing Sarbanes Oxley (SOX) related Internal Audit checks and having to rework things.
• Information Security (InfoSec) reviewing the product and demanding changes at the end of the project.

In a way it felt good to collectively get it off our chests but it left us feeling empty. Not quite hopeless, but certainly depressed. We decided to think through what we did on our own projects to address these issue and get together next week to start sharing them.

When I got back to my desk I received another curve ball. The Business Project Manager sent me an email saying there was another company they were starting to work with that offered different services. She wanted to know if we could send the same feed to another company.

Our schedule is so dead.

Jump to Part 5.

January 19, 2009 – Going Covert, Part 3

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This series of entries is a fictional account based on the Project Manager in that article. Any resemblance to anyone from my past, present or future is purely coincidental. To start at the beginning, jump to January 1, 2009 – Going Covert, Part 1.

Day 14, Wednesday – Had lunch today with a couple of other Project Managers, Bill and Darryl. I told them what I was struggling with: Management expectations, resource over allocations and a project without definition. If it was sympathy I was looking for, I was going to have to look elsewhere. No surprise there. They were guys and both had complained about the same things during project reviews I had conducted.

They stopped short of laughing in my face but their little smirks were infuriating.

While washing down our $1.50 hotdog from Costco with Diet Cokes, we came to the conclusion that the processes themselves were not the issue. The biggest roadblocks were:

• Too many projects for a PM to manage
• Resources spread too thin
• Projects held to preliminary budget and dates
• Processes not communicated to the teams
• No management buy in to the process resulting in directives at odds with standards and processes

Bill mentioned that some of the other PMs had voiced similar frustrations. We decided to pick up the conversation with them.

I stole an hour in the afternoon to do a little research. My access to the PMO data hadn’t been cut yet. For the most part, PMs each had 2 or 3 projects, but some of them were running more than 5. My rule of thumb says the project management pieces alone take a minimum of 6 to 8 hours a week:
1.5 hr status meetings (15 minute / day or 1 per week) plus minutes
1.0 hr reviewing and updating schedule
1.5 hr updating the project repository and/or creating the project status report
1.0 hr risk / issue management
1.5 hr business status meetings and minutes

With 3 projects half the week is spent you’ve only covered the basics. Any requirements management, technical reviews, conflict resolution, additional reporting or stakeholder management is in addition.

In a prior life I had 3 concurrent projects. Management wanted to give me a fourth. When I presented the math to them they gave it to someone else. I like to think their respect for me went up, but I suspect their tolerance of me dropped instead.

Day 15, Thursday – Met with the team to review the schedule. I kept it somewhat high level, mostly activities and asked them to think in terms of hours, not days. It appears to be a bit of a shift in their normal thinking. I want to calculate the duration based on their availability given the number of projects they are working. They offered minor change, mostly in dependencies and half hearted commitments.
I scheduled a follow up for tomorrow and will nail it down. The rest of the day was spent estimating availability from the status gleaned in our Stand Up meetings.

Jump to Part 4.

September 15, 2008 – Back to the Basic: Competing Project Constraints

Following last week’s edition, one of my project management co-conspirators dropped me a note informing me that the triple constraint (see The Troubling Triangle) is officially dead. The upcoming release of the PMBOK Guide 4th edition has killed it.

In lieu of the binding, restricting, tri-legged barer of logic, PMI has opted for “Competing Project Constraints.” The new PMBOK includes Scope, Quality, Schedule, Budget, Resources and Risk as a representative list of the numerous constraints that a Project Manager faces.

Without reading the text directly I can not make a fully informed decision about the wisdom of creating a multisided polygon constraint. For one thing it doesn’t have quite the same ring as a triangle (I’m sure there’s a bad musical percussion joke in there somewhere). However, here are my initial thoughts.

1. I whole heartedly agree that Project Managers have more to worry about than Scope, Schedule and Budget. I don’t think there was ever any real misunderstanding of that fact.
2. By removing the Triple Constraint and accompanying triangular image, we loose the visual used to explain the impact of changing one of the legs.
3. Of the examples given as other constraints, Quality is easily represented by the size of the area encompassed by the leg segments of the triangle. Although not originally part of the image, it fits.
4. Another, Resources is generally a factor of the cost (or budget) of the project. If money is no object you can get better and more resources. The New York Yankees and Real Madrid sports franchises, with their ability to buy talent, come to mind. Generally speaking, projects run out of time or money before they experience a lack in available resources.
5. For the other, Risks, I need more explanation for the use of the term “constraint.” If the term means “factors that may adversely impact your project” then I would agree.

Perhaps that is the basis of the change in the terms used. PMI may believe that it is doing us a favor by widening the term to show the myriad of chainsaws and knives we need to keep juggling. My fear is that it opens the door for management to defy the simple logic that if they increase scope, schedule or budget, one or both of the other legs have to adjust.

If we are expanding the number of constraints, maybe we just need a different image:
Picket Fence – Each of the slats represents a constraint holding the project level.
Suspension Bridge – All of the cables adjusted to keep the path safe for passage.
Multi-legged Table – Legs adjusting together to support the project.

Whatever the symbol, I will miss the triangle.

September 8, 2008 – Back to the Basic: The Troubling Triangle

In our quest to return to the basic of project management we have already tackled the stakeholders. Next we take on the triple constraint in the form of a triangle. The concept of a triangle to represent the Scope, Schedule and Cost of a project is actually quite ingenious. Adding more scope dictates an increase in the schedule, cost or both. Reducing the cost or timeline for the project requires less scope. Each part is dependent on the other two.

The trouble is that management thinks of these three items as completely independent of each other; like 3 line segments lying as distinctly separated as the bones in my daughter’s x-ray from last week’s edition.

Scope. The scope of your project includes the full extent of what is agreed to, both verbally and in writing. In reality scope is never fully defined until all of the requirements are vetted, but from the minute you take ownership it is our responsibility is to ferret out promises and commitments made. This is especially evident in the consulting world. Account Representatives (aka Salesmen) are notorious for making promises and not letting the project manager in on the secret. Take your list of Stakeholders and find out their expectations.

The resulting wish list is not your scope. Like pruning a Bonsai tree you need to cut that back to something you can realistically deliver in the timeframe and cost provided. Remember, you can’t set one line segment of your triangle without impacting the other two.

Cost. Auto salesmen get a bad rep, justifiably so in many cases. But you can take a page out of their play book. When asked how much it will cost to deliver the scope, ask how much they are looking to spend. If they only have enough for a used, beat up Yugo, don’t try to sell them a Lamborghini.

When giving an estimate, put it in terms of what will be delivered. Never give a quote without documenting your assumptions; the “here’s what I was thinking…” piece. Placing the cost into context forces the discussion of scope.

Schedule. Timing is always an issue. On one project our directive was to go live in August. Backing up from that date gave us July for Testing and Implementation, June for Development, May for Design and April for Requirements. It would be tight, but do-able. At the end of May “in production” was clarified to mean the day after 4 weeks of parallel testing in the production environment. Changing the move to production, even if we weren’t “live” would have been impossible without changing the scope and adding more resources (increasing the cost).

Find out what the date is and the significance of it. If it is a hard date you have already set one of the legs in the triangle.

As you establish the three legs of your triangle, it is management’s job to stretch the scope side while reducing the length of the cost and schedule sides. How can you effectively push back without a career shortening screaming match?

Go gourmet on them. Most CIOs, VPs and Senior Managers enjoy their share of fine food. The higher end restaurants produce amazing dinners that take longer to serve and cost quite a bit more than your local fast food joint. Even our cafeteria at work has a sign that says, “Good food takes time. Thank you for your patience.”

Build a reputation on speaking straight and not padding estimates. It is your responsibility to present the facts, back them up with evidence and state your case clearly. It is their job to make decisions.

June 9, 2008 – Project Success…at What Cost?

Great things can be accomplished if Scope, Budget and Duration are no object. Here are some historical examples:

Hoover Dam
Scope: Stop a river and produce 2080 megawatts of power.
Budget: $49M US cost (under budget)
Duration: < 5 years (2 years ahead of schedule)
Added Expense: 112 Deaths

Egyptian Pyramid
Scope: Started as a grave. Scope creep resulted in one of the Seven Wonders of the Ancient World with quite a bit of gold plating, literally.
Budget: Spare not Cost
Duration: 27 years each
Added Expense: Slave Labor

Great Wall of China
Scope: Stop the Xiongnu attacks with a really big wall (6400km / 4000miles long)
Budget: Unknown
Duration: Several Centuries
Added Expense: 2 to 3 million Chinese lives

Each of these was an amazing project and each came with a high price tag in human lives.

Unfortunately there are a fair number of companies that force their teams to nearly kill themselves for unrealistic timelines. A friend of mine told me of the unhealthy environment they had recently left. The pressure there was tremendous. Deadlines were strictly enforced, resulting in projects that came in on time. How? People were required to work as much as 80 hours a week and be on call when they weren’t physically there. This resulted in people quitting, massive amounts of sick time request, spouses threatening divorce and people being hauled off in ambulances.

What made this story ironic was the fact that the company was in the health care industry.

How can you avoid killing your team?

Involve them in the estimating process. It seems obvious, but the people that do a deed generally know what it takes to get it done. Your job is to question the numbers. First, make sure there are enough hours. Are their estimates only for development? Did they include requirements, design and testing? Next, get a second opinion. One method for this is Planning Poker (see entry on Agile Estimating Methods). Finally, work to eliminate padding. Create a contingency pool to apply where needed but estimate the pieces realistically.

Limit overtime. Your initial pass at the schedule should not include overtime. Then, if overtime can’t be avoided, set boundaries on the timeframe. People can survive a lot if there is an end in sight. Strive to keep the overtime sprints to 6 weeks in duration. Show the team the time line and ask for their commitment.

Compensate them. Even “exempt” employees (salaried / non-time and materials) can’t be expected to work tirelessly without receiving something. The promise of several days off following a sprint can keep the team pushing forward. This isn’t expected to be an hour per hour trade for the time they put in. After all, salaried employees are expected to put a bit more into their jobs when necessary.

Set realistic expectations. As the project manager it is your responsibility to set the expectations of upper management.

Schedule team outings. Get your team out of the office once in a while. Lunch can be a simple solution. On the flip side, a friend of mine is attempting to set up a cricket match here in the states.

Give family friendly rewards. Stressful environments wreak havoc on families. Token rewards such as movie tickets or gift cards can help ease some of that pressure. Acknowledgement of that fact can go a long way. Consider presenting awards directly to spouses to show you understand the strain they are under.

Watch for warning signs. Keep on eye out for people that are putting in too many hours. Encourage them to throttle down a little, especially if they are wearing the same cloths they had on yesterday.

Very few projects are worth killing your team over. Besides, the paperwork involved in having an ambulance on site is a real pain.

December 3, 2007 – Lacking Commitment

They stripped a month off my project. Okay, technically I misunderstood them when they said go-live was September. What they meant was there would be a month long parallel run in production before they turned off the old system in September. Either way there were four less weeks of development time.

After sketching out the timeline, System Testing was scheduled for July 18. The four weeks to that date didn’t look long enough to me for the interface team. I wanted desperately to return to the steering committee with evidence to support my suspicions, but when asked, the team assured me it would be ready. Every status meeting I checked. Between meetings I followed up. Always the same answer: “We are on schedule.”

On July 17 we had the pre-System Testing meeting to tie up loose ends, the interfaces being one of them. The technical lead smiled and said with confidence, “We finally did it. The design is complete.” Yes, he said DESIGN! During the somewhat heated discussion that followed it became clear that they were no where near ready to test. The code didn’t even exist. They had said the words but had never committed.

Obtaining Commitment. Before anyone can (or should) commit to anything they need to know what they are in for. Walk through the expectations with the team that will do the work. Ask them for their estimates, timelines and constraints. Deadlines I impose can be dismissed as unrealistic but if the team develops the dates they own the estimate and associated commitments.

Scheduling Commitments. Before finalizing and announcing any dates, put a schedule together to lay out the commitments. Ideally you would use Primavera, MS Project or other tool to detail phases, deliverables, activities and tasks with planned hours and baseline dates. Even without those you can still put a meaningful schedule together. At a minimum, break the effort into pieces (ex. Interfaces A, B and C) and sketch out the tasks to complete them. Lay out the timeline based on the commitment and assign resources to the tasks.

Tracking Commitments. If your team has matured to the point of using actual hours and estimates to complete to rework the plan on a weekly basis, consider yourself fortunately. Many companies aren’t there yet. For everyone else, you can work it using the due dates and percent complete. Each week have the team report on which tasks are completed and the percent complete of started ones. Also have them review the task end dates and confirm they are still realistic. If a task slips, check the ripple effect and have them determine how to get back on track. Projects usually fail at the task level. Keep them in line and you stand a chance of completing on time.

Breaking Commitments. Sometimes commitments can’t be kept. Your team has to know they can tell you when they can’t meet a date. For whatever reason, my interface team waited until it was too late. By communicating the progress along the way adjustments can be made. Scope can be altered. Resources can be added. Alternatives can be discussed. When communicating the disappointing news to your management, have your facts in place. Instead of just saying, “We can’t make it,” spell out:
· Cause of the problem.
· Plans to get back on schedule.
· Proposed new dates.
· Steps to keep the problem from happening again.
· Help needed from management.

To solve our problem we ended up bypassing the interface engines by generating test material until they were completed. With significant sweat and long weekends we were able to meet the aggressive September timeline with a shortened parallel run.

October 8, 2007 – MS Project Resource Baseline Fix

Creating a baseline for your project is the starting point for tracking your progress. It is your line in the sand against which you measure your success. It may show that the first deliverable is over budget/schedule compared to the baseline but the next one is under. Evaluating the variances and trends allows you to make adjustments throughout the life of the project.

The baseline should remain unaltered throughout the project unless a Change Request is approved to modify it. The temptation is to re-baseline the entire project. Unfortunately doing so overwrites the baseline for all the tasks, eliminating any variances and wiping out your ability to see the trends. Instead, only those tasks associated with the Change Request should be re-baselined.

Microsoft Project historically does not deal well with saving partial baselines. Evidently the idea of a Project Manager only needing to re-baseline certain tasks isn’t logical to them. When I asked Microsoft Support if they intended to fix the problem they referred to it as a “User Perceived Bug” and said it was coded to the specifications.

The Problem:
When a project is baselined, Microsoft moves the values in the Work and Cost (for both Tasks and Resources) to the Baseline Work and Cost fields. Re-baselining the entire project moves the values for all levels (Tasks, Activities, Phases, Resources, etc.) over. Saving the baseline for only selected tasks doesn’t.

MS Project 2002 introduced the option to “roll up baselines” to the summary tasks from the subtasks when baselining selected tasks. That was a huge improvement. They stopped short of doing the same for the Resource totals.

Let’s say that Bill has a total of 100 hours scheduled for two tasks: Write Specification (40 hours) and Create Prototype (60 hours). A Change Request is approved to double the time and those two tasks are re-baselined at 80 and 120 each. In the Resource Usage view, Bill’s baseline totals would still read 100 instead of 200.

The Solution:
Historically I have had to drop the details to Excel, use Subtotals to do the summation and paste it back into the project plan. Not a lot of fun. A friend of mine, Jon Smith (yes, that is his actual name), recently sent me a macro for Project that essentially does the same thing for the Work field without leaving MS Project. I tweaked it to add up the Cost field, too.

If you would like a copy of the macro, drop me an email at ThomasCutting@yahoo.com.

August 27, 2007 – Balancing Your Budget by Taking a Vacation

A word to the wise…do not go tent camping at Perris Lake, CA in August. You know you are in the wrong place when the locals say you are lucky the temperature dropped…to 102 degrees Fahrenheit (39 Celsius). As soon as the sun rises over the hills it immediately jumps to 85F (29C). As you can imagine, ground baked at those temperatures for extended periods of time tend to be hard. Not the best of sleeping conditions. There is a saying that goes “that which does not kill you makes you stronger.” In reality, it should probably say, “that which does not kill you makes you wish you were dead.” Fortunately this week we are headed to Palm Springs to stay at a resort with air conditioning and a big swimming pool.

It’s an odd segue but I was speaking with a Project Manager about taking vacation the other day. His small, four month project was running several thousand dollars over budget. I suggested that at his bill rate a couple of vacation days might bring the costs back into alignment. Here are a couple of other items that may help balance your budget.

Resource Rotation. Examine your resource allocations. Do you have senior people doing simple tasks or junior individuals struggling to perform in difficult areas? By moving less expensive resources to handle the simple things you can shave that added expense from the project. Conversely, where your junior team is struggling in deep waters, an expert may be able to blow through the issues in half the time, actually saving funds in the long term. Don’t get trapped in the mindset that cheaper is better. Each situation needs to be examined to determine the best option.

Of course this only works if you are tracking the true cost of your resources. I am surprised at how many companies do not distinguish between resources when counting the cost. Some only use the number of hours or a flat, blended rate to determine the cost. Using that method means your best players costs the same amount as your third string team. No one would consider fielding a professional sports team like that so why do we manage our teams that way?

Find Filler. Look to pull work from the future to fill in blank spots now. One project I managed involved testing multiple systems. Originally they were scheduled to be done sequentially but delays in the earlier ones were impacting the schedule. By pulling the analysis from future systems and performing it early we were able to fill in the gaps and keep the project from running long and over budget.

Consolidate Testing. Before I go any further, let me first say that I am not suggesting you cut corners for testing. What I am advocating is the consolidation of testing across multiple, interrelated projects and between common end users. Integrating the testing for projects that share resources (i.e. databases, common feeds, etc.) can save funds by using the same testing environments and testers. An added bonus is the assurance that the systems will function well together. Any problems caused by their interaction can be resolved prior to going to production.

Time Out for Training. Take advantage of projected down times to schedule training for your team. This is actually a multi-prong attack. First, the budget for training usually comes from outside of the project so the cost of those individuals can be offloaded during a time when their services aren’t vital. Second, if the training is specific to an upcoming aspect of the project your resources will be better equipped to perform, potentially increasing their productivity. Finally, investing in your team shows your commitment to them and will help keep them from seeking employment elsewhere.

Bottom line, if you need a vacation, tell your manager you are willing to take one for the team. Once he understands how it can help the budget he might just join you.

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.

April 30, 2007 – So What?

Anyone who has teenagers or has had to deal with them will inevitably run into one with a bad attitude. Even their body language says “SO WHAT?” As project managers we deal with a lot of issues, risks, problems and people. Some times it makes you want to throw your hands up and say, “So what?!?!” Actually, that might not be a bad idea. How would that look for issues, risks, budget or schedule problems and politics?

Issues. My natural inclination when someone raises an issue is to try and solve it. The next time you are confronted with one make sure to ask “so what?” So what is the impact to the project? Is it severe? Does it need to be address immediately? Is it something we can live with? Can it be addressed in future releases? Some times the impact is small enough that it isn’t worth the effort to address the issue.

Risks. Applying the “so what?” question to risks is easier since you aren’t feeling the immediate pain you do with an issue. Not all identified risks are dealt with the same way. In addition to Avoidance (sidestepping it), Mitigation (reducing the probability or impact) and Transference (making it someone else’s problem) there is the ultimate “so what” attitude: Acceptance. In Risk Acceptance you look at the probability of it becoming an issue and the impact to the project and decide it isn’t worth the effort to take action against it.

Budget or Schedule Problems. Budgets and schedules usually are scrutinized highly on projects, but sometime even they get trumped. There are times when a project has to get done. People may be willing to pay whatever it takes and wait longer to get it. I was managing on project where new requirements were requested toward the end of the testing phase. When we said it couldn’t be done the response was, “Would more money help?” Unfortunately money wasn’t the issue, time was.

Politics. I can’t stand politics. It is probably because my straight forward approach to life and management causes me to inadvertently step on toes I don’t see. The question can work here, too. I would suggest you let the voices inside your head ask the “so what?” question rather than blurting it out. So what if that person or group isn’t happy with the product? Does it meet the specs? Are they the ones paying for it? So what if they aren’t going to like the status I need to give? Is it better they hear it now before the project fails? So what…do I have to do now that I offended the boss?!

The answer to this question will help you gauge what your response should be. Sometimes you will luck out and be able to ignore the problem. Other times the answer will be to take action. Either way, you will be working from an informed position, not reacting blindly.

April 4, 2007 – It’s in the Game – Information Overload Part

One of the advertising campaigns for EA Sports is “It’s in the Game,” referring to the fact that the games are technically accurate as well as fun to play. Actual statistics are included to make their games as realistic as possible.

While I was managing a project for Electronic Arts I began playing more of their games. Depending on your perspective the level of detail included can either be great or a real pain. If your favorite football team was on the top of the heap when the stats were taken it is great. But what if, like me, you are a Buffalo Bills fan? Not so good, eh? If you are from the United States, FIFA World Cup can be extremely frustrating. No matter how you play the game you are unlikely to pull off a major victory based on statistics. Hard core players can change the stats and build a better team but maintaining that much detail can be overwhelming.

Managing a project can cause much the same information overload. The key is to identify the right balance between enough and too much. Let’s take a look at that balance for 3 areas: Project Schedules, Meeting Minutes and Messages.

Project Schedules. Project Schedules are notorious for either a complete lack of information or radical overload. When planning and tracking your projects there are a couple of things that can help make it manageable.

1. 4 – 80 rule. Ideally task effort should be between 4 and 80 hours per resource. Instead of having 1 hour to review a document, 1 hour to make changes, 1 hour to review it again, and 1 more to approve, combine the effort and create one task to “Review and Approve.”
   
   Task over 80 hours per person are difficult to truly estimate. If I’m asked to do something that it is more than 2 weeks of effort I need to break it down further to fully understand what is expected. An exception to this rule is fixed duration tasks like support where you know it is a certain amount of effort and no more. If 80 becomes too granular for tracking purposes, make sure to include a separate checklist of items that make up that task. This allows progress to be tracked and keeps the team from burning the entire budget without accomplishing anything.
   
2. Avoid recurring tasks. Don’t set up a task for each meeting. MS Project allows you to create a “Recurring Task” for things like status meetings. This actually creates multiple tasks that you will need to track against. Too much detail. Instead, create a single task for each meeting that spans the entire project. You may even be able to combine all meetings into one if it is clear who should be charging for which meetings.
   
3. Off load. When you manage multiple vendors or departments push some of the effort to the PM or Team Lead for those groups. Set expectations for the timelines, deliverables and level of reporting you are expecting but let them handle the details.

Next time we will continue with ideas on how to avoid information overload with Meeting Minutes and Messages.

March 26 – Budget Management Checkbook Style

This article was originally published at http://projectmanagementlearningcenter.com.

I have really messed up my checkbook. It started around Christmas time. When I tried to balance it in January I failed miserably. Since I can balance the budget for a multi-million dollar project I should be able to handle a checkbook that borders on empty every month. Even with a new Quicken file in February, I was still unsuccessful this weekend in determining what I have left. If I don’t get it right I won’t know how much I have available and will likely end up bouncing checks.

What surprises me is the number of project managers that don’t put the effort in to balance their project budget. Every time someone expends effort on your project it is like a check being posted against your account. If you don’t capture and track those transactions you will eat through your budget faster than high school kids through your refrigerator.

Here are 4 basic concepts of budget management to put into practice.

Know your budget. I started a multi-person, multi-email discussion recently about the budget on a project. I knew what the overall cost of the project was but it included a Fixed Price Premium (FPP). An FPP is added to the cost of the project by the consulting company to offset the risk involved with a fixed price project. Since it is basically an insurance policy, it is outside of the budget for the project. I had to find out what that amount was in order to develop the baseline for the cost.

Create your schedule to the budget. Assign resources to the tasks with costs per hour for those resources. If you are responsible for the hardware, software, facilities, etc., include them in your schedule. This gives you a projected cost for the effort. If, after realistically created the tasks and applied the resources, you are over budget there are a couple of steps you can take.
1. Review the strategy and see if there are any shortcuts that can be applied.
2. Use cheaper resources to accomplish the same tasks.
3. Revisit the scope to see if anything can be removed.
4. Ask for more money for your budget. It may be a little early in the project for this one, though.

If your totals show you under budget, recheck to make sure you didn’t forget anything and then place the remaining amount in your schedule as a contingent reserve (hidden fund for future unknown problems).

Track your expenses. Each week your resources’ timesheets deduct money from the project. If that time is not applied against your schedule it is like using your debit card and throwing the receipts away. Eventually your bank is going to send you nasty letters telling you there is no money left and, to prove their point, deducting $20 more from you.

Record time spent against the tasks worked. This is simpler if you have time tracking software like MS Project Server, Clarity or Primavera but it can be done manually. You can collect paper or electronic timesheets showing actual effort against a task list and enter it into the schedule.

As you do this you will see areas where you are expending more than was planned and take corrective actions.

Balance the books. The finance group should issue statements from time to time showing the charges to the project. Take the time to match invoices and timesheet totals back to your schedule. This is where you will find people that are charging to your project that you didn’t know about. It also helps you confirm your budget still exists.

A multi-millions dollar project I was managing had saved nearly $1.5 million by altering their hardware needs. This savings was part of the contingent reserve on my schedule. When I balanced back against the numbers from finance the budget was off by $1.5 million. It was discovered that the in final budget submitted the savings were removed and given to other projects. It was a shock to go from extremely under budget to barely on target, but it was better to find out midway through than when the checks started bouncing.

Tracking your budget is about as much fun as balancing your checkbook, but not doing either one will land you in trouble.

March 15, 2007 – Wowing Management

Register @ Cutting's Edge.

I heard an interesting quote the other day: “Desire without dedication is fantasy.” It was said in the context of maintaining a solid marriage, but it struck me that it was such a universal truth. If an athlete desires to be a professional but lacks the dedication to practice he is just dreaming. A farmer that wishes to have a good crop doesn’t lay around all spring thinking about it. It seems obvious in those contexts, yet it seems to fall apart in the world of management.

Many times management recognizes the need for establishing guidelines and following best practices but lacks the will to follow through with it. They get a glimpse of what consistent processes can do for them but can’t or won’t enforce them long enough to see the benefit. Granted, if it were easy everyone would do it.

I always enjoy starting in an environment where there is a lack of project management processes. It is fun to wow people with the simple things when they haven’t seen much real project management. Here are a few simple actions you can take as a professional project manager to impress your management.

Meeting Minutes. One of the simplest steps to project success is issuing minutes from meetings. It is also one of the things many project managers drop first. Minutes refresh attendee’s memories, inform those that weren’t there and give everyone a chance to confirm agreement with what happened. Good: Include a list of invitees and mark off those that show up. Better: Keep the minutes short. Give decisions, not discussions. Best: Publish them within 24 hours. Great: Use the minutes template as the agenda and send a draft version with the invitation.

Project Tracking. Use your project schedule don’t just look at it. Set it up with realistic estimates and time lines and keep it updated throughout the project. Good: Track the actual time expended (Actuals) and reforecast with the Estimates to Complete (ETCs). Better: Identify and manage the critical path. Best: Baseline to your budget and track and use Earned Value to manage the project.

Status Reporting. One of the basic communication elements, the status report is a clear, concise summary of what happened in the last week. Good: Add a section describing what to expect this week. Better: Include Risks and Issues. Best: Give the high-level project schedule indicating if you are on schedule/budget. Great: Use Earned Value statistics to show trending.

Status Meetings. Don’t just send the status report. Schedule a weekly meeting to review the status of the project with the Sponsor. It doesn’t have to be a long drawn out event. Good: Pick out the highlights from the report that will keep her informed of the project. Better: Discuss risks and issues and explain how management can help mitigate and resolve them. Best: If you don’t have an answer to a question, admit it, get the answer and get back to her.

If you can do these four things consistently you will not only wow everyone, you will deliver your project successfully and without any surprises.

March 8, 2007 – Project Definition Trio

[NOTE: If you have not taken the opportunity, please register in the Guest Book to receive updates from the Cutting's Edge.]

Project definition is a tricky part of the project. If your environment is like most, you need to nail down the scope, the responsibilities and the approach as quickly as possible because the team has already started working. Given the limited time it may sound counterproductive but ideally you should create the preliminary list of risks and the project schedule at the same time.

As the image above illustrates, the Project Plan* (Scope, Management Plans, etc.), Schedule and Risks feed off each other as they are created. As the Scope Statement is defined and activities are defined they are added to the schedule. When an item is determined to be someone else’s responsibility there is a risk that it won’t be done.

While developing the Work Breakdown Structure (WBS) and Project Schedule you will uncover activities and perhaps deliverables that need to be added to the scope. Thinking through the implications of the tasks involved may trigger a thought for the Quality Plan or identify a new role to add to the Human Resource Management Plan. Risks are a natural result of drilling into the details.

Identifying Risks may expose the need for additional communication channels, tasks in the schedule or clarifications on the scope.

Working these three tools together will set your project on the right track from the beginning.

* Per PMI definition the Project Plan includes the Scope Statement, Risk Management Plan, Quality Plan, etc. The Project Plan could also be replaced with the Statement of Work (SOW).

March 7, 2007 – Deliverable-based Project Schedules: Part 7

Finally! We are ready to add resources and get on with the project.

Assign Resources. Just do it. Make sure at least 1 resource is assigned to each task and turn them loose. There are 2 tips I would throw out, though.

First, as I mentioned before, assign the resources 100% to your project unless they are physically on a different project for a set amount of time. This gives your scheduling tool the most options when calculating assignments.

Second, enter dollar values for your resources. If you are not tracking the value of your project you are not effectively managing your resources. A blended rate doesn’t truly cut it. If everyone cost you the same for your project wouldn’t you always pick the best ones? Think about professional soccer. What if you could get David Beckham or Tom Cutting for the same price? Not really a question, eh? My point is that each resource brings different strengths and different expenses to the mix. If you have a budget you need to balance both sides of the equation.

Add Constraints. Once you have the resources entered the final step in setting up the plan is adding the constraints. This includes updating the scheduler’s calendar with holidays, filling in vacation time, setting target dates with milestones, etc.

Wow. You have officially created the first pass at a deliverable-based project schedule. Which, of course, means it is scheduled for twice as long as you have and three times the budget. Now you need to go back and balance the resources, adjust the dependencies and make modifications to bring it into alignment with reality. But, these are all great topics for another day.

Before we run off, though, let’s recap. The objective was to build a plan based on deliverables. All of the tasks role up into one of the deliverable. Because we applied the 80% productivity factor we have a realistic view of the length of the project. We even added cost to the resources.
Assuming you baseline the original schedule and track it with Actuals and Estimates to Complete you can accurately report progress and project completion for each deliverable. Add columns to display the baseline and planned values for the start / end dates and costs and you can tell if you are within schedule and budget. This is the information management needs to determine the health of your project.

When is enough too much? We touched briefly on this when we were breaking down the tasks. The level of detail and amount of tracking you perform should be comparable to the amount of benefit you gain from it. If no one cares if you finish on time or within budget, then why bother tracking? Enough becomes too much when the effort outweighs the benefit gained from doing it.

March 6, 2007 – Deliverable-based Project Schedules: Part 6

All the tasks have been laid out, sorted into deliverables, aligned with predecessors and estimated for effort. If you are using an auto-scheduling tool like MS Project, the length of the project has been stretched out as if one person was doing everything at 100%. Now we want to set realistic expectations on the duration of each task.

Estimate Duration. “Why are we worried about the duration before we add the resources?” you might ask. Good question. The reason is productivity. It is easier to bake it in up front than to try and force it in later.

Mentally everyone knows that, unless you work overtime, an 8-hour task takes more than a day to complete. This is a factor of our productivity. Over the course of a year people are, at most, about 80% productive. This is based on the following calculation.
2080 hours in a year (52 weeks * 40 hours / week)
- 72 hours for holidays
- 80 hours vacation
- 48 hours sick time
- 24 hours training (non-project related)
- 52 hours status reporting (1 hour / week)
- 52 hours team meetings (1 hour / week)
- 88 hours interruption (1.5 hours / week)
1664 hours remaining (80%).

Obviously some people have more vacation, others don’t get sick, some have more training, etc. but in general this holds true. Without taking this into account at the task level you are setting yourself up to be late.

Some project managers do this by assigning all of their resources at 80% available. In MS Project there is a resource field named Max Units that they set to account for the productivity factor. Unless someone is assigned to my project only part time, I keep them at 100% available and set the duration of the individual tasks to account for the extra time. After all, they are still expected to work 100% of the time.

MS Project allows you use a custom field to automatically calculate the 80% rule. To do this use the Duration 1 field and create the formula [Work / 0.8]. This will calculate 8 hours as 1.25 days and 40 hours to be 6.25 days. If you place the Duration 1 column in the schedule beside Duration, you can easily copy and paste the estimated values into the Duration column.

You can also type it manually for each task using the 8 and 40-hour duration estimates as guidelines.

When we add multiple resources to a task, they are each assigned at 80% to it. They will still be assigned 40 hours of effort for the week, but the tasks will be spaced to account for interruptions, status reporting, overlapping tasks, etc.
The resulting durations are starting points. After you add resources and begin to use and refine your schedule you can make adjustments to them.

March 5, 2007 – Deliverable-based Project Schedules: Fixed Work Sidebar

Before we move on to discussing duration and adding resources there is a side step we need to take to discuss different task types. When you are developing your project schedule, most tasks should be set as Fixed Work. As effort is expended or added to the task this allows the tool to re-calculate the duration and show the new estimated completion date.

In MS Project there are 3 types of tasks: Fixed Duration, Fixed Units and Fixed Work. I’m sure other scheduling tools have similar terms. Units (U) refers to the percent a resource is assigned to the task (the productivity factor discussed above). Duration (D) is the number of days a task takes to complete. Work (W) is the amount of effort expended or to be expended on the task. The formula for calculating Duration is D = W / U (ex. 8 hours / 80% = 10 hours = 1.25 days). This equation and variables are used to determine when the task will complete.

“Fixing” one of these variables tells the tool not to allow it to change. If Duration is fixed and you add more Work, the Units will increase to balance the equation. In order to complete a 16-hour task in 1 day the resource will need to be assigned 200%. If Units are fixed at 100%, reducing the Duration of a 16-hour task from 2 days to 1 day will force the Work to 8 hours in order to maintain the equation. Neither one of these options helps you track progress.

Selecting Fixed Work is more realistic. If you have an 8-hour task scheduled for 1 day and you decide to extend it to 2 days you want the Work to remain at 8 hours, not increase to 16. The time you allowed for the completion of the task increased, not the effort to do it.

This is a big topic from project managers trying to figure out what MS Project is doing to them. They change a duration or end date and suddenly the estimated hours either explode or shrink to nothing. Very frustrating.

On the flip side, there are tasks that should be Fixed Duration. These tasks include support, status reporting and others that are based on the calendar rather than the effort. Although I have never used it, there is probably a good application for Fixed Units. If you have an example, add a comment to this blog and I’ll pass it on.

The task type becomes important as we move to estimating the duration.

March 2, 2007 – Deliverable-based Project Schedules: Part 5

With all the tasks defined and even divided up into deliverable many project managers would be off and running. Truth be told, projects can be successful with the checklist approach. The trouble is a checklist does not allow you to predict when deliverables will be completed, report on the true cost of the project or understand and impact the critical path. I suggest we keep pushing forward, then.

Determine Predecessors. When you are setting up your project schedule, enter the logical predecessors. These are the tasks that legitimately belong linked, like creating the document before you review it and ordering the hardware before you receive and install it. Fake predecessors are based on resource availability or just a random decision because something has to go first. These have their place throughout the project, but not when you are initially setting up the schedule.

The more tasks you can link with predecessors the better your scheduling tool can… well… schedule.

Estimate the Work. You may have noticed we haven’t assigned any resources yet. As you estimate the work for each task, think in terms of 1 person doing the work on that task uninterrupted. So, even if you anticipate it would take 2 people a week to complete a document, set the Work value to 80 hrs. Later we will add the specific resources.

While you are assigning the Work, you are probably thinking of a certain skill level or specific individual. These thoughts influence the estimate. Because of this you should document them as estimating assumptions and include them as part of your proposed schedule. No, this isn’t a fancy word for excuses. If you are expecting an expert Java programmer and end up with a novice, your assumptions were wrong and therefore your estimate will be off. With your estimating assumptions outlined you can recognize the impact and make adjustments accordingly (i.e. more or different resources, additional training, obtain more time, etc.).

March 1, 2007 – Deliverable-based Project Schedules: Part 4

Whether you select a Product or Phase structure, the steps to building a deliverable-based schedule remain the same.

Enter All Tasks. The next step is to fill in all of the tasks associated with the identified list of deliverables. Those deliverables may be the list from the WBS or, like the Phase structured schedule; it may include the separate building blocks (i.e. Requirements Document, etc.).

Drill down to the task level for each deliverables. You can use the WBS or other tool, but eventually you will need to switch to the scheduling tool. Although we are not ready to assign effort to the tasks, the general rule of thumb for the size of a task is between 4 and 80 hours per resources. Anything less than 4 hours is a pain to track and doesn’t offer much payback for the effort. Anything greater than 80 hours is hard to grasp. We are pretty good at understanding and estimating things that can be done in 2 uninterrupted weeks (= 80 hrs). Anything larger becomes difficult to estimate and should be broken into smaller pieces.

Each deliverable should be reviewed with the group or at least the individual that will approve it so include the task Review Deliverable and the milestone Obtain Approval for each one. (Note: a milestone is a task with zero hours and zero duration used to mark an important event or accomplishment.)

Add another deliverable at the bottom of the schedule for Project Management. The tasks under it should include Project Status Reporting, Individual Status Reporting & Time Keeping, Team Meetings, Client Meetings and Management. Some people track project management time as part of each deliverable but it is easier and cleaner to pull it out as a separate item.

The ultimate goal is to have all of the tasks neatly tucked in as sub-tasks under one of the deliverables. Collectively the deliverables constitute the whole of your project scope and anything not part of a deliverable would then be out of scope. However, as you complete your list of tasks, there will be some that don’t seem to fit. There are several possible reasons for this:
1. A deliverable has been missed. Something needs to be added to the scope of the project. If the scope has been agreed to you may need a change request to add to it.
2. The task might have been dumped on you when it should really be out of scope. This might require some push back to define your responsibilities.
3. It may be a legitimate task but the responsibility of another group. You may want to track the completion of the task but not the effort.
4. The process or lifecycle may require the task (ex. creating internal assessment documents, updating review committee checklists, etc.). Since the deliverable is a product of the process, these types of tasks can be incorporated into its creation.
You may have to get a little creative with some tasks, but to effectively use the project schedule to track and report progress you don’t want a rambling task list with no structure.