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.

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.

December 17, 2007 - Use Case Diagrams: A PM's View

Last week I attended a class on managing requirements with Use Cases. It was aimed at training business analysts and programmers to use Unified Modeling Language (UML) to understand and communicate business requirements . As a project manager I found it both enlightening and encouraging.

Enlightenment. Bottom line, modeling requirements is the quickest way to work with the end users and agree upon of what the system should be designed and developed to do. Because our focus was requirements, the class used Use Case diagrams as the basis for the training.

The three main components of a Use Case diagrams are the Actors, Use Cases and Scenarios. Actors are represented by stick figures, Use Cases by ovals and Scenarios by text boxes. An Actor is a role played by either humans or other systems that interact with the system being built. A Use Cases is a complete series of events handled by the system to help the actor achieve a goal. Scenarios detail how the Use Case will achieve those goals.

In one of my training sessions I use the eXtreme Insurance company as the basis for the exercises. The company is creating a new system to support the sale of life insurance policies to extreme sports nuts. These policies will be sold by cashiers of D&L Sporting Goods stores. The diagram above details the Purchase Policy use case. Other use cases that would be added to this diagram include Process Claim and Reconcile Transactions.

These quick, graphical representations are developed from information gathered through interviewing the users, observing system usage, researching similar systems and other means. The diagrams are then reviewed with the business to verify understanding, accuracy and completeness of the system. Gaining this clarity early in the process is cheap. Waiting for feedback until a prototype or, even worse, User Acceptance Testing may result in costly rework.
Encouraging. The encouraging part of this class was the way the instructor used Use Cases as a means to establish a requirements baseline and discuss change management. Remember, this was a class designed for analysts and programmers. By moving the discussion to their level, the Project Manager wins powerful allies for managing scope. Analysts can better identify the required functionality and processes, lower future surprises and rework. Programmers start to recognize gold plating as anything that isn’t specified in the use cases. When the business begins to ask for additions or changes, clarification begins with revisiting the diagrams and understanding what is different. Those differences become change requests to be processed by the Project Manager.

January 3, 2007 - NMJ (Not My Job)

A project manager once came to me with an interesting dilemma. It seems the manager for one of her projects was asking her for status reports on projects she wasn’t even involved with. As she explained the situation it became clear that this manager had not assigned PMs to 3 or 4 projects that he was responsible for. She felt trapped. She couldn’t easily say, “Hey! That’s NMJ (Not My Job)!”

My suggested solution was to handle it like a change request. First, determine the amount of time spent on a weekly basis to gather, document and present the status for each project. Depending on the level of reporting this could be significant (i.e. progress reporting, financial reporting, issue and risk reporting, defect reports, etc.). For this PM the effort was compounded by the fact that she wasn’t remotely part of any of the projects.

Second, meet with the manager and explain the impact this is having on other projects. Show him the estimates and point out that these projects need their own PMs assigned that are able to do more than just report status. In essence, verbally issue a change request and ask if this should be made part of your project. This ought to be enough to make him see the problem and find a different solution.

However, if he insists the reporting continue you may have a decision to make: live with it or say, “No.” For the “just say no” side, I was once asked to add a fourth project to my workload. In that case I explained that I could not successfully manage another and declined. I know the manager was disappointed and I probably lost some of his respect, but I knew it wasn’t possible.

If your decision is to continue doing the reporting, at least make sure you are placed on the projects for time reporting or billing purposes so the effort is taken from the right budget. This will help hammer home the impact without killing the budget of your original project.

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.