January 1, 2009 – Going Covert, Part 1

Day 1 – It should have been an easy operation: go in, implement the update and get out. But it was anything but easy. It led to the Incident. Years from now I’m sure the Resource remaining with the Company may laugh about it, but this week the PMO was hit hard. The Head was chopped…gone. They pulled rank, brought her a box to go with the termination speech and brought in a Yes Man.

It may have been better if the whole unit had been pulled out. At least then we could land somewhere else and possibly do some good.

And this was supposed to be the year everything went right.

Day 2 – Made it to Friday without suffering the fate of the Head. I’ll regroup over the weekend and start fresh on Monday.

Day 5 – Overheard joking in the Development quadrant this morning. Someone said the Head had it coming. Overstepped her bounds and tried to call the Management to task for not following the Processes. IT’S A LIE! They were waiting for her to fail. Then they were all over her like flies on road kill. Stupid thing is we tried to warn her, but she didn’t see it coming.

Now the shuffle starts. I’ve been demoted from the PMO and reassigned to the Project Management squad. I knew too much to stay in the PMO but not enough to get rid of me completely. The patsies they are putting into the PMO certainly won’t push too hard or ask the wrong questions.

I’m ok for now. Gotta keep my head down, do the Job. It’s been a while since I had a full time PM roll, but I’m sure it will come back quickly.

Day 6 – Looks like I’m heading to the front lines: high profile, troubled project in the heat of battle. I suspect when he handed me the Binder, Management wanted me to think the smirk on his face was congratulatory. It wasn’t. This is a win-win for him. If by chance I survive and win the battle, the Company profits. If I fail, Management has a ready made reason to push me out. It would probably make him happy if I pulled the trigger on my own.

Day 8 – Been looking through the Binder. The previous PM didn’t do much. We’re supposed to be in Design, but there isn’t any evidence that the Requirements are complete. The Schedule looks like someone took the template and blew a big hole in it before throwing names against it like rotten vegetables at that house down on 3rd street. Not pretty.

Based on the Charter…which was never approved…we have a deadline. No real objective or clear direction. Just a deadline.

I’m assuming the previous Project Manager won the lottery…or got another job. Haven’t even heard what his name was.

Did meet the Team, though. Some of them seem pretty sharp.

Day 9 – It’s Friday again. With a long weekend of Planning ahead of me I suspect I won’t get much sleep. Entering the sleep-depravation phase. I wonder how long before the water-boarding starts.

I made the connection today. This is the project the PMO wasn’t allowed to review. It was stamped “Critical” and encouraged to “not let the Processes get in the way of progress.” Looks like it lived up to its calling because it did go critical…nearly nuclear.

And now it’s all mine.

Jump to Going Covert Part 2.

NOTE: On January 12, Computerworld published an article I wrote entitled Covert PMO. This blog entry 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.

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.

April 16, 2007 – Audit Failures

I have a friend who used to work for the Internal Revenue Service (IRS) as a tax collector for the United States. When this agent performed an audit he expected you to be honest and work with him to determine what was owed. He had the authority to make your life miserable if you chose to mess around. After trying unsuccessfully on one case to work through issues with an individual the agent showed up at the company before 6:00 AM with padlocks and chains to impound all of the vehicles. In concert with this move he froze all financial assets as soon as the banks opened.

On the flip side, he was working with a woman whose husband had run up bills, lied on his income tax and then left her. She met with him to work out some payment arrangement. After reviewing the case he determined that there was no way she would be able to repay what was owed so he wrote the whole thing off. She walked away free and clear.

When I was a project auditor I didn’t have that level of authority. The audits I performed were focused on making sure the projects and teams were following the procedures and that the company was not at risk. It was great to audit the managers who honestly worked with me to understand the project even when there were problems.

To keep from having and causing problems, review the following audit failures that should be avoided.

Lacking Definition. The most important part of a project is the definition. Without clearly defined objectives, deliverables and ground rules you won’t know where you are going, when you are done or how you will get there.

Make sure your defining documents clearly identify the project scope. Problems are usually found in this area just by speaking with the project manager. I review the Statement of Work and then start asking innocent questions like “what is your team currently working on?” When he starts talking about things that aren’t in the SOW I know there’s a problem.

Review your project’s defining documents and make sure you are doing what you said you would and nothing more.

Missed Milestones. Milestones are checkpoints. There isn’t anything magical about them. But if an audit discovers several of them have been missed then the project is at risk of failure to deliver. Don’t try to hide the fact that you are behind. Be the one to point it out. Then outline what you are doing to pull the project back on schedule. This may include bringing in additional resources, issuing change requests to adjust the dates or lowering the scope to meet the deadlines.

The audit reads a lot better if it shows you understand the issues and have a plan to correct the course. It sounds a lot better than “he hasn’t got a clue that the project is in jeopardy.”

Unacceptable Approvals. A good auditor looks deeper than file names to determine if an artifact is acceptable. There were multiple times that I looked at approval emails to discover they were worthless. There are 4 areas that approvals fail:
1. The person approving isn’t authorized. Check the names against the approval matrix or other guiding documents (i.e. SOX) for the right signoff levels.
2. The document doesn’t say what it approves. When issuing an email requesting deliverable approval make sure it spells out exactly what is being approved. Just saying “I approve the document we looked at yesterday” isn’t going to cut it.
3. Using voting buttons. At first it looks like a good idea: send an email and let them pick either Approve or Reject. The problem is the email content is lost on the return and all you get is the word “approve” or “reject.” It doesn’t say what they approved and it relies completely on the file name.
4. Doesn’t actually say “Approved.” I have seen questionable approvals that say “looks good” or “ok.” Not the best, but at least it indicates an affirmative response. The tough ones are the conditional approvals. If they say, “I approve this if Joe approves it” you better have Joe’s approval evidence, too. Or if it says, “I approve if you change these 3 things.” You will need to have it re-approved by everyone after those 3 things are modified.

Take a look at what you are presenting for your audit and don’t try to hide anything. The real reason for performing them is to identify areas that need improvement and then focus the necessary help on solving the problems. Besides, it can’t be as painful as a tax audit.

January 29, 2007 – Managing the Thing: Project Definition Part 3

Most of the topics that I cover could fill full books and several classes. I barely touch the surface and hopefully point you in the right direction. Even in the brief way in which we are discussing Project Definition it has taken 3 different entries to complete. Today will cover Roles and Responsibilities, Milestones and Budget, and the Management Approach.

Roles and Responsibilities. This section identifies the roles of specific resources involved in the project and outlines their responsibilities. Major miscommunications and unmet expectations can be resolved simply by clearly setting responsibilities here. Build a table with the columns Role, Name and Responsibilities. It is important to identify a specific individual with each role. Also, the Responsibilities column, as with Out of Scope section, offers you the opportunity to state what you expect others to do. The example below is for the Business Team Leads but you should also identify the Sponsor, Overall Project Manager, other Team Leads, external vendors and other key roles.

Role
Business Team Leads

Name
Heather Morgan (Demand Planning)
Jillian Enaile (Supply)

Responsibilities
· Represent their business unit on the project.
· Provide project status to Overall Project Manager and upper management.
· Identify and assign appropriate individuals to participate in JAD sessions.
· Review and approve the Design document, UAT, and Final Approval.
· Coordinate all aspects of UAT for their business unit, including test plan and test scripts creation, execution, and signoffs.
· Etc.

Notice the use of verbs to describe what is expected. Imbedded in the Responsibilities is another clarification on the UAT ownership.

Milestones and Budget. This section, as the name implies, identifies the major milestones and deliverables with planned start and end dates and estimated cost in dollars, hours, or both. This needs to align with the Project Schedule. By developing the schedule and PDD together you can perform checks against each of them to keep them synchronized. If you identify a deliverable in the Approach section, it should correspond with a group of specific tasks in the schedule. Similarly, if you have activities identified in the Project Schedule you need to account for them in the SOW.

Management Approach. Depending on the maturity of your organization the size of the Management Approach section may vary. It outlines how each of the following areas will be handled and sets the expectations up front.
· Communication Management – identifies reports produced and meetings held (ex. Weekly Status Report and Weekly Status Meeting).
· Issue Management – shows expected level of issue documentation and resolution plans, giving a specific path for escalation.
· Risk Management – documents how risk identification and mitigation and how when contingency plans are necessary.
· Change Management – describes what constitutes a change, how to document it and the approval process.
· Acceptance Management – gives direction on how to approve or reject deliverables and timeframes for doing either.

If your organization has any or all of these management approaches defined, do not recreate them here. Reference them and document any deviations that your project will follow.

These six sections (Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach) form a basic Project Definition Document. Depending on your environment and project needs, the level of detail and legal jargon that is required will differ. The concept remains the same: Define The Thing that is to be delivered. Set the project expectations in writing and then obtain formal approval of it. As we will see in the entries to come, this document forms the basis for both change and approval.

January 26, 2007 – Managing the Thing: Project Definition Part 2

Without defining the project, The Thing will likely fail to get accomplished. It will consume more time than anticipated and accomplish less than expected while costing more than it should have. When the wide variety of documents are boiled down to their simplest form that basics that need to be communicated are the Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach.

Project Background. The background is meant to describe who requested The Thing, what it is, why they requested it, and how the team arrived at the current point. A successful background is short and correctly spells the name of the person that requested it.

Scope. The scope section documents exactly what the team is responsible for (In Scope) and, just as importantly, what it is not (Out of Scope). Items should be identified clearly. As an example, “Support of User Acceptance Testing” does not clearly set expectations. You may be thinking, “make sure the system is up, answer a few questions, and fix anything that fails.” What the Sponsor may read between the lines is, “create the test scripts, train the testers, and supply coffee and donuts.” A better scope statement might read:
Support User Acceptance Testing by ensuring that the system is available, refreshing test data, recording defects and tracking corrections, and facilitating daily UAT meetings.

The Out of Scope portion further refines the expectations by addressing items that a newbie to the project might otherwise assume were the team’s responsibility. Examples would include:

• Training testers on the use of the system is the responsibility of the Training Department.
• The UAT Test Scripts will be developed by the Business as directed by the Business Project Manager.
• Bring your own stinking coffee and donuts.
  

Well, maybe the last one shouldn’t be in the final document.

Approach. The approach outlines the Technical Environment, Development Life Cycle and Deliverables.

Technical Environment. Is this web development or COBOL, JAVA or Infomatica? Clarifying this up front will set everyone’s expectations. This is not a Technical Specification so give a high-level overview and refrain from details of how the parts interact and perform.

Development Life Cycle. What phases or process will be followed as the project unfolds? Will you do prototyping, execute a pilot, or use JAD sessions to drive out requirements? Briefly define what the involved parties can expect.

Deliverables. This is the real substance of this section. In some cases it may make sense to have a separate section for it. Deliverables are the building blocks for the project and serve as checkpoints to verify progress. The sum of all of the deliverables should constitute the whole project so it will be helpful to develop a Work Breakdown Structure (WBS) to identify the all.

Each deliverable should be listed with its name, description, acceptance criteria, and approval authority. Below is a good example of a deliverable statement.

Name
Statement of Work

Description
This document defines the project by identifying the Scope, Deliverables, and Roles and Responsibilities. It is an agreement between the involved parties and forms the basis for project expectations.

Acceptance Criteria
The document contains the following sections:
1. Background identifying the request and brief history.
2. Scope of the project.
3. Approach with Technical Environment, Development Life Cycle, and all Deliverables identified.
….
Each section clearly articulates the expectations of each stakeholder.

Approval Authority
Project Sponsor
Business Project Manager
IT Project Manager
Manage of Sales

A good way to present this information is in a table. Notice how in the Acceptance Criteria lists the specific sections we have discussed. As we will see in the Acceptance Management section, those criteria are what the approver should be verifying when deciding whether or not the deliverable is done.

In the next entry we will cover the remaining sections of the PDD.

January 25, 2007 – Managing the Thing: Project Definition Part 1

The first key piece to successfully delivering The Thing is defining the project. PMI identifies three major documents that are used to do this:
1. The Project Charter grants formal authority for the project.
2. The Project Scope Statement documents what work is to be accomplished and the deliverables that need to be produced.
3. The Project Management Plan documents how the work will be performed.

If you think that the Project Management Plan is the same as the project schedule you would fail the PMP exam. A full Plan includes sections or even separate documents that lay out how you will manage the Scope, Schedule, Cost, Quality, Staffing, Communications, Risks and Procurement.

If you work for a company that doesn’t have this level of maturity yet, I would suggest creating a condensed version and calling it the Project Definition Document (PDD). Think of your project as a big sandbox where everyone is trying to build a castle. You need to know the rules of the sandbox and what you are building. That is the purpose of the PDD. By agreeing up front what you want to accomplish and how you are going to accomplish it, the complete team (Sponsor down to the coders and testers) can shovel sand in the same direction. Once completed the PDD should be reviewed and approved by the key project stakeholders (i.e. Sponsor, Project Manager(s), Business Manager, etc.).

I worked at a company where defining the project in writing and getting it approved was not encouraged. The reason became apparent as additional items were added to the scope. Project managers struggling to create detailed PowerPoint presentations for the overall project status. It had to cover aspects of the project they had no control over and little visibility to. The PM was stuck doing it because there was no documented understanding of the division of responsibilities and no authority to delegate it.

Tomorrow we will begin to look at the six areas that should be included in the Project Definition Document: Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach.

January 24, 2007 – Managing to the Thing: Introduction

Several years ago I volunteered to participate in a massive PC cleanup effort after a company wide virus attack. At the time my project deliverables were behind schedule and the virus was putting me further behind. As a Project Manager, that is not a good feeling. It was less than a month after returned to project management from the Software Quality Assurance group and I could feel the pressure from both sides. In my mind the SQA group was saying, “Finally, someone who knows the processes and can show those Delivery people how to do things right!” Meanwhile my new Delivery co-workers were rooting, “All right! Now one of them is going to find out just how difficult it is to follow their processes!”

While I was checking and installing virus protection in multiple buildings with several floors that night I had plenty of time to think about the things I wasn’t getting done. My new day job was proving to be very tiring as I attempted to stay on top of the wave of activities. I was trying to juggle everything, rushing from meeting to meeting, jumping from task to task and not completing anything. The strain of the urgent had choked out the basic principle that I knew: You have to define it before you can accomplish it.

Central to successful project management is delivery of the end product, or The Thing. In order to do this effectively, three key pieces need to work together: the Project Definition*, Change Management, and Acceptance Management. Over the next several days I want to outline the main aspects of each of these and show how they form the basis for project success.

Why these three? The Project Definition, Change and Acceptance at their core are simply communication vehicles. When used together, these three:
· Define The Thing that is to be delivered,
· Allow The Thing to change,
· Let everyone agree that The Thing is completed.

Without communicating these three, projects would go on forever without satisfaction for anyone.

*Project Definition – The defining document(s) for the project. Consulting companies use the Statement of Work. Internally it may be a Charter or the Scope Statement together with the Project Management Plan.