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.

September 29, 2008 – Back to the Basic: Communication - What

While waiting in line at Costco to buy my $1.50 hot dog and soda, I watched the manager collect money from the tills and seal it in plastic, oblong containers. He walked over to the wall and stuck them in a pneumatic tube. With a muted *phoomp* they shot up and out of sight.

Long before email, the quickest form of interoffice communication was the dial switch message tube. Plastic cylinders were sucked from one end of the building to a central switch board. From there they were placed in another tube and pushed to their destination. Instead of having a megabyte size limit for attachments there was a weight limit.

Given the length of time that people have been communicating, the topic of communication is obviously huge. Methods have evolved from papyrus to paper and are headed to paperless…which just seems to create more paper. Communication is concerned with the entire package: what to communicate, when to say it and how to deliver it.

What to Communicate. Simply put, as a project manager you need to communicate answers, accolades, applause, bad news, budgets, briefs, causes, critiques, costs, delays, dangers, decisions, earned value…and I’m only up to the Es!!! An estimated 80% of a manager’s job is communication.

So how do you know what to communicate? That depends on who needs to know.

Delivery Team. To the team you need to articulate the vision and direction of the project. Begin with the defining documents (Charter, Scoping Document, SOW, etc.) to lay out the vision of the project. Use the Work Breakdown Structure (WBS) to drive discussion of what needs to be accomplished and how to get there. Set delivery expectations by laying out a schedule with assigned resources, specified effort, and agreed upon dates.

Since communication is a bi-directional exchange, require feedback. Collect status, effort, re-estimates, criticism and suggestions. Don’t accept excuses, complaints and whining without moving them beyond to solutions.

Sponsor / Management. Contrary to popular belief, management does not always want a rosy picture painted for them. They need the truth told succinctly so they can make informed decisions. They also need bad news delivered as soon as possible so they can take action.

On the other hand, management, if left to their own devices, will make assumptions that may not be true. Understand their expectations and work to align them with reality. Based on the scope definition of one project I was on, we successfully upgraded a software package. The directive for Phase 1 was “out of the box” and we and held the modifications to a minimum. At the end, the sponsor was disappointed she didn’t get the new reports she wanted. I had failed to keep her expectations focused on the scope.

Governance / Auditors. The job of the Governance (Program or Project Management Office) and Auditor groups is to ensure that the safeguards are in place to make the project a success. They want to know that you understand the processes are following them. If your project doesn’t fit the mold, meet with them up front and carve out a new mold that everyone can live with. Communicate lessons learned and process improvements to make projects work more effectively.

End Users. Usually End Users are ignored until the product is virtually complete and then they are brought in to ooh and ah over what we created for them. Your job is to understand their expectations from the inception of the product, align those expectations with the development, confirm them in the User Acceptance Testing and deliver successfully. Communication is the key through each of these steps.

Others. There are always others. Some of them can kill even the most successful project. While speaking with my PMO counterpart on a mass transit project, I asked who was handling the communications to the ultimate end users: the people taking the trains and buses. The project was to implement smartcard technology into the public transportation system. If they were unprepared to use the system, it would be a failure. Who will be impacted by your project and how should you be communicating the changes to them?

The ultimate purpose of communication is to eliminate surprises. Do that and you will be communicating the “what.”

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.

November 19, 2007 – Automotive Sponsor Problems

It is never good when your mechanic calls and asks, "How attached are you to this vehicle?" Friday was not one of my better days from that perspective. I drive a ten-year old Plymouth Neon and normally it gets me where I need to be. Sure it leaks oil and steering fluid but the AM radio still works and three of the four door locks are still automatic. But Friday it decided to die on the way to work.

The mechanic said it would take about $900 to get it back up and running. Then there was the list of things that "need" to be done totaling another $1000. I just checked and my car is only worth about $2500. I felt like the sponsor of a project that has gone bad. Actually there were three things that drove that feeling home.

Return on Investment. The mechanic was the first to bring it up with his opening question about my love for the Neon. He could tell the cost of fixing it wasn’t going to be cheap. Prior to undertaking a project, a company needs to understand the ROI, both the costs and the returns. The projected costs are more than the expenses to complete the project. Don’t forget to include training, maintenance, licensing and other life cycle pieces.

These costs should be balanced by the expected returns from the endeavor. Savings are usual the first thing considered. How many people will I replace? How much time and money will it save. Add to these benefits forecasted increases in projected sales because staff can spend less time fiddling with the system and more time with customers. Consider that the new online experience may lead to more purchases. Customer satisfaction may net more repeat business. Think through the project purpose and project the positive results of success.

Lack of Information. Friday morning I certainly didn’t have enough information to decide whether or not to give up on my car. I needed a multiple choice question and was handed only a true / false option. How much was my car actually worth? What would it cost to get an comparable vehicle? Was it worth more as scrap metal? What could I really afford? Would there be additional expenses I didn’t anticipate? If I bought a different car, would it have more problems than this one?

When deviating from or adding to the project scope, a Change Request documents the final decision, but the discussion starts by answering questions. Sponsors expect project manager to supply them with the information to answer those questions. Why wasn’t it in scope to begin with? What are the consequences of not doing it? How much is it going to cost? What other options are there? If the answers aren’t readily available, you may need to request funding to research and find them.

Risk Management. Among the "other" items my car needs are new front brakes, brake fluid flushed and replaced, and my back breaks aligned. Total cost an additional $450. The risk of not fixing them is obvious. If you can’t stop your car, something else will have to. Whatever you use to stop it (another car, a brick wall, etc.) will probably cost more than $450. As with any risk I could Avoid, Transfer, Mitigate or Accept it. Buying a new car would avoid the problem. Making sure my collision insurance is up to date would transfer the risk. Getting the brakes fixed would mitigate the issue. I opted to accept the risk and postpone the brake fix to a future phase of the project. You may want to stay off Beach Boulevard for the next week or so.

It could have been worse, though. Had the car continued to run it would have completely overheated and destroyed the engine. I wouldn’t have had any choices at that point and my next blog would have been about purchasing a new car. Don’t hide project problems from your sponsor until things overheat and there are not choice left.