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.

April 6, 2009 – Going Covert, Part 6

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 27, Tuesday – Management meetings have been switched to Tuesday. That actually works out well. On Monday’s I approve last week’s time, update the schedule and fill out the status report on line. In Tuesday morning’s standing meeting I confirm the status in time to make any last minute updates before the firing squad.

Speaking of firing squads, I think I’ve found a way to turn the tide on the management meetings: shoot yourself first. It sounds drastic but it seems to work.

Today I came in with my usual reports. This time, instead of waiting for the barrage of questions and going on the defense, I attacked…myself. I had already asked myself all of the questions I knew they wanted to so I walked through them all before they could start.

“We are currently 2 weeks behind schedule. In order to make the deadline I have asked the team to fast track some of the testing. We’ve completed the extract and started the data conversion and transfer pieces. While that is happening we’ve used Excel to generate a test file for the vendor, Counseling Phone Support (CPS), to use.

“There are 2 major risks to the project: 1) any additional changes to the format or content of the data. 2) The inability to make web services work as the interface.

“Because the probability of either of these remains high, I have an individual finalizing a manual means to produce the file and FTP it to CPS for processing. It may be labor intensive but we could extend the project indefinitely by supplying the data by hand.”

I answered most of their questions before they even asked them. I even threw in some they should have asked. For those I didn’t have answers to I brought the acknowledged the issue and told them when I thought there would be an answer.

Some of them looked bored. Quite a switch from the last meeting I had with them.

Day 28, Wednesday – Wednesdays always offer a little breathing space. The rush for the end of the week hasn’t started quite yet and all the reports are done. It gives me a chance to “walk around” and check with the team. It’s a bit easier when they are all co-located but I try to touch base with most of them somehow during the week. Still trying to work out the video thing with the offshore team.

Back to the PM problems. If I remember correctly we had just solved world hunger and started on world peace. No, that wasn’t it, but it sometimes helps to put this into perspective. There are a lot bigger problems in the world than the Business getting the requirements right the first time.

Estimated End Date: Deadline was set before anyone really estimated the effort.

We identified 3 types of estimates: Ballpark Estimate, Budget Estimate, and Detailed Estimate.

Ballpark Estimate is used the first time an idea is tossed out. It could be as much as 75% low because we only know the bare minimum.

Budget Estimate is given after a set of high level requirements is reviewed and an impact assessment team has reviewed it. This estimate can be up to 25% low and have a realistic duration. The end date should be announced until the project actually starts.

The Detailed Estimate is done while the design is finalized and should be within 10% of the final cost. End date should be set.

As a group we’ve decided to start using the terms. Without management support we can’t enforce it, but consistency may breed familiarity and that can lead to acceptance.

March 31, 2008 – Estimating Lessons Learned – Communicating the Results

Back in December my 1997 Plymouth Neon was totaled when someone rear-ended me, forcing my car into the next one. It is an odd feeling to look into your rearview mirror and know that the car behind you isn’t stopping.

The insurance company sent me a check for a whopping $2,545. To quantify that massive amount, they compiled an 18 page document comparing my car to similar vehicles using mileage adjustment, feature assessments and other data. All that information was their justification of my car’s estimated value.

Lesson 13 – Tell them where you got the numbers.

An estimate is a guess based on the approach, assumptions and constraints that make up your understanding of the project. Theoretically your team’s estimate has some basis in reality. The key is to communicate that reality to your key stakeholders without them asking what color the sky is on your planet. In Lesson 10 we said to “Document your reasoning.” Let’s look closer at what that means.

Begin with the planned approach for the project. Are you cloning an existing application or starting on a new platform? Will there be a proof of concept performed? Is a pilot phase part of the process? Will it be a “big bang” conversion or phased in over time? Laying out the approach sets the foundation for the numbers. Keep track of any concepts that don’t make it and why they were dropped for future reference.

For constraints, any discussion or thought process that includes can’t, shouldn’t, must, or similar words needs to be recorded and confirmed. If you are saying “we can’t X if they don’t Y” or “we must have Z” then put it down on paper and bring it up.

Assumptions are more difficult to call out. In our minds we see them as obviously true. The hard part is pulling them out for examination and making sure everyone agrees. These can be negative assumptions (any discussion or thought process that ends “we’re not doing that”) or positive (“Marketing will surely have the brochures ready by then”). You may assume they are out of scope but unless it is stated there’s the chance others may think it is in.

Document these and you won’t end up looking at your estimate and saying “what were we thinking?”

Lesson 14 – Email doesn’t cut it.

Schedule a meeting and present your estimate. Sending out an email and expecting a meaningful response isn’t going to cut it. Either face to face or via an on-line conference, you need to walk it through. Explain the Type of Estimate (link) and your confidence level. Recap the estimating process used.

This is your chance to review and verify the approach, assumptions and constraints used to generate the estimate. Make sure everyone is heading in the same direction. Save time and energy by identifying the differences and adjust course earlier in the process.

Had my insurance company simply sent me a check for my Neon, I would have been disappointed and resentful, causing me to switch companies. Because the agent walked me through the numbers I understood that they probably gave me more than it was worth.

Lesson 15 – It is still just an estimate.

In the end, however precisely thought out, meticulously defined and well communicated, it is still an estimate. Things change and assumptions are proven untrue, but with a solid estimate as at its base, your project will be off to a good start.

March 24, 2008 – Estimating Lessons Learned – Estimate Creation

No matter which estimating type you use, there are common steps to creating one.

Lesson 6 - Include your Team. Don’t estimate in a vacuum. Using the team sets you up for success on two fronts. First, the estimate will be more accurate. They know the details of what needs to be done, without which you are just pulling a number out of your hat. Second, it builds buy in and commitment. If they are involved in the process they have ownership of the final result.

Lesson 7 - Break it down. The question always asked is “How do you eat an elephant?” Frankly, I don’t believe anyone eats elephants any more. It is probably a cholesterol thing. How do you get in shape is a different animal. Reduce it to chunks: Diet, Exercise, and Support. Then break those into pieces. Diet - What to eat and what to avoid. Exercise – Classes, weights, aerobics, swimming or walking. Support – find a group and meet regularly. Broken down you can wrap your mind around it.

Traditionally projects create a Work Breakdown Structure (WBS) to identify the work products. Another approach is using Use Cases to drill to specific stories. However you do it, chop the big chunks into smaller units that can be more accurately estimated.

Lesson 8 – Mix and match estimate types. There is no rule that says you must estimate all pieces the same way. If there is a piece that looks like something you have done before, use the Analogous technique to estimate it. For reports the Parametric type may be appropriate.

Lesson 9 – Ask the right questions. One of my previous employers estimated a project to complete a previously implemented system across an enterprise. The question they failed to ask? “Does it work in the area it was first implemented?” The answer would have been “no” and the estimate would have been considerably higher.

Lesson 10 - Document your reasoning. How you came up with the number is as important as what the number is. We’ll delve into this more next week.

Lesson 11 – Sketch a calendar. Create a sanity check for your estimate. Lay out the high level estimate on a timeline by month. Estimate the number resources you need, when you will need them and for how long. Include the number and type of resources broken down by week. Keep it simple as illustrated in the graph below.

I purposely used Excel and kept the image rough so that it does not convey any semblance to accuracy. Does the resource effort look accurate compared to the numeric estimate? Sometimes this rudimentary method allows you to see it from a different angle and find gaps in your estimation.

Lesson 12 - Add Project Management. Include time for status reporting, timekeeping, status meetings and other items. Be aware of other tasks that Project Managers may be pulled into like steering committees, metrics management and resource management. For larger projects a Project Coordinator or even sub-project leads will be necessary to help manage the effort.

In some respects establishing the actual estimate is learned and perfected as you do more estimates. What are some of the tricks you have picked up over the years?

March 18, 2008 - Estimating Lessons Learned - Agile Methods

One of the most pathetic looking sights on the highway is a man walking, head down, with a gas can. He represents the ultimate in poor estimating practices. It is bad enough that he ran out of fuel, but he was probably already late or he would have stopped to get gas. Having the embarrassment of trekking back to the car only adds to his dilemmas.

One of the misperceptions of Agile development is that the team continues to code until they “run out of gas” by hitting the target date.

Lesson 5 – Agile development requires estimation.

Although non-traditional methods differ in their techniques, they still rely on estimates to plan for and meet projected dead lines. We’ll look at three different types: Predictive Modeling, Time Boxing and Planning Poker.

In order to be effective, each of these estimating types requires a prioritized list of functionality and features that define the scope of the project. SCRUM estimates items on a Product Backlog. In the Rational Unified Process (RUP) Use Cases are identified and estimated at a high level (ex. 2 days for A and 5 days for B). XP uses Stories. The difference lies in the way the estimates are determined.

Predictive Modeling involves breaking the product into pieces and assigning relative work units to each one. For example, you may assign feature X 5 units and feature Y 10 units because Y is 2 times bigger or more complex than X. Initially you predict the duration for the first set of features and extrapolate the full project effort based on those numbers. Upon completion of the first set you have a better idea of how long it will take to complete the next, allowing you can refine your prediction. As each piece is completed you can more accurately estimate the remainder of the project.

Time Boxing is based on the concept of set periods of duration, anywhere from 1 to 6 weeks, for each release. Based on their size, complexity and dependencies, Use Cases (or features) are scheduled for specific releases throughout the project. At the end of each release the next set of Use Cases is re-evaluated to verify that they are the right ones and that they can still be completed in the timeframe. If a trend begins to appear showing that the team is consistently falling behind, the overall project schedule will require re-evaluated.

Planning Poker is a variation on the Wideband Delphi technique. In the 1970s Barry Boehm and John A. Farquhar expanded the US Armed Forces’ Delphi method to use multiple experts giving anonymous estimates for pieces of a project. Those estimates would be reviewed and the pieces with big discrepancies would be discussed in meeting and re-estimated.

As with every other aspect of development, Agile decided to speed up the process. In a Planning Poker session, team members are given cards with numbers on them, representing work effort (i.e. 3, 5, 10, 20 hours). Individual stories are reviewed and discussed by the team. Each member then selects a number from their deck that corresponds with their estimate. Only after everyone has picked a number do they show their estimates. If the numbers are close together, the value stands. When there is a large difference, additional discussion is held and another secret estimate is held.

Each of these estimating types has their strengths and weaknesses. Sometimes it is best to use a different technique for different parts of the project. The key will be how you explain and communicate the numbers to the project stakeholders. We’ll cover that next time.

March 10, 2008 – Estimating Lessons Learned - Traditional

Estimating is probably the hardest part of any project. My wife will attest that my ability to estimate when I will leave work is inversely proportional to the importance of me getting home at a specific time. The plan will be for me to only work until noon the day we leave for vacation. At 2:00 I will still need to finish my status report, change my voice message and set my out-of-office email. Maybe I just need a better estimating technique.

Lesson 4 - There are many different ways to come up with an estimate. This week we will take a look at the more traditional methods: Analogous / Top Down, Parametric, Bottom Up and Work Distribution. Next time we will discuss a some of the newer methods like Time Boxing and Wideband Delphi.

Analogous (Top Down). When a project is first considered, the quickest ways to develop an estimate is to compare it with one from your past. The question then becomes: Is it half as big or 5 times bigger? The focus is on what is different from the previous project. This technique requires the least amount of detail and gives the widest margin of uncertainty. This typically regulates it to Rough Order of Magnitude estimates.

Parametric. Normally associated with construction, Parametric estimates are based on historical data. For building a house a contractor may price it at $103 dollars per square foot. The calculation is built from years of completing similar jobs and calibrated with the current cost of materials. This is similar to the use of Function Point analysis in software development. A Function Point is a single unit of business functionality. The cost (in dollars or hours) of a single unit is calculated from past projects. New projects are defined by the number of function points and the math is done to create an overall estimate. This can be effective for features of similar sizes like reports or system interfaces. If historically it takes 40 hours to design, create, build and implement a report, 10 reports is going to take 400 hours.

Bottom Up. This form of estimate requires a more detailed analysis of the project. The Work Breakdown Structure (WBS) is defined further to identify the tasks associated with the work products. Each task is estimated and the cost for all of the individual pieces is combined to create the overall total. Using scheduling software like Primavera and Microsoft Project helps to define, record and plan the estimate. This is the most accurate type of estimate, but it requires a level of detail usually only known after the requirements are fully defined.

Work Distribution. Somewhere between Bottom Up and Parametric is the Work Distribution method. Usually the development phase of the project is estimated at some level of detail and the time for the other phases is based on a percentage of the project. The percentages are specific to the organization and project team performing the work based on their past performance. Generic numbers could be:
Phase %
Initiation 5
Requirements 15
Design 10
Construction 30
Testing 20
Implementation 5
Project Mgmt 15

The development team estimates the construction effort and the other hours are calculated based on that amount.