No Surprises!

I always set the expectation on my projects there should be no surprises. Why? If I’m chosen as the Project Manager, the one to integrate the project components together, I’d best have some idea of what is going on. With virtual surprised business manproject teams, this can be more difficult — but I still have to ask. Ideally I will be “cc’d” on all important messages, correspondence, and calls, and if there is a significant meeting I have to miss, notes should be taken and made available. This isn’t about my ego or control issues, but about doing my job.

Unfortunately many project participants (and yes, project sponsors) are still in the dark. They don’t understand the necessity of this type of request. These folks can usually be coached. Or perhaps they have a form of “political” agenda that’s contrary to assisting you in getting the job done. These are the folks you need to work with the project sponsors with to have removed from your project.

Now please don’t mistake “surprise” (something significant happened and a project participant didn’t inform you) with other events. Emergencies do come up. Business priorities do shift. This is when you have to pull the team together, replan, and move on. Just a few years ago I had a project with $20M worth of computer equipment in a warehouse — each system was being tested, prepped with new software and hardware, and packaged for shipping to a customer. It was nearing the end of the year and I got a phone call telling me business priorities dictated the systems be in customer hands by the first of the year — the original plan called for 6-8 weeks later. We looked at our options to fast track — testing standards were maintained, but we notified HQ we needed more materials to complete more of the work in parallel, worked out a parallel shipping schedule, and secured additional transportation to help us complete on time. Come January 1, everyone was happy!

Stick to Your Guns (When You’re Right)!

According to the PMBOK® Guide, as project managers we’re supposed to be the only ones who can put all the puzzle pieces together to complete the project. This is a tall order, especially for someone that might lack confidence or is unsure of him- or herself. When you’re right, stay the course, and things will usually work out for the best.

My very first role at GE Information Services was to be “technical support” for the development of a new product and be the liason to the consulting company engaged to develop the product. Within days of joining the company I received a call from Customer Service — an important client had a significant problem in running the old version. The support people in customer service were stumped and were escalating to the Engineering Department — me in particular.

They presented me with the “abend” dump from an IBM mainframe with little other information. I inspected the error messages, trying to put together a story that might help the customer, but it was difficult. All indicators pointed to a form of error in the statements that ran the program, but the actual statements weren’t available and my research was pointing to something specific to the client’s system configuration. I relayed my findings and hoped for the best. Unfortunately, the customer wasn’t buying it.

Within a couple of days, my contact in Client Services arranged for us to drive to Baltimore to meet with the customer. On site, I related my research directly to the customer — an IT Director for a Fortune 500. He wasn’t buying it, and the fact I only had a vague indication it was a local problem wasn’t helping. I suggested they check some local installation parameters again. By this time, the IT Director was very agitated and berating my colleague from Customer Service. I was afraid my career was going to end before it even began. They both turned to me again, and I repeated the information one last time.

By this point, the IT Director was red in the face. He jumped up and stormed out of the conference room. My colleague and I were resigning ourselves to returning home in defeat, when suddenly a much calmer, happier IT Director returned to the room. Turns out although he insisted he had double and triple checked everything, he did find one small error — and when he corrected it, everything ran perfectly. My research and insistance paid off.

Fast forward around a half dozen years and I encountered another problem, now as a manager. I was to give a presentation to the Deparment Manager on the pros and cons of two programming languages and make a recommendation. I reviewed my pitch with peers and my boss, making sure it was as perfect as I could make it. Before I could give my pitch, the Department Manager picked it up, flipped through it, slammed it to the table, and declared “this is biased!” I was stunned — I knew the report was very balanced and had the right recommendation, so meekly inquired what led him to make that statement. While I don’t remember his exact response, I could see it was more emotional than logical. Once again, I stuck to my story — I worked with the experts and reviewed it with my boss. Perhaps we could go through it in more detail. Sure enough, once he read and undestood the presentation and how it was derived, I got the green light to proceed.

I’ve always remembered these and other incidents where I carefully chose my information, did my homework and stayed the course to success. This comes in useful every day when dealing with colleagues and customer, since care and confidence are respected qualities.

Get Motivated!

This week I had the pleasure of taking my team to Peter Lowe’s Get Motivated! seminar. It was a great opportunity for low cost, high value professional development. A cross between an Amway meeting, a Bible revival, an infomercial, and a seminar, the day was packed with usable information on success, leadership, tools to manage your personal finances, and sales closing. The knowledge and wisdom in these areas came from Krish Dhanam, Zig Ziglar (now 80 years old!), Steve Forbes, Phil Town, Marty Schottenheimer, Tom Hopkins, LaDainian Tomlinson (better known as LT to San Diego Chargers fans), and presidential candidate and former 2001 Time Man of the Year, Rudy Giuliani.

Even those with additional seminars to sell, like Tom Hopkins, had great things to say. Tom encouraged the audience to treat failure as a learning experience and change their attitude to the word “no”. Does this sound in line with the theme of this blog? His “Champion Creed” is “I am not judged by the number of times I fail, but by the number of times I succeed.”

Rudy Giuliani had these seven things for leaders to work on:

1. Have strong beliefs
2. Be an optimist
3. Have courage
4. Relentless preparation (if you anticipate everything you can, you can plan the unanticipated!)
5. Teamwork
6. Communication
7. Love people

There was plenty here for project managers, leaders, sales people, and anyone who wanted to hear more on these topics. It was well worth the cost. Be sure to check them out if they visit your city.

Cover All Your Bases

One of the best compliments I’ve had as a Project Manager is “Ray, you really know how to cover all your bases.” I don’t think those around me at the time it was offered really understood what it meant. It is another one of those “lessons learned” frequently ignored.

Think of your project as a chess game. Each task or activity usual involves some form of decision and has an outcome. There is a large tree of possible paths and outcomes. If we plan and think through those outcomes, we can usually find weaknesses. Dates can be missed, budgets can be exceeded, and quality might not be up to snuff. If one of these things happen, its always good to have the alternate plan in your back pocket.

A recent example came up this week when a project participant asked me why they were developing a software demonstration using two different technologies. They thought it was wasting resources. The issue at hand is a certain technology is currently in use, but the client is considering another. The best way to show we are the right project to choose is to show them we can do it equally well using both technologies since they are not yet prepared to state a technology requirement.

Now of course those of you who work on larger, higher risk projects recognize this as a different skill set — risk management. You look at the project outcomes early on to decide if contingency plans are required. More planning is done up front. In the lower risk and smaller project arena, just covering your bases is usually sufficient.

So next time you work on a low risk project, know “who’s on first” and cover your bases! If more is at stake, a complete risk management plan is likely warrented.

“I Sent a High Priority Email …”

Does anyone see the oxymoron here? When I started my Project Management career, electronic communication was a luxury and normally used to correspond with overseas or remote offices – internal use only. We learned to carefully pick and choose the communication medium to ensure the message was successfully sent and received. Customers were contacted by phone or letter.

While working at GE Information Services, I occasionally did some consulting for our GTE account. If you lived in Florida and picked up your phone, dial tone was always there because the supporting GE systems (contacted before dial tone was provided) had 99.999% availability and sub-second response time.

The US Postal Service (“snail” mail) claims 98% accuracy. One evening watching the news I observed the results of a reporter who “tested” the system within the state of California and observed a rate of a little over 90% accuracy. Not perfect, but not a bad way to get a message through.

For a few years, I maintained an email server for my local PMI component. When I started, there were around 600 members (we have over 1,000 today). Each month I downloaded our member email addresses from the PMI Global Operations Center and sent meeting and other key announcements to members. On the average, only 75% of these messages got through. Some of the reasons messages didn’t get through included:

  • Spam filters that didn’t like a message from a mass email sender.
  • Spam filters that didn’t like some of the words in the message (one member works for a company that rejects all external emails mentioning words like “price” or “cost”).
  • Errors in typing the email address.
  • The member’s email server (and yes, this included some major corporations) was down at the time the message was sent.
  • The member’s email box exceeded its message or storage limit.
  • The sending mail system had technical compatibility issues with the receiving email system.

Note the latter four apply to internal corporate email systems as well as external systems. So you can imagine how I cringe when I hear a critical message was sent by “high priority” email. Doubly so when the sender and receiver sit just yards or miles from each other.

Can you hear me now? Even with dropped calls and “dead zones”, you are more likely to get your point across by cell phone as opposed to email. So my lesson learned for this week: if you have an urgent message, choose the method that has the best chance of receipt to ensure a timely and accurate resolution. Sending high priority email just leaves things too much to chance.

“PLAN” is not a Four-Letter Word (Part II)

Moving forward ten years, I found myself as a program manager responsible for several projects related to a $10M+ Unix rollout. A colleague was responsible for the procurement and hardware side of the operations while I was tasked with getting a workstation into the hands of 400 developers in 16 locations. Each had to be trained on the basic operations of their workstation, they had to receive specialized training for their area of expertise, and I had to manage the support of the systems going forward.

Things were all well until I found myself in the middle of an emergency meeting called by senior management. It seems like their initial decision to exclude any form of internal network wasn’t going to fly. What’s more, other company divisions were approached for assistance, but their charges proved to be several times management expectations, especially since there was nothing budgeted. I was quickly introduced to a consultant since the workstations were due to start arriving in six months. We had a week or so to plan how to install a Unix LAN in a nine-story building, another two-story building, and to provide a solution for field offices – the other 14 locations.

With our short time together, we put together a detailed work breakdown structure and a basic diagram of our network plans. A detailed budget added up the various hubs, brouters, wiring segments, construction effort to build shelving in phone closets, building services support to pull wires, and telephone and electrical personnel to assist. Over the course of the project there would be more than a dozen people involved.

Once more, we did our homework. It turns out every office already had an extra jack for telephones or modems that could be used for the LAN – we carefully tested this “theory”. This was perhaps the largest savings of the entire project. But after putting together a $300K budget, senior managers asked us to find ways to trim $50K. We reviewed the plans and decided we could use a less formal wiring plan in the smaller building – the company had a short term lease there. Making some of the wiring up in-house also saved a few dollars.

With careful management of the installation of each major segment, we had the basic wiring in place, incorporated our laboratory workstations into the network, and also brought on a collection of PCs and Macs – all with a comfortable margin before the workstations arrived. The project finished on time, and below budget a sufficient amount for us to include a T1 line to connect the two facilities together – something management was willing to forego if necessary.

But what has happened to common sense and good project management practice since then? “Plan” seems to have become a four-letter word. I’ve worked for a debt funded company where the owner’s mantra was “I wanted it yesterday”. That company was bankrupt within a year. I speak with companies who are developing without planning and simply calling it “rapid application development”. Like “The Apprentice”, their project managers just “chase everyone around” on a daily basis. Then there are others that start 20 different projects with the resources to do a far smaller number well. Client satisfaction suffers from broken promises and lower quality.

It might be overly bold to say I never managed a project with lots of good planning that didn’t come in on time and on budget, but the record seems to speak for itself. So next time you are about to start a project, make sure you will be allowed to use the p-l-a-n word!

“PLAN” is not a Four-Letter Word (Part I)

Back in the early 80s when corporations like IBM and Univac were mainframe giants, it took the typical systems team 3-5 years to produce a new compiler. It was during that time I took on a project to finish where some R&D; left off. The goal: produce a compiler, assembler, and linkage editor for a family of computers in use in the world’s largest private computer network. This was critical because the only tool in existence was a non-relocatable assembler (a throwback to the 60s). Development builds of code were running for more than eight hours and productivity was low. Introducing the notion of relocatable code would drop the time to minutes, allowing the development team to be more productive. More productivity would allow faster development of key network-related products and services.

The R&D; phase had obtained the portable Pascal-P4 compiler and implemented it on a lab mainframe. With this proof of concept out of the way (elapsed time around four-to-six months), the real work could begin. The project tasks then included developing a code generator for the new computer family, a relocatable assembler, a linkage editor, and some supporting tools (macro generator, cross reference listing tool, etc.).

Planning for the project took three months. We felt this was a reasonable time to dedicate due to the perceived magnitude of the effort by industry standards. During planning we kicked around different approaches, ran some estimates, but more importantly, developed an approach. Checking around with the 4,000 employees in the company, we found another project had developed a linkage editor that was close to what we needed — the input and output formats were different, but we could salvage some of the processing code. We also recognized the key to efficient development was to define the object file format necessary for the assembler, code generator, and linkage editor to communicate. By the end of the third month we defined that format and were ready to go.

One team member developed the assembler, one team member developed the code generator, and a third modified the linkage editor. Since the common file format was decided, it was easy for each team member to work independently. Two additional team members worked on the supporting tools and some miscellaneous routines to help out the three key developers. The result: by month nine we were ready to test the system with live code. Just a little over a year total, the system was done and all the communications computers were running using the new code. The users loved the result!

Now you would think that with software of this magnitude there would also be plenty of bugs. Not so, since during planning we identified the need for careful unit and integration testing. In fact, only five bugs were uncovered during the first six months of operations and none after that. About a year later we were asked to add another small feature. The system was productively in use for more than a dozen years. By then I was moving on to another company. I took a look at the execution counter associated with the file out of curiosity. The counter had actually rolled over and was sitting at over a million. We never would have achieved the completion of the project in one year and with high quality without that initial three months of planning.

Next week, in Part II, we’ll move forward a decade and see how good planning quickly made up for a mistake in planning.

Projects by “The Skin of Our Teeth”

Thornton Wilder called it “the most ambitious project I have ever approached.” His play, The Skin of Our Teeth, is an allegory of the cosmic life-cycle of mankind. It asserts that we are always close to extinction due to natural disasters and our inability to learn from past mistakes. Our history is not linear, but cyclical. At the end of each cycle, we somehow manage to always rebuild and move forward. We pick ourselves up, dust ourselves off, and try again. This cycle of life has always fascinated me.

After over 25 years of participating in, leading, and observing projects, I can assert this same cycle exists in the world of projects. Projects used to end in “post mortems” — today the more politically correct and sensitive term is “lessons learned”. Or more like “lessons not learned”, because I have seen projects repeat some of the same mistakes over and over again. And like Wilder’s family, the Antrobuses, the project manager and participants pick themselves up, dust off, and try again.

This blog is dedicated to lessons learned, lessons not learned, and generally interesting stories of project management that both educate and amuse. Each week I’ll post one story from a “project notebook”. The intent isn’t to name names or embarass, so any lesson learned without a positive outcome won’t name the parties involved. By covering this type of material, we can all hopefully avoid those continued mistakes that lead to our undoing. Why keep doing the things that lead to our failure or downfall?

I’d also like to invite you, my readers, to submit lessons learned for me to write about. Or perhaps you just have a question about project management I can answer for you. Just drop me a line at

In the meantime, I wish you all successful projects!