Showing posts with label Cost. Show all posts
Showing posts with label Cost. Show all posts

Sunday, January 24, 2010

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.

Sunday, September 14, 2008

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.

Monday, September 8, 2008

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.

Sunday, May 4, 2008

May 5, 2008 – Keeping Junk and Throwing Valuables

Value. It is a word that has come up several times over the last few weeks. My wife recently snagged me two Eisenhower dollar coins (1974 and 1978) she saw someone spending. We were also speaking to a realtor about possibly selling our house. Neither the coins nor my house were worth as much as I had hoped, but without knowing their value I might have given away something for nothing.

This can happen on your project. It starts with a promise made during a meeting or by one of your team members while gathering requirements. Then, as you start to estimate it and assign a cost, you realize that what seemed simple will break the budget. Here’s how to avoid the problem.


  1. Scope Definition. Get it drawn up and agreed to. Whether you are using Use Cases Models or hand written napkins, spell out what you were asked to do and get it agreed to.


  2. Scope Awareness. Publicize what is in and out of scope. Make sure your team understands the need to keep the design and development focused on what is agreed to and nothing else. Stress the same concept with the business, too.


  3. Change Readiness. Create a way to change the scope: a change management process. Assure everyone that change is good and can result in a better finished product. Lay out the path an idea needs to follow to become a reality. Include what constitutes a change; estimating the effects on cost, time and resources; and who has to approve it.


  4. Idea Promotion. Encourage your team and the business to identify changes, especially early in the requirements and design phases. Drawing out those ideas gives you an opportunity to deliver something of real value. Once they are identified run them through the change management process to determine if or when they will be included. Some ideas may be good enough to oust existing scope or extend the project. Others will hit the wish list and never see the light of day.


  5. Effective Giving. Even if you are giving something away, determine and communicate the value of it. Adding another field to a display may not be significant, but one request can become twenty if the perception is that they are free.

Now you have the right people making the best decision while removing you from having to say "No!" all the time.

On the flip side, too often we hold on to things that have no real value. Garages quickly fill up with slightly broken electronics, old monitors, lamps missing shades and even partially bent golf clubs. When the garage is full people rent storage units at $150 or more per month to hide things they can’t part with. At those prices it doesn’t take too many years before the money spent could have purchased brand new replacements for the broken items.

Project secrets are not worth the price. I’ve had to pay before. On a project with clearly defined testing dates, one group continued to tell me they were on schedule. The Monday that testing was to begin we held a final go/no go meeting. They arrived to inform us that they had completed... their design. Construction was far from finished. If your dates are slipping, be the one to step up and identify it as a Risk. Do everything humanly possible to complete on time, but get the problem out in the open.

Unproductive resources cost too much. Sometimes we think that any resource is better than no resource. Compare your dead beat developer against that statement. Is he producing anything of value? Is she bringing the moral of the team down?

Check your value system. Are you throwing away valuables or holding on to junk?

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.

Friday, January 12, 2007

January 12, 2007 – How to Really Fix a Failing Project

You project is in trouble. You know it. Your team knows it. But somehow you have been able to keep it from your management. You need a quick fix. But there aren’t any. What can be done to get back on track? Since yesterday's ideas didn't help, here are some suggestions that might point you in the right direction.

Refocus the Scope. Begin by going back to the defining documents including your Charter, Statement of Work and approved Change Requests. Figure out what you have committed to accomplish. Conversely, document all of the things that were unofficially added to the project. What you are trying to obtain is a clear understanding of the commitments and the expectations of others. With these lists in hand, meet with the project sponsor (or similar key stakeholders) and agree on what should be part of the current effort.

Draw up the Schedule. Based on the remaining effort and current resources, recalculate the schedule. Forget the deadlines placed on the project at this point. Given the amount of work and people available, determine a realistic timeframe to complete the revised scope.

Determine the Cost. Find out what the budget is and how much has already been spent. After calculating the difference between the two amounts (hopefully it isn’t negative) compare it to what remains to be done. Based on your revised schedule run the numbers to determine a reasonable Estimate to Complete.

Review Lessons Learned. Meet with the team and other stakeholders to determine where the project went wrong. Develop a list of steps to take in order to avoid the same thing happening next time.

Develop Alternatives. Using the scope, schedule and cost information review the options available. Based on the Project Triangle* that pits scope, time and cost against each other, consider the impact of each of your options on those factors. Will your plan include adding more resources? Extending the date? Reducing the scope? Although “Phase 2” is always the answer most project jokes, it can be a solid alternative. In some extreme cases the right decision will be to cancel the project. Although an unpopular choice, some projects need to be dropped. Reduce the testing phase is usually the popular option, but I don’t suggest it.

Admit Reality. Once you have drawn up a couple of viable alternatives, present them to the management team. Begin with a healthy dose of reality. Management does not like going through the failed project dance. If they have to do it twice things get ugly. Lay out the situation, preferably without playing the blame game. Then present your plans for getting back on track. Let them help you talk through the options and make suggestions.
Start Fresh. Issue a revised scope statement, obtain the funding, reset the schedule and obtain appropriate approvals. You have been given a new lease on your project. Work the plan and make sure to incorporate the Lessons Learned from your first attempt.

* Project Triangle: Picture a triangle where each of the three sides represents Scope (or functionality), Time and Cost. If you change one side it impacts the other two. Reducing the size of the Scope side will allow you to reduce the Time and/or Cost side. It is the same for the other sides as well. This is a standard and effective way to communicate the struggle between the three.