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.

January 8, 2009 – Going Covert, Part 2

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 12 – Monday. Take a deep breath….hold it…let it out slowly. Great. Just 5 days until Friday.

Actually the weekend gave me a chance to do just that: take a deep breath. It helps to switch gears for a bit. I mowed the lawn. I’m probably one of the few homeowners in southern California still mowing my own lawn, but it allows my mind to relax and put things into perspective. Call in Monday Madness, but I have a bit more optimism today.

I did two things this weekend. First, I took stock of what currently exists. Second, I made a list of what was missing with notes on getting them. Here’s what I came up with.

Have:

• Project description: New insurance offering – interface with external vendor supplying them with member information, they offer call in counseling. Supposed to be a big money maker.
• Deadline: 3 months from last Wednesday. Firm.
• Commitment: Promised by CEO to shareholders’ meeting 4 months ago.
• Documentation: Some. Charter was drafted but not presented. Requirements are stored as Use Cases in RequisitePro. Design is being developed mainly on whiteboards for now.
  Status: Officially in Design, but Requirements are not completed/approved and I heard that Developer 1 is coding. Not sure who Developer 1 is, yet.
• Need:
  Scope definition. Ideally it would be the Charter, but there may be something political going on there.
  Finalized and approved Requirements. Need to get them out of RequisitePro and in front of the Business.
  Introduction to external vendor project manager…if he/she exists.
  Find out who Developer 1 is and stop the coding.

What I didn’t do this weekend was put together a Schedule. Don’t have enough information yet.

Initiated a Stand Up Meeting. Actually, most of the team called in to the conference number and the Team referred to the meeting as a Scrum. Semantics. I asked 3 questions of each member:

1. What did you do yesterday?
2. What are you doing today?
3. What other projects are you working on?

Turns out most of them are working on multiple projects and are not getting much time for this one.

Day 13 – Got nailed last night for not having the Schedule ready. My fault for not resetting the expectation. By not saying when it would be completed I allowed Management to create an unspoken expectation in his head. His wishful thinking date didn’t correspond to my “you’ll-get-it-when-it-is-done” attitude.

After talking Management down off the ceiling I calmly explained the current state of the project, walked through the Have and Need list and said I would have a schedule by the following Monday. I think what he heard was “blah, blah, blah, blah…Monday.” At least now we share the same target date.

Note to self: Never promise anything on a Friday. They invented weekends to catch up on everything you don’t get done during the week.

The Business Sponsor is excited about the project. She sees it as an easy $100K profit each month. While we were chatting, I pulled out the Cost Benefit Analysis template and started filling it in. Technically it is an Initiation Phase document, but I had a plan.

Asked about the delivery date. Said she suspects that it was arbitrarily picked by the CEO, but the sooner the system is up, the sooner they can make money. Companies were already interested in signing up.

Set up a weekly meeting with her to give a verbal update, but assured her that she could pick up the phone at any time and ask. Along that line, I think I’ll send out one paragraph email blurbs throughout the week to update Management, the Business Sponsor, et al. When appropriate I plan on mentioning team members by name to give them credit for their actions.

Jump to part 3.

February 11, 2008 – Did You Get What You Wanted?

It was the perfect gift. Our daughter’s CD / Cassette player stopped functioning in time to add it to the Christmas list. We found just the right one on line for about $60. Unfortunately by mid-January it quit. It didn’t start skipping or playing songs backward, it simply refused to turn on. We contacted the company and sent it back: $19 shipping and $6 handling fee. Within two weeks a new one arrived on our doorstep. Unfortunately it was the $30 model. She was willing to live with it until it ate the first cassette tape she tried to play. Did I mention it was a book on tape from the library and it was completely destroyed, resulting in a $10 fine? So by now I have invested $105 and own a tape hungry paperweight.

Do end-users ever feel that way? They’ve gone over budget and ended up with a product that vaguely resembles what they asked for but isn’t anything they could possibly use. How can we avoid disappointing them?

Involvement. There are two sides to involvement: (1) Getting committed users to participate and (2) Using them effectively. Sell the concept that their participation is essential to building a successful product. Let them know the effort involved and timeframes they will be needed. Get buy in from their management to dedicate a percentage of their time to the project.

In order to maximize their availability, plan in advance when and how you will use them. Invite them to a kickoff meeting and lay out the plan. The tendency is to only use them a bit up front for requirements and then again for User Acceptance Testing. Send your designer and even your lead developers to sit with the users for a couple hours at a time to see what they do. The more your team understand what they are creating the better they can design and build it. Every week (two at most) touch base with the end user. Re-confirm the schedule. Bounce the latest design off them. Keep them involved.

Bite sized chunks. Agile methods use the concept of frequent releases, as often as every two weeks. The concept is not new, only the implementation. If you are not in an agile environment, instead of workable code, aim to have something tangible every 2 – 6 weeks. It may be the draft requirements or prototype, but it should be something that confirms the project direction and gains the confidence of and buy in from the sponsor and key stakeholders.

Picture it. Graphic illustrations and mock ups help people visualize the direction of the product. Use Case Models was one of my recent blog entry topics. This is a great way to drill out requirements with minimal effort.

Get Touchy. Nothing peaks the interest of end users like a demo. Moving to a screen version that mimics the final product sparks the memory, too. All too often you begin to hear, "oh, yeah, we forgot to tell you about ." Try to keep your patience and remember that the goal is a usable product that meets their needs.

As a side note, make sure they understand what they are seeing. I used to program handheld inventory machines. We made the mistake of giving the sales people a PC based tool that allowed the client to view a mocked up version of the application. It was great for developing the requirements, but their assumption was that once it was on the computer screen we just had to download it to the scanner and ship it. I’m convinced some of the sales guys thought so, too.

Keep Control. In addition to controlling your patience, it is important to control the direction and duration of the project. Too many directional changes and the product will be outdated before it ever goes live. The best way to deal with this is by starting with a core functionality release and building on to it. When an enhancement or change is raised, define it, estimate its impact to the project and have the sponsor prioritize it. Agree on which release it should be part of and what gets bumped for it. Then get back to the current release.

Remain Flexible. It may sound contrary to keeping control, but flexibility is your ally. In the end it will be the users of the system that define if the resulting product is a success. Regularly verify the critical success factors of the project and align with them. When presenting the impact of a change, explain it in terms of the success factors. If the go-live date is vital, show how the request will impact the delivery. If functionality is key, reference the priority list and ask how the change fits into the bigger picture. Communicate the trade off and get their informed direction...in writing.

If all else fails, charge them a $6 handling fee and tell them to expect a box in about 2 weeks.