January 24, 2010 – Driving me Crazy!

Having a GPS in the car drives me crazy. I do not operate well with directions that come one step at a time. It may be the Project Manager in me, but I want to see the big picture and know where I’m heading. Besides, at 65 miles an hour, I can’t judge “300 yards before taking the next left.” I’m not even sure if “Miss Voice” means her left or mine.

I realized this last week as I was traveling to a client site with our main sales person. She was driving and I was trying to navigate. We were attempting to go from Orange County, CA near Disney to the Pasadena area, home of the Rose Bowl Parade. The final destination was between the 60 and Interstate 10. I know how I would go and assumed the GPS would use the same route, straight up the 605.

Imagine my confusion when Miss Voice said, “In ½ mile, take exit to Interstate 5 North.” Before I could wrestle the screen to show the projected route, we had swerved onto the exit ramp to follow the directions. It was either that or face the dreaded “Recalculating…Recalculating” reprimand….or worse, the “Make a legal U-Turn” snide remark.

Through a comedy of errors, we managed to get back on track. We missed the 60, but found Interstate 10. Following Miss Voice’s advice, we passed the exit bearing the name of the street the client was on and took the next exit. I had a general sense of where we were heading by then and expected to head south and then east. Miss Voice, however, took us north and then west until we realized the ending address had changed.

I personally think Miss Voice was so disgusted with us that she was thinking, “Fine! If you don’t appreciate me, I’ll drive you to a back alley where you’ll get car jacked. They’ll strip this vehicle down and sell me to someone that can follow directions!”

Some project managers run their projects using a GPS. They punch a predefined address into their Charter and start driving. They fail to look far enough ahead to get into the right lane before missing the turn. Ultimately they allow the project direction to be altered without their knowledge, ending up somewhere else entirely. Even if they avoid a devastating collision, the sponsor usually ends up with car sickness.

Here are the top 10 ways to reach your destination without throwing your GPS out the window.

10. Lay out the full map. Understand where you are headed. You don’t need to know the turn by turn details, but you want to be able to sense when you are going in the wrong direction.

9. Verify your destination. Review the scope and requirements with your stakeholders and obtain their approval.

8. Keep an eye on the gas gauge. Budget, time and resources have to be planned and used appropriately.

7. Listen to Miss Voice. If you have laid out your plan and schedule accurately, follow them.

6. Track your progress. A GPS uses your current speed and position to calculate arrival time. Analyze your progress and spend rate to make sure you are on schedule and budget.

5. Look for landmarks. Set milestones in your schedule. Use them to validate your direction with stakeholders and gauge your timing.

4. Check the map frequently. Verify progress against the scope and requirements in order to stay on course.

3. Recalculate. As the project progresses, more information is available. It may be refined requirements, new technology, resource changes or other factors that impact the end product. Use formal change processes to re-evaluate and alter the direction and cost.

2. Check the traffic. Analyze the risks in your project. If it appears there is traffic ahead, take action to avoid it.

1. You have arrived at your destination. Recognize when you have completed the project’s scope. Don’t allow random course changes to be slammed in at the end of the project. These tend to be less structured, lack adequate testing and overrun the budget.

We arrived in one piece, but it is a good thing we left early.

September 15, 2008 – Back to the Basic: Competing Project Constraints

Following last week’s edition, one of my project management co-conspirators dropped me a note informing me that the triple constraint (see The Troubling Triangle) is officially dead. The upcoming release of the PMBOK Guide 4th edition has killed it.

In lieu of the binding, restricting, tri-legged barer of logic, PMI has opted for “Competing Project Constraints.” The new PMBOK includes Scope, Quality, Schedule, Budget, Resources and Risk as a representative list of the numerous constraints that a Project Manager faces.

Without reading the text directly I can not make a fully informed decision about the wisdom of creating a multisided polygon constraint. For one thing it doesn’t have quite the same ring as a triangle (I’m sure there’s a bad musical percussion joke in there somewhere). However, here are my initial thoughts.

1. I whole heartedly agree that Project Managers have more to worry about than Scope, Schedule and Budget. I don’t think there was ever any real misunderstanding of that fact.
2. By removing the Triple Constraint and accompanying triangular image, we loose the visual used to explain the impact of changing one of the legs.
3. Of the examples given as other constraints, Quality is easily represented by the size of the area encompassed by the leg segments of the triangle. Although not originally part of the image, it fits.
4. Another, Resources is generally a factor of the cost (or budget) of the project. If money is no object you can get better and more resources. The New York Yankees and Real Madrid sports franchises, with their ability to buy talent, come to mind. Generally speaking, projects run out of time or money before they experience a lack in available resources.
5. For the other, Risks, I need more explanation for the use of the term “constraint.” If the term means “factors that may adversely impact your project” then I would agree.

Perhaps that is the basis of the change in the terms used. PMI may believe that it is doing us a favor by widening the term to show the myriad of chainsaws and knives we need to keep juggling. My fear is that it opens the door for management to defy the simple logic that if they increase scope, schedule or budget, one or both of the other legs have to adjust.

If we are expanding the number of constraints, maybe we just need a different image:
Picket Fence – Each of the slats represents a constraint holding the project level.
Suspension Bridge – All of the cables adjusted to keep the path safe for passage.
Multi-legged Table – Legs adjusting together to support the project.

Whatever the symbol, I will miss the triangle.

September 8, 2008 – Back to the Basic: The Troubling Triangle

In our quest to return to the basic of project management we have already tackled the stakeholders. Next we take on the triple constraint in the form of a triangle. The concept of a triangle to represent the Scope, Schedule and Cost of a project is actually quite ingenious. Adding more scope dictates an increase in the schedule, cost or both. Reducing the cost or timeline for the project requires less scope. Each part is dependent on the other two.

The trouble is that management thinks of these three items as completely independent of each other; like 3 line segments lying as distinctly separated as the bones in my daughter’s x-ray from last week’s edition.

Scope. The scope of your project includes the full extent of what is agreed to, both verbally and in writing. In reality scope is never fully defined until all of the requirements are vetted, but from the minute you take ownership it is our responsibility is to ferret out promises and commitments made. This is especially evident in the consulting world. Account Representatives (aka Salesmen) are notorious for making promises and not letting the project manager in on the secret. Take your list of Stakeholders and find out their expectations.

The resulting wish list is not your scope. Like pruning a Bonsai tree you need to cut that back to something you can realistically deliver in the timeframe and cost provided. Remember, you can’t set one line segment of your triangle without impacting the other two.

Cost. Auto salesmen get a bad rep, justifiably so in many cases. But you can take a page out of their play book. When asked how much it will cost to deliver the scope, ask how much they are looking to spend. If they only have enough for a used, beat up Yugo, don’t try to sell them a Lamborghini.

When giving an estimate, put it in terms of what will be delivered. Never give a quote without documenting your assumptions; the “here’s what I was thinking…” piece. Placing the cost into context forces the discussion of scope.

Schedule. Timing is always an issue. On one project our directive was to go live in August. Backing up from that date gave us July for Testing and Implementation, June for Development, May for Design and April for Requirements. It would be tight, but do-able. At the end of May “in production” was clarified to mean the day after 4 weeks of parallel testing in the production environment. Changing the move to production, even if we weren’t “live” would have been impossible without changing the scope and adding more resources (increasing the cost).

Find out what the date is and the significance of it. If it is a hard date you have already set one of the legs in the triangle.

As you establish the three legs of your triangle, it is management’s job to stretch the scope side while reducing the length of the cost and schedule sides. How can you effectively push back without a career shortening screaming match?

Go gourmet on them. Most CIOs, VPs and Senior Managers enjoy their share of fine food. The higher end restaurants produce amazing dinners that take longer to serve and cost quite a bit more than your local fast food joint. Even our cafeteria at work has a sign that says, “Good food takes time. Thank you for your patience.”

Build a reputation on speaking straight and not padding estimates. It is your responsibility to present the facts, back them up with evidence and state your case clearly. It is their job to make decisions.

August 4, 2008 - Failure to Manage

Our house recently went through some medium size renovations. It began with replacing the hot water heater with a tankless model. During the installation the plumber explained that our galvanized pipes were badly corroded. In some places the rusty build up was seeping through to the outside of the pipe and in other it was clogging the water flow.

Scope change #1: add $5500 to re-pipe the house using copper.

Since they were taking the shower wall apart we opted to rip it out and tile the entire bathroom.

Scope change #2: another $3500 + materials.

It finished with the “Since We’re Here” special: I was in the process of digging up my front lawn to install sprinklers and they offered to run the pipes.

Scope change #3: $800 + materials. Good thing we recently refinanced!

Instead of going with a company, I hired a couple of independent contractors. They did a great job with the work, but there was a lack of basic project management from the beginning. That failure to manage caused disappointment, minor frustration and more work for me:

• The hot water heater went in smoothly, but the promise to run the wire and mount the thermostat went unfulfilled.
• The bathroom and shower look terrific, but when they said they could raise the shower head above 6 feet, I thought they were actually going to do it.
• Refitting the house with copper was a success except for a minor design change. They originally planned to come up through the floor instead of the wall. Evidently they changed their minds and now I have big holes in my walls were the pipes come out. Evidently they don’t do drywall so now I have to.
• Removing the old shower and other trash evidently wasn’t in the plan, either.

Technically, I got more than I paid for. They charged quite a bit less than they could have, did a solid job and the bathroom alone increased our house value by more than the cost of the whole project. But if I had it to do over again I would have applied more project management myself by:

• Defining the Scope. There were several items I assumed were in scope that I ended up doing: wiring an outdoor electrical box; removing old pipes from under the house; disposing of garbage; and filling the holes in the walls to name a few. I’m sure it would have increased the cost of the project but at least communicating it up front would have prepared me for it.
• Identifying all requirements. As the “sponsor” this one was my fault. When they replaced the main water line to the house they dug under the sidewalk to connect it at the meter. Had I told them I was looking to add a sprinkler system we could have used that same hole and saved some digging.
• Documenting Changes. A potential problem was averted by writing down the prices quoted to me and verifying my understanding.
• Establishing Timelines. It seemed to take forever to complete all the projects. There were scheduling conflicts on our side and theirs that stretched the duration.
• Tracking Commitments. Every time I take a shower I will likely think, “I should have reminded him to raise that pipe.” As for the thermostat, I finally hung that to the wall today.
• Customer Satisfaction. The ultimate item a project manager would have brought to the mix was a better customer experience. Small details matter, like placing a runner on the floor to minimize tracking dirt across the floor; letting us know arrive and departure times; and setting expectations.

With the help of a project manager, I have no doubt these guys could double their work load and obtain great referrals every time. Then again, I’m probably biased.

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 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?

April 7, 2008 – Scope Creep in Tent City

The city of Ontario, California had a problem: a large number of homeless people. To address this, the council decided to create “Tent City” using the land around the airport. They supplied tents, water and toilets. Government agencies supplied other goods and services. Everyone felt good about themselves and life was looking grand.

Unfortunately, this solution just created a bigger problem: more homeless people. The total number of residents quickly rose to over 400. People from out of state were showing up to take advantage of the generosity. With the situation officially out of control, the city gave notice to everyone and brought in bulldozers to level the area. The new plan is to place a fence around the area and issue 90 day registration tickets to set a limit of 170 residents.

I see three warnings for project managers from this well intentioned public image problem.

First, even the best intentioned additions to your project need to be planned, estimated and agreed to. We all want to exceed our client’s expectations. The temptation is strong to add things to the project and eat the cost. After all, it’s a simple change and we are a bit ahead of schedule anyway.

The problem is that little things add up. Even if you are giving it away, use a change management process to assess and communicate the impact to the project in time, cost, resources, etc. Once the value is understood you can give it away. If you hide the value it will be appear as if it was in scope already and not really an addition. It becomes just one more homeless person entering Tent City.

Second, consider the risks involved in the actions you take. Tent City seemed like a good idea at the time but it exploded into something ugly. The council thought far enough in advance to provide facilities and fresh water but failed to mitigate the influx of non-Ontario residents. Get your team to perform a Risk Assessment early and often. You should set aside time as a team to brainstorm potential risks minimally monthly and whenever something significant changes (see topic: Risky Business).

Finally, sometimes you have to admit your mistake and bring in the bulldozers. Had the city of Ontario continued to ignore the problem eventually someone would have died. In addition to the tragedy of loosing a human life, it would likely result in lawsuits and even more bad press. If additions to your project are bringing down the property value, it may be time to plow it under and put a fence up to control the scope.

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).

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 12, 2007 – How to Really Fix a Failing Project

You project is in trouble. You know it. Your team knows it. But somehow you have been able to keep it from your management. You need a quick fix. But there aren’t any. What can be done to get back on track? Since yesterday's ideas didn't help, here are some suggestions that might point you in the right direction.

Refocus the Scope. Begin by going back to the defining documents including your Charter, Statement of Work and approved Change Requests. Figure out what you have committed to accomplish. Conversely, document all of the things that were unofficially added to the project. What you are trying to obtain is a clear understanding of the commitments and the expectations of others. With these lists in hand, meet with the project sponsor (or similar key stakeholders) and agree on what should be part of the current effort.

Draw up the Schedule. Based on the remaining effort and current resources, recalculate the schedule. Forget the deadlines placed on the project at this point. Given the amount of work and people available, determine a realistic timeframe to complete the revised scope.

Determine the Cost. Find out what the budget is and how much has already been spent. After calculating the difference between the two amounts (hopefully it isn’t negative) compare it to what remains to be done. Based on your revised schedule run the numbers to determine a reasonable Estimate to Complete.

Review Lessons Learned. Meet with the team and other stakeholders to determine where the project went wrong. Develop a list of steps to take in order to avoid the same thing happening next time.

Develop Alternatives. Using the scope, schedule and cost information review the options available. Based on the Project Triangle* that pits scope, time and cost against each other, consider the impact of each of your options on those factors. Will your plan include adding more resources? Extending the date? Reducing the scope? Although “Phase 2” is always the answer most project jokes, it can be a solid alternative. In some extreme cases the right decision will be to cancel the project. Although an unpopular choice, some projects need to be dropped. Reduce the testing phase is usually the popular option, but I don’t suggest it.

Admit Reality. Once you have drawn up a couple of viable alternatives, present them to the management team. Begin with a healthy dose of reality. Management does not like going through the failed project dance. If they have to do it twice things get ugly. Lay out the situation, preferably without playing the blame game. Then present your plans for getting back on track. Let them help you talk through the options and make suggestions.
Start Fresh. Issue a revised scope statement, obtain the funding, reset the schedule and obtain appropriate approvals. You have been given a new lease on your project. Work the plan and make sure to incorporate the Lessons Learned from your first attempt.

* Project Triangle: Picture a triangle where each of the three sides represents Scope (or functionality), Time and Cost. If you change one side it impacts the other two. Reducing the size of the Scope side will allow you to reduce the Time and/or Cost side. It is the same for the other sides as well. This is a standard and effective way to communicate the struggle between the three.

December 19, 2006 - Scope Creep Part 9

There are times when the change requested is able to be completed without altering the schedule or budget. It wasn’t part of the original scope, but is it necessary to create a Change Request for it? Yes.

Giving Gifts. The temptation to add to the scope of your project is hard to resist. Part of becoming a valued employee is going above and beyond to deliver more for less. Naturally you want your client to be pleased. But you should still follow the process.

Create a Change Request outlining what the cost would be. When it is presented you can “give” it to them. Show them that you are able to absorb the extra cost and time without impacting the project and you are doing it with no additional charge.

There are 3 benefits to doing this.

1. It continues the Change Management Process. The change still needs to be reviewed and approved to ensure it is necessary and wanted. Simply adding things to the scope may muddy the final product.

2. People understand that changes have impact. Don’t be tempted to take on additional items at the beginning of the project without following the process because the project is ahead of schedule and budget. If you do you are setting an expectation that they can add anything they want at any time. Later on in the project when the budget and schedule get tight they are going to ask for something and you will have to say no. It’s probably a bad analogy but it would be like letting your puppy jump up on your couch until she is a year old and then trying to stop her. You’ll get those big puppy dog eyes looking at you and cave in. Both your budget and couch end up trashed.

3. You get credit for it. If you simply add the scope it appears to have had no value or was originally part of the project. A gift of no value or, worse, one that isn’t perceived as a gift is never appreciated. You can build a partnership based on the added value.

With Christmas fast approaching an entry on giving gifts is probably a great one to stop on. I will be on vacation until January 2 and may not get a chance to write until then.
Have a Merry Christmas.

December 18, 2006 - Scope Creep Part 8

Since we brought up the subject of budget, this is probably a good time to discuss how to handle the project financials in relationship to change management.

Change Control Budget. The biggest hassle with managing change is determining how to pay for it. A change control budget is a great way to deal with that problem. This is a fund, separate from the project, specifically earmarked for changes. The amount to seed the fund with depends on the amount of perceived project risk but is generally 15-20% of the original budget.

These funds are not part of the project until they are allocated. The purse strings are held by the Sponsor or a Change Control Board. When a change is initiated, the request is documented and presented to them for review. Their responsibility is to determine if the money should be allocated. At the end of the project, any remaining amount is returned to the organization’s budget. The process can be implemented at either the project or Program Management Office level and ensures that changes are funded. It also deters excess spending.

Whether it is moving the location of a door or adding functionality to a system, the owner is going to weigh the options before allocating the money from their checkbook. Frivolous additions tend to be passed over, allowing the project team to focus on delivering the project on time and in budget.

December 14, 2006 - Scope Creep Part 6

Theoretically, if you are tracking your scope while comparing the project direction against the defining documents it should be obvious when something changes. That isn’t always the case.

Identifying Changes. Sometimes it is easy. The Business or Sponsor stops you in the hallway and says, “I think this is a change to the scope, but can we do….” Other times it hinges on a miscommunication caused by ambiguous wording. So how do you know when a change happens? To help us identify change, we will look at 6 types of changes: Initiated, Stuff Happened, See I Told You, Missed That, Miscalculated and Not What We Agreed.

Initiated Changes are the simple ones. The end user comes to the status meeting and says they have a new requirement. Everyone knows it is a change and we move on.

Stuff Happened Changes pop up when something unforeseen knocks you off schedule. Depending on the type of relationship, the “stuff” might be seen as a candidate for change or not. A natural disaster might be written into a construction contract but probably not into an IT agreement. A power outage takes down the system during implementation delaying it by a day. Whose responsibility is it? Who eats the cost? Can the date be moved? Once you establish that something changed you can begin to get answers to those questions.

See I Told You Changes are when Risks become Issues. If you missed the discussion on Risks you may want to jump back in time (November 14, 2006) and catch up. Even though you work hard to identify and mitigate risks, sometimes they become issues and a change request is required to deal with them.

Missed That Changes involve requirements that didn’t make it onto the books. One project I was managing hit a snag just before implementation. There were pre-existing data problems that were not considered during the analysis phase. As a result several work around solutions were needed to make the system function properly.

Miscalculated Changes are those budget problems where either the funding or the timeframe was grossly under estimated. Before quickly issuing a change request to fix the problem perform a thorough analysis and get it right the second time. This helps you avoid having to go back to management multiple times. Sometimes you end up eating the extra cost, especially if it was a fixed bid project.

Not What We Agreed Changes are probably the trickiest to deal with. When one party doesn’t fulfill their end of the bargain it is sometimes called a “non-compliance” change. If in the Statement of Work there was an agreement that the system would be available for testing on a given week and it is not functioning, a change request should be issued to reset the test date and potentially fund the additional time the team sat idol.

Hopefully these examples will help you identify potential changes on your project.

December 13, 2006 - Scope Creep Part 5

So your scope has been defined, documented and approved. Great start, but how do you keep it from slipping?

Tracking Scope. Too often project managers loose track of their project’s focus. They have a clearly defined purpose and scope but then they don’t look at it again. The best way to track scope is to revisit the defining documents on a regular basis. You don’t have to re-read it word for word, but a cursory review will remind you of your direction, like Captain Jack Sparrow consulting his compass to adjust the direction of the Black Pearl.

One project manager I was working with was smoothly sailing his project and was ready to get approval for one of his deliverables. Upon reviewing his Statement of Work to write up the approval document he found that what they created wasn’t part of his project. At some point they had started using a different name and produced something that wasn’t quite what was promised. Fortunately it was close to the original and some quick adjustments brought it back in line. The point is clear, though, without keeping an eye on your compass you will get lost.

My father is semi-retired, which means he would rather be working than sitting around. He now drives tractor for a potato farm in western New York State. In order to plow a straight line he focuses on a point at the far end of the field and aims for it. One time he finished a row and found that the point he had picked was the head of a duck that was walking back and forth along the edge of the field. Needless to say, that row was not even close to straight. If you allow your scope to waddle back and forth your project will experience similar consequences.

By keeping the expectations clear in your head you can track your progress against the commitments and steer you project in the right direction.

December 12, 2006 - Scope Creep Part 4

In our quest to eliminate Scope Creep, we have covered Definition and Documentation. The next item is to ensure that everyone is in agreement.

Approval. Ideally a formal approval process should be followed. This includes time to read the document, review it with the project manager and accept it. Formal acceptance used to mean wet signatures, but with today’s technology it can be a formal email approval or through a document management system. Whatever the method, it should clearly state what is being approved and, if applicable, the version and date of the item approved. This helps avoid confusion later on when six completely different version exist in various inboxes.

Any major groups discussed or assigned responsibilities in the scope statement should have either review or approval authority. Review authority allows them to suggest changes to the document and approval authority shows ownership in the outcome.

Some people have trouble with this type of commitment. I have heard horror stories about companies that never signed anything. They consider verbal “encouragement” and project funding to indicate you can proceed, but actually approving anything is out of the question. I’m sure this gives them, and their lawyers, a sense of security. In reality they are actually less secure. Without a clear understanding of the expectations from all the involved groups the project is placed at risk. If your management is approval-adverse consider allowing a statement with the approval that says, in effect, “Approval of this document is for purpose of project definition and does not imply financial or guarantee acceptance of the final product.”

Check with the lawyers. I’m sure they can get you verbiage they can live with within a week…after your project completes.

December 11, 2006 - Scope Creep Part 3

Once you have gathered an understanding of your project you need to put it in writing. Many companies have Charter or Statement of Work templates as a starting point. What goes in to those becomes the baseline for your project. If something arises that is not in there or changes what was agreed to there will be an impact to your estimates and time lines. With that level of importance, let’s look at the next piece of the Scope Management processes.

Documentation. There are 3 specific areas you need to cover when documenting the scope of your project: Purpose, In Scope and Out of Scope. You template may have other sections, but for Scope Management, these are the key ones.

We discussed nailing down the purpose in the previous entry. It may need to be reworded before it is ready for prime time, but you have the basis already.

The In Scope section is an outcome of the list that you detailed in our discussion of definition. Now we need to draw boundaries around the items. These boundaries are not intended to put a noose around the project. Rather, they are there as construction cones on the road to keep the project headed in the right direction. They are there to let you know when you are diverging from the plan so you can make realistic, fact based decisions about the direction of the project.

Here are a couple of examples that can cause problems without the cones in place.

JAD sessions. It was decided that you are going to have Joint Application Development (JAD) sessions to drill down to the requirements. Should you just start meeting? One project manager came to me after 3 months of JAD sessions and said they had some great requirements for their project. The problem was they had spent a ton of time and most of their budget to do it and had nothing to show for it.

There are 3 things to box in for JAD sessions: The number of sessions, the number of participants and the length of each session. Your scope statement could read, “Three (3) JAD session will be held over the course of 1 week. Each session will be 6 hours in duration and will be attended by one (1) Subject Matter Expert each from the Marketing, Finance and Orders.” You have now established a basis to measure changes against. If someone from Shipping attends, it will take more effort and potentially more time per meeting. If, at the end of three sessions, there is a need for a fourth you can determine the cost and impact to the schedule and present that to the team as a change request.

User Acceptance Testing. End users are key to the success of any project. Their involvement is needed from the beginning of the design through implementation, but nowhere is it more evident than in User Acceptance Testing (UAT). As the project manager, you have little control over the end users outside of your department. Ideally they are responsible for developing test scripts, performing the tests and documenting the results. Your scope statement would read, “The development team will assist in the execution of User Acceptance Testing for a 2 week period beginning on a date agreed to with the Business Manager during System Testing. The development team will ensure that the UAT environment is available, batch jobs are run appropriately and reports are generated in a timely manner.”

In the event that a third week of UAT is necessary, you now have a clear change in scope to deal with. If your developers are asked to take a more active role in testing there may be additional cost to the project. In fact, your developers may be working on another project while supporting this effort at 50% or less.

Out of Scope is nearly as important as what is In Scope. In this section you need to spell out those things that might appear to be your team’s responsibility but are not. It is like filling out a rental car agreement where you initial…initial…sign here…prick finger and place print there. You are acknowledging that you don’t want the roadside assistance or extra life insurance and that you are going to fill the car up with gas before returning.

In relationship to the UAT discussion above, a good Out of Scope statement might say, “User Acceptance testing is the responsibility of the Business Manager. This includes the development of test scripts, execution of testing and documenting findings.”

Notice that I did not just say, “User Acceptance Testing is out of scope.” Rather, I specifically indicated who was responsible for the activity and laid out the things they should not expect the development team to do.

December 8, 2006 - Scope Creep Part 2

Managing scope begins with coming to an agreement with your sponsor and key stakeholders on what that scope is. This involves definition, documentation and approval.

Definition. Begin with a general statement about the purpose of the project. This should be an overview of the reason the project is being undertaken. It can be as short as a single sentence or up to a couple of paragraphs. Anything longer is too much. You want this to summarize the overall goal so it becomes the focus point against which scope changes are compared to later in your project. If a change request doesn’t further the project’s purpose then you should question whether or not it belongs.

The second step in defining your project is to create a list of deliverables that, when added together, fulfill the purpose of your project. When my wife sends me out to get something at the grocery store I write it down to make sure her expectations are met. Your scope gains definition as you making your grocery list. In some cases you may have to drill down a couple of levels to better understand what you are building, like buying the ingredients instead of purchasing a pre-made cake.

To do this you will need to work with the people that requested the project. One of the difficulties you may encounter is that they will want to drill down to the requirements instead of staying at the higher level. As an example, you need to know that they are looking for an online customer interface for placing and tracking orders. You also need to know which back end systems it has to interface with. You don’t need to know that the third screen should be a pale green. If it comes up you might want to jot it down for the requirements phase, but don’t put it in your scope statement.

NOTE: If you have a multi-phase project, there should be a definition of the full project and each phase should describe their slice. Depending on where you are in the life of the project, a Charter may have been developed. Reading through that and other project initiation documentation will give you a good starting point.

December 7, 2006 - Scope Creep Part 1

Scope creep. No, it isn’t that strange guy in the cube next to you with mouthwash breath. Although he may invade your personal space, scope creep can destroy your chances of project success. Some times it is stuff that isn’t even related to your project.

Here are some classic examples of the impact it can have on your project.

• A Project Manager told me about a problem she was having. Her management was asking her to create status reports for project that she was not involved in. She had to hold meetings and document information for four other projects. On average it probably stole 6 to 8 hours a week away from her real project.
  
• Picture a routine trip to the Architect Review Board to go over the final design for a new application will net the company a big profit. Your team is on schedule and has finished 50% of the development. The review board sends you back with a new direction based on updated development standards. The rework will push the project beyond its go live date.
  
• You are developing a front end to an image storage system. The idea is to be able to store, annotate and reuse pieces of animation for video games. The trouble is you have 3 different studios that are giving input to it. Each group has a “gotta-have-it” set of features. These features are killing any hope of meeting the deadline.

These scenarios make the medicine-breath guy in the cube next to you seem a little friendlier, eh? How do you deal with these situations? Over the next several days we’ll take a look at each of these situations and address the key aspects of Scope Management including the importance of defining your effort, involving your stakeholders and determining your target.