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 15, 2006 - Scope Creep Part 7

Now that we have identified a scope change we need to react to it.

Change Requests. A change request is a formal method of asking for something different. It puts in writing what the request is and the impact it will have on the project schedule, budget and deliverables. Using it as the basis for discussion allows a decision to be made on whether to accept or reject it. Once it is approved it becomes an integrated part of the project’s defining documents, overriding what was originally agreement.

For our discussion we will look at who can initiate a Change Request and what type of information to include.

In most environments I have worked anyone can initiate a Change Request. In practice it is usually the Project Manager who ends up researching and documenting it. The general rule I follow is to allow a maximum of 4 hours to document a change. If it will take longer than 4 hours to research and write it up then consider issuing a separate Change Request that authorize the additional effort. For example, an additional feature to a screen may be a simple item to document. The effort to document a new data feed may take days to research all of the ramifications. The cost of that research in time and budget needs to be agreed to before it is spent.

In addition to the project identification information (i.e. project number, name, PM, etc.), the key areas a Change Request should cover include a description of the change, justification of it and the effect on the project scope, schedule and cost.

Description. The first thing to include is a description of the change. This should be done in the language and terms of the impacted group. Don’t use technical jargon. Keep it simple and clear.
Justification. Explain why this change is necessary. If I have to tell you a thousand times I will, don’t use hyperbole. This is your chance to tell the person holding the money why we need to include this in the project. Cover things like savings, functionality, regulations, etc.

Effect on Scope. Just like we did in the Statement of Work, lay out the scope of the change. Using one of our examples from before, if you are adding more JAD sessions, specify how many and any changes to the number of people, duration, etc. This is where you need to be as precise as in the defining documents. Remember, once this Change Request is approved it becomes part of the defining documents.

Effect on Schedule. Changes impact time lines. When features or other items are added to a project it will take longer. Make it clear that you can’t add 10 things and still meet the deadline.

Effect on Cost. When asking for more money, do your math. I don’t subscribe to the “pad it” theory. Be realistic, not optimistic, but don’t add 20% “just in case.” If the Sponsor sees this behavior he will always cut your budget by 20%. It is better to just be up front, show your figures and be honest.

Without this more formal process you may end up the type of situation that happened to my dad. He occasionally does carpentry work on a time and materials basis for people. Once he was installing a door between two rooms. He had it all roughly framed in and the owner asked to have it moved to the other end of the wall. So he pulled the frame, put studs back in the wall and started framing it in at the other end. Again the person changed their mind and wanted it moved back closer to the center. Being the customer centric man he is, my dad moved it again.

When he presented the bill to the owner, she couldn’t understand why it was so high to install a single door. My dad replied that he had actually installed three doors and filled in two of them. Since it was time and materials the homeowner hadn’t considered the extra cost.Note: Although our discussion has focused on adding scope to a project, a Change Request can also be used to remove scope or clarify an existing point. A classic example of reducing scope is moving something from Phase 1 to Phase 2. If this happens the impact to the schedule and budget should be to shorten the duration and decrease budget. Commonly reducing scope is used to bring the project back on schedule and in budget so you won’t see the timing or financial adjustments.

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.

December 6, 2006 - Christmas Concert Managed to Perfection

’Tis the season for Christmas concerts at the school my daughter attends. After quickly doing the math to determine how many songs she will be participating in, the question became “will we end on time?” By asking that question I began crossing the line from sitting back and enjoying the presentation to project management.

The program I received became a task list to be checked off as each performance finished. By estimating an average of 3 minutes per piece and allowing time for groups to enter and exit the stage the task list grew into a project schedule. It was all down hill from there.

As I marked each performance complete and checked the actual time spent against my baseline, I observed some great management techniques being demonstrated:

1. Phase Zero – Some projects have preparation work that is necessary to complete before the start of the project. They incorporated this “Phase Zero” approach at the concert. Prior to the start time there was a group singing in the entrance, which moved that effort prior to the start of the project.
   
2. Stakeholder Management – Between different groups the audience was distracted by having to sing Christmas carols. Keep your stakeholders involved.
   
3. Multi-Tasking – As the carols were being sung to cover the transition, the kids due up next were hurrying to their places, making an otherwise disjointed scramble into a seamless transition.
   
4. Time Management – The carol leader assessed the progress of the groups taking their places on stage and could reduced or lengthen the audience singing time to end when everyone was ready.
   
5. Resource Management – At one point while a group performed on stage right, the next group was assembling in the middle of the stage for their performance.
   

To my surprise, the concert came in under budget by 8 minutes. It was obvious that the teamwork demonstrated was the result of years of perfecting this show. If only all of our projects ran as smoothly.

December 5, 2006 - Management by Procrastination Part 3

Now we have a prioritized list. Has procrastination paid off yet? Actually, it has. By taking the time for prioritization you have made it clear to the stakeholders that the complete wish list can not be tackled. That means some of them fall under the 90% category and we can continue to the next step.

Deliver. We’ve narrowed it down to the hypothetical 10% you can’t avoid. Put the tasks into the schedule and assign resources. These tasks will take away from your team’s productivity and impact the delivery dates so they need to be tracked. Placing them into the schedule shows that impact.

Then do the work. It sounds simple, but if you have committed to it and your stakeholders are expecting it, you better get it done.

Track the progress to completion. Treat them like other tasks in your plan by collecting status and time reporting to see the continued effect on the schedule.

Finally, announce completion of the significant items. This loop back builds the stakeholders’ confidence in both the process and the team.

So don’t put it off any longer. Begin procrastinating today.

December 4, 2006 - Management by Procrastination Part 2

So far it may look like procrastination has only brought us more work. We’ve taken time away from other things to create a list. How has that done anything for us? If you consider for a moment you will see that the list made everyone admit they asked for something more than what we agreed to. That probably caused things to immediately fall off the list as unimportant. In addition, as a project manager you have allowed your team to continue their work uninterrupted as you take the second step.

Prioritize. Once you have created the list determine which ones are most important. There are several ways to assign the priority. The simplest is to ask the key stakeholders which three are on the top and then work those into the schedule. This is obviously subjective but is practical. On the other end of the spectrum is taking the time to rank each one based on set criteria. Some examples of criteria that could be used include:

Return on Investment (ROI). Determine which additional items give you the biggest bang for the buck and focus on those. This requires additional work to define the cost, savings, profit and impact to the schedule for each task.

Functionality vs. Extra. If an item is necessary to make the system function better it is more important than the bells and whistles. Features that fail the functionality test can be added in the future.

Ease of Implementation. More complex tasks are going to eat away the time your resources have to complete the project. These items can be moved to the bottom of the list, effectively procrastinating them to phase 2.

However you decide which ones should be added to the project, make sure you follow your change management process. If additional budget or duration is required, get the commitment from your sponsor before moving forward.

December 1, 2006 - Management by Procrastination Part 1

Management by Procrastination is alive and well in project management. My theory is that 90% of non-scope items that you are asked to do will be changed, dropped or done by someone else before you can get to it. The trick is to figure out which items make up the other 10% and do them. I’ve written a chant you can practice quietly to yourself while sitting in another boring meeting to promote this management technique:
Procrastinate, Procrastinate
Put it off until it’s late
S-T-A-L-L
Stutter, stop……wait

All right, so there isn’t much science behind my theory but there are real results from procrastination. When tasked with activities tacked on to your project, the key is to identify, prioritize and deliver.

Identify is more than merely taking note of anything that someone suggests you do. First confirm that what you heard is what they said. Second, make sure you are the one they are asking to do it. Finally, put it in writing for review and approval. “Approval” in different settings means different things. It could range from verbal to email confirmation to wet signatures. Choose appropriately.

So to identify the real tasks the questions you should ask are: (1) Did you just say what I think you said?” (2) “Are you talkin’ to me?!?!?” (3) “Could you please sign here…and here…initial here…and thumbprint there?”