August 18, 2008 - Stand up and act like a... PM?

For the past few weekends I have been pulling together training material to cover Project Initiation, Tracking and Reporting for HP’s Project and Program Management tool (PPM). Not the most inventive of names but it seems to be a fairly robust system that integrates Financial and Project Management at the corporate level with add-ins for QA and other project pieces.

For that reason all of my creativity has been sapped and I have been unable to blog. However, during last week’s PMI Orange County dinner meeting we had an interesting speaker. Listening to Lee R. Lambert, PMP (http://www.lambertconsultinggroup.com) was like getting a slap in the face to wake you up.

He began by asking how many people had the job title “Project Manager” and then gave us the stunning news that we weren’t. By PMI’s definition a project manager has the right and responsibility to make decisions. Very few of us actually make decisions. We supply timely information, analysis and recommendations for people that do. By PMI’s definition that makes us Project Coordinators or Project Expeditors.

Our responsibility then is to present clear truth, backed by evidence with solid analysis and delivered in a timely manner. Over the next couple of weeks I plan to revisit the basics of how to obtain that information. Far too often we fall under the hypnosis of management’s instructions to add scope, reduce costs and get it done sooner with fewer resources.

We say “oh, well” and back down with half hearted pleas for sanity to reign…but it doesn’t. Then we complain the entire life of the project, pushing the team beyond their limits and try to deliver something...anything…that resembles what was required impossibly soon.

As professional project managers we need the ability to say “Yes, we can do that and here is what it will take.” Then present a solid estimate, realistic timeline and honest cost for what they asked. State the case and let them make the decision.

So, tune in next time and we will get started.

May 19, 2008 – Purpose Driven Projects

Last Friday I had the privilege of speaking at PMI-San Diego’s annual Project Management conference. There was a great turnout and several excellent key note speakers.

Friday’s lunch time speaker was Karen McBride, NASA Mars Program Executive, speaking about the upcoming Mars landing of the Phoenix project (5/25/08). She recapped how they managed the risks of attempting to land an expensive and extremely heavy piece of machinery 48 Million miles from Earth. The landing experience takes 7 minutes. At the speed of light, communications to and from the Mars Lander takes 15 minutes. Their mission is to put down at the pole and take samples of the ice and soil for 2 purposes:

1. To study the history of water in the Martian arctic and
2. Search for evidence of a habitable zone and assess the biological potential of the ice-soil boundary.

She was quick to remind us that they are not looking for life on Mars, just the potential for life.

The last speaker of the conference was Red Hat founder, Bob Young, whose latest endeavor is LuLu, the online self-publishing company. The purpose of the company is to eliminate traditional entry barriers to publishing and enable content creators and owners to be heard.

What is your project’s purpose? You can’t motivate your team to quality and getting to market solely on making the company more money. Understand the business purpose of the project and then translate that to how it will impact your customers.

Several years ago I heard a Project Management in an insurance company say their project could save lives. At first I thought it was a stretch, but after thinking it through I altered my perception a bit. If an error caused the company to deny necessary treatment coverage it could result in death.

Here are examples from some of my previous employers. For each there is a Reason and a Purpose. The reason simply states the scope of what we were doing. The purpose gives the effort a value.

American Greetings: Handheld Inventory Applications.
Reason – Accurately record returns and stock on shelves.
Purpose – Enabling the timely restock of cards to supply just the right thoughts, words and emotions to cheer a patient, brighten a day, thank a mom and encourage a child.

KeyBank: Customer Marketing Database.
Reason – Store customer information to identify additional sales opportunities.
Purpose – Proactively offering cost savings and financial opportunities for customers to enhance their lives by funding their dreams of education, home ownership and a better life.

Marymount Hospital: Y2K Application Testiong.
Reason – Ensure the applications would work successfully at the turn of the calendar.
Purpose – Ensure the functionality and security of patient treatment and information systems, without which the health and life of individuals may be at risk.

These are just three examples, but you can see the difference it makes to think through why the project was initiated. I can’t get too excited about a telemarketing database but a database of people with dreams to be funded I can promote.

Sept 24, 2007 – Starting Over

I survived the first week at my new job. Starting over can be exciting and a bit scary. Having survived nearly 15 years in the consulting industry, I am no stranger to rebooting my work experience. Actually, I even wrote an article for Computerworld about the topic (The New Guy's Guide to Building Trust).

Upon reviewing the list of 10 steps in the article, I think I’m off to a good start. I issued meeting minutes, started identifying preconceptions and even created an informative status report. With this new adventure I have discovered a couple of other steps to add to the newbie list.

Don’t Burn Bridges. It truly is a small world. I have run into several people from previous workplaces that have either worked with me or with someone who knows me. Fortunately I can work with almost anyone and know enough not to make enemies. Had I been a jerk to any of these people I would be paying for it now.

Don’t Jump the Gun. Like a runner, you need to be careful to not leave the starting block before the pistol is fired. Within the first day or so at a new client I began introducing myself to the extended team as the project manager. It soon became apparent that there were already two project managers on the effort and neither one of them knew I was coming. That was just a little awkward. Check with your management to make sure the announcement has been made before you step on anyone’s toes.

Know the Currents. On a camping trip to Martha’s Vineyard as a teenager we visited a beach with a riptide, a dangerous current that runs parallel to the beach. As you swim, you may think you are heading straight out from shore when in reality the current has pushed you 100 yards away. The best example of this in business came from an advertisement friend of mine.

While working a deal at a new client, one of the female executives asked if his company had done the ads for product X. In fact they had actually won awards for those ads and proudly said so. The executive said, “Those are the most sexist, degrading ads I have seen and there is no way we will be doing business with the company that created them.”

Deliver Value Quickly. On your first day start thinking about your status report. What are you going to put on it at the end of the week? Whoever hired you took a chance. They will be looking to see how soon you can be productive and contributing to the team. Identify some things you can accomplish during the first week to show an early personal Return on Investment. One of the new PMO objectives is to create project development standards and templates. I was able to report deliver of several draft templates on Friday’s status.

It may seem daunting to start over again, but soon those feelings will disappear as you pick up your new challenge.

June 19, 2007 - Where's the Finish Line?

One summer at camp we had a big foot race. It went from the archery range down to the beach and up a steep trail before ending on the main lawn. Knowing the finish was at the top of the hill I sprinted and was in first place coming off the trail. Having reached the summit I fell to the ground, glad to be done. Looking up I saw the finish line another 50 feet in front of me. Needless to say, I didn’t finish anywhere near first.

Fewer things are more frustrating than getting to the end and finding the finish line isn’t where you thought it was. As a project manager, if you don’t reach the goal it can result in having to seek employment elsewhere. To finish strong you need to know who is holding the tape at the end of the race. Usually we think of the project sponsor and forget others like the corporate architects, security, Sarbanes-Oxley (SOX) auditors and the project office. Since these groups can bring your project to a halt it is important to seek them out up front. It puts a new twist on the old saying “it isn’t what you know, it’s who you know.”

Architecture Committee. My project was going quite well. We were cloning an existing concept and the company stood to make a bunch of money selling the new product. You can imagine my surprise when I presented the project to the Architecture Committee prior to implementation and they said it didn’t meet the new technology direction. It didn’t matter that the requirements were never published, I just should have known.

Take the time to present your project’s concept to the architecture group early on. In addition to keeping you from going down the wrong path they can suggest improvements and point out design flaws.

Head of Security. Security is a thankless job. Protect the company for years but have one little laptop disappear or a couple thousand account numbers go missing and everyone is breathing down your neck. It is no wonder they say “NO” so often. Get them to help you design the system security in right from the Business Requirements phase. Too often we try to tack it on at the end and it doesn’t meet company standards.

Security funds are a great place to find additional funding for your projects, too. When the safety of the company is at risk money can be found. If there is an aspect to your project that enhances the security of the company you may be able to utilize a separate budget.

SOX Auditors. Auditors are generally avoided at all costs. Rather than hiding anxiously in your cube, go introduce yourself. Find out what the latest killer audit questions are and make sure your project is covered. Understand the rules and then consult with them before deviating from them. They may be able to help you find the path of least resistance to compliance. If you really want to blow their minds, ask them to perform a review of your project early on. This gives you a first hand look at what they are looking for and allows you to start off on track.

Project Office. The Project Office is the compliance police for development and management policies. Their directives may come from either the Program Management Office in charge of the enterprise or the Project Management Office set up for a specific endeavor. Like the SOX Auditors, they know the standards and can either be your source of information or source of pain. Many of them were project managers before they turned to the dark side and may be able to mentor you through the processes.

Starting off right with these people will allow your project to get the finish line without collapsing 50 feet from the end.

March 8, 2007 – Project Definition Trio

[NOTE: If you have not taken the opportunity, please register in the Guest Book to receive updates from the Cutting's Edge.]

Project definition is a tricky part of the project. If your environment is like most, you need to nail down the scope, the responsibilities and the approach as quickly as possible because the team has already started working. Given the limited time it may sound counterproductive but ideally you should create the preliminary list of risks and the project schedule at the same time.

As the image above illustrates, the Project Plan* (Scope, Management Plans, etc.), Schedule and Risks feed off each other as they are created. As the Scope Statement is defined and activities are defined they are added to the schedule. When an item is determined to be someone else’s responsibility there is a risk that it won’t be done.

While developing the Work Breakdown Structure (WBS) and Project Schedule you will uncover activities and perhaps deliverables that need to be added to the scope. Thinking through the implications of the tasks involved may trigger a thought for the Quality Plan or identify a new role to add to the Human Resource Management Plan. Risks are a natural result of drilling into the details.

Identifying Risks may expose the need for additional communication channels, tasks in the schedule or clarifications on the scope.

Working these three tools together will set your project on the right track from the beginning.

* Per PMI definition the Project Plan includes the Scope Statement, Risk Management Plan, Quality Plan, etc. The Project Plan could also be replaced with the Statement of Work (SOW).