May26, 2008 - Memorial Day

Take the time you would have spent reading this blog to honor those who have protected the innocent, preserved freedom and provided peace.

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.

May 12, 2008 – Stop Wasting My Time

My brother-in-law, Paul, tells a story about a boy, Theo, who wass afraid of clowns. The tale follows Theo’s life from childhood to teenager to young man through to his old age. At different stages in his life he attempts to survive a circus performance but always ends up fleeing, screaming hysterically, at the sight of the clown. He tries therapy, hypnosis and other extreme means to cure himself. Finally he joins a religious order of monks known for their fearlessness and sharp comebacks in the face of danger. In the final confrontation with the clown, Theo is being chased, stumbles and falls down. With the clown standing menacingly over him, Theo finally faces his fear and yells, “I don’t like you very much!”

Quite pointless, eh? Paul can drag this story out for at least 15 minutes, adding more details and deeper insights. When he finishes you feel cheated out of a large portion of your time.

As project managers, we need to make sure that what we are asked to do has purpose. The Systems Development Life Cycle is a great example of this. As part of the Project Management Office, I expect pushback from the people using the SDLC. The majority of the templates and processes come directly from the teams, but if they don’t make sense we need to get them changed. In order to be successful, everyone needs to get involved in the following ways.

Know What. Keep an eye out for PMO announcements telling you what has been added or changed. When you start a new project or phase, browse through the processes, templates, best practices and lessons learned to make sure you have the latest and greatest. The temptation is to modify what worked for the last project, but great improvements may have been made since then.

Understand Why. I’ve been guilty of playing the PMO blame card. Early in my PM career I would ask the team or client to complete something “because the PMO requires it.” A great example is the Risk Assessment. If you are just filling in risks because you have to, you are missing out on a project saving devise. Telling the client / business that you have to have one to pass an audit may get you off the hook immediately, but it shoots an arrow into your support team. Eventually the client / business will think all PMs blindly do whatever is dictated. They then loose faith in the whole organization.

Use Them. Put the process to the test. Processes and templates generally aren’t built to gaze longingly at. They make really lousy wall hangings and lawn ornaments. They are intended to be used. Besides, the best and most constructive complaints come from those that have tried to use them, not those that ignore them.

Provide Improvements. The goal is to use the group’s collective knowledge and learning to continuously refine and replace what exists today. The PMO will be among the first to admit that the best answers come from the line. Toyota’s manufacturing success has at its core the right and responsibility of assembly workers to suggest ways to make it work better.

The users of the processes are the real owners, not the PMO. If a piece is broken, get it fixed. If it doesn’t make sense, find out why it even exists. If no one knows why, get the PMO to drop it until someone screams for it back.

In the end, no one wants to waist your time with pointlessness. Well, except maybe my brother-in-law.

May 5, 2008 – Keeping Junk and Throwing Valuables

Value. It is a word that has come up several times over the last few weeks. My wife recently snagged me two Eisenhower dollar coins (1974 and 1978) she saw someone spending. We were also speaking to a realtor about possibly selling our house. Neither the coins nor my house were worth as much as I had hoped, but without knowing their value I might have given away something for nothing.

This can happen on your project. It starts with a promise made during a meeting or by one of your team members while gathering requirements. Then, as you start to estimate it and assign a cost, you realize that what seemed simple will break the budget. Here’s how to avoid the problem.

1. Scope Definition. Get it drawn up and agreed to. Whether you are using Use Cases Models or hand written napkins, spell out what you were asked to do and get it agreed to.



2. Scope Awareness. Publicize what is in and out of scope. Make sure your team understands the need to keep the design and development focused on what is agreed to and nothing else. Stress the same concept with the business, too.



3. Change Readiness. Create a way to change the scope: a change management process. Assure everyone that change is good and can result in a better finished product. Lay out the path an idea needs to follow to become a reality. Include what constitutes a change; estimating the effects on cost, time and resources; and who has to approve it.



4. Idea Promotion. Encourage your team and the business to identify changes, especially early in the requirements and design phases. Drawing out those ideas gives you an opportunity to deliver something of real value. Once they are identified run them through the change management process to determine if or when they will be included. Some ideas may be good enough to oust existing scope or extend the project. Others will hit the wish list and never see the light of day.



5. Effective Giving. Even if you are giving something away, determine and communicate the value of it. Adding another field to a display may not be significant, but one request can become twenty if the perception is that they are free.

Now you have the right people making the best decision while removing you from having to say "No!" all the time.

On the flip side, too often we hold on to things that have no real value. Garages quickly fill up with slightly broken electronics, old monitors, lamps missing shades and even partially bent golf clubs. When the garage is full people rent storage units at $150 or more per month to hide things they can’t part with. At those prices it doesn’t take too many years before the money spent could have purchased brand new replacements for the broken items.

Project secrets are not worth the price. I’ve had to pay before. On a project with clearly defined testing dates, one group continued to tell me they were on schedule. The Monday that testing was to begin we held a final go/no go meeting. They arrived to inform us that they had completed... their design. Construction was far from finished. If your dates are slipping, be the one to step up and identify it as a Risk. Do everything humanly possible to complete on time, but get the problem out in the open.

Unproductive resources cost too much. Sometimes we think that any resource is better than no resource. Compare your dead beat developer against that statement. Is he producing anything of value? Is she bringing the moral of the team down?

Check your value system. Are you throwing away valuables or holding on to junk?