Monday, December 18, 2006

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.

Friday, December 15, 2006

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.

Thursday, December 14, 2006

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.

Wednesday, December 13, 2006

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.

Tuesday, December 12, 2006

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.

Monday, December 11, 2006

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.

Friday, December 8, 2006

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.

Thursday, December 7, 2006

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.

Wednesday, December 6, 2006

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.

Tuesday, December 5, 2006

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.

Monday, December 4, 2006

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.

Friday, December 1, 2006

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

Thursday, November 30, 2006

November 30, 2006 - But that isn't my project

I was mentoring a project manager at one of my clients. As we talked, she began telling me about the additional tasks she was being assigned that were keeping her from effectively manager her project. One item was creating status reports for projects that she was not managing. These projects weren’t even remotely related to hers, yet she was charging time against her project for researching and presenting the status.

If you find yourself in a similar situation, first determine the additional effort that is being expected and the impact it is having on your other responsibilities. Schedule a meeting and discuss the situation with the individual. Tell her you are willing to perform the tasks if necessary but that you would like to explain the impact to your current assignments and workload. Use your project scheduled or other evidence to outline the slippage it is causing.

Sometimes that is enough for her to realize the responsibility isn’t yours. If you still end up with the chore, request additional charge numbers to bill the time against for the reporting. If it is still pushed to your budget, consider issuing a Change Request to the sponsor for the number of hours and change in schedule to perform the tasks. In a less formal setting, an email recapping the conversation and decision may be more appropriate.

The bottom line is that you have committed to your project and budget and the additional tasks are eating away at those. There needs to be a clear understanding of the problem and an agreed upon solution that keeps both you and your project sane.

Wednesday, November 29, 2006

November 29, 2006 - Surviving Directional Changes Part 4

So far we have set ourselves up for success and discussed improving while remaining constant to the purpose. Both of these prepare us for changes as long as we see them coming.

Recognize Change. Change is inevitable…unless you are buying coffee at Starbucks with a ten dollar bill. Within the context of surviving change in the QA group there are three kinds of change that I’d like to discuss: Contractual Changes, Organizational Changes and Hidden Changes.

Contractual Changes are obvious when they happen but the impact may not be evident at first. An easy consulting example of this is if your contract switches from fixed bid to a time and materials. If in the original contract the QA group was a non-billable feature it needs to be recognized and billed for or the group will soon be terminated. Our original contract included obtaining CMM Level 3 within 1 year. This forced our focus for the first 12 months was on achieving that. If our contractual agreement changed, our focus and perhaps our charter would have had to change, too.

Organizational Changes may occur without you knowing it immediately but can still have a big impact on the group. If new business management results in a heavier focus on SOX related items, your continuous improvement muscles might get stretched. If the new focus is away from process and more on speed, you will receive more push back from the development teams. As organizational changes happen it is important to identify them and begin looking for clues on their impact. We ran in to this when our direct QA manager changed. The focus moved from the corporate SQA group as our sponsor to the local management as our “client” and ensuring they were satisfied. This shift resulted in substantial changes in the way we operated.

Hidden Changes are a pain in the butt. You find out about them by accident like the party in high school you weren’t supposed to be invited to. Someone says “didn’t you know? Oh, um, never mind.” It happens during audits when the PM says “we’ve been told not to do it that way any more.” Or when someone comes back from the Architecture Review Meeting and informs the team that there is a new requirement to replace all Java code with Mocha Latte.
The best way to catch these changes is by putting yourself in the right places. Get yourself invited to development department meetings. Create a PM Forum where project managers can share war stories, complain and transfer knowledge. Pay attention during audits to the excuses for noncompliance.By setting yourself up for success, continuously improving while focusing on your purpose and recognizing changes you will be able to prolong the usefulness and impact of the QA group.

Monday, November 27, 2006

November 27, 2006 - Surviving Directional Changes Part 2

In a quest to build stability in your team 3 key activities were identified: Set yourself up for success; strive to continuously improve; and recognize change and the impact it will have on the group. Identify your sponsor was the first step to setup for success.

The second is to recognize the stakeholders. Among the stakeholders for our QA group included the Corporate SQA manager, the on site consulting management and the project teams. Our group was expanded to include the Project Office role we also trained, mentored and audited the project managers so they also became key stakeholders.

Of course recognition involves more that just naming them. Documenting the relationship and responsibilities the group has toward these individuals leads directly into the next step, create a charter and obtain approval. This formally identifies the group, draws the boundaries around their responsibilities and grants the authority to perform those duties. This is another point where the level of authority of your sponsor is important. If it is too low the charter won’t be enforceable.

The final step in setting up for success is to communicate the group purpose and objectives. It is important to let the key stakeholders know what you are charged with accomplishing. This was especially important in our group. There was a need for Quality Control function to verify the final product; however our charter outlined our responsibilities as Quality Assurance focused on ensuring the processes were defined and followed. When our purpose was questioned we returned to our charter to make sure we were meeting the group objectives.

Wednesday, November 22, 2006

November 22, 2006 - Surviving Directional Changes Part 1

Last night I had the privilege of speaking to the Orange County Southern California Quality Assurance Association (http://www.scqaa.com/ ) about surviving directional changes. The presentation focused on lessons learned by the Quality Assurance group at one of Keane’s largest AO engagements.

This particular Quality Assurance group combined responsibilities of the project office and the process definition and audit group. Their focus was on training, mentoring and auditing project managers to ensure that projects were performing according to the documented procedures. In order to gain and maintain stability in a changing environment the group had to do 3 things: 1. Setup for Success
2. Continuously Improve
3. Recognize Change

Setup for Success. The first key to a successful start is to identify your sponsor. The sponsor is the person you derive your authority and direction from. Ideally for a QA group the sponsorship and reporting structure should be different than the one for the delivery team. This alleviates any pressure to alter or water down the auditing if the results reflect poorly on your own management. It gives the group a route to report decisions and actions that may place the company or project at risk.

After the Thanksgiving weekend we will take a look at each of the remaining keys to setup for success.

Have a happy Thanksgiving.

November 21, 2006 - Risky Business Bonus: Think Positive

Based on what we have discusses so far, Risk Management seems to be about keeping bad things from happening. If you really want to throw your management for a loop, start actively managing beneficial risks.

Think Positive. The same steps we identified for keep risks from becoming issues can be used to focus on brighter outcomes. This is more than rewording your risks to have a positive flavor. Suppose you recognize that the project could be a real showcase for your company and could earn well deserved attention for your team. "Promoting team recognition" could be treated as a risk. Mitigation steps might include documenting the anticipated benefits and publicizing them to upper management. Obviously this is not a traditional risk and would never end up being an issue, but it can have a big impact on success of the project.

November 20, 2006 - Risk Management Bonus: Contingency Planning

Most risks never actually become issues. We face hundreds every day without panicking. Every time I merge into traffic from the 605 to the 405 near Seal Beach I run the risk of getting stuck in traffic for hours. Actively managing my daily commute involves checking the news or Internet before leaving and listening to the traffic reports en route. If I wait until traffic stops in front of me I may be a mile from the next exit. But sometimes my best efforts fail and I need the fall back plan.

Contingency Planning. Contingency plans are preplanned actions that can be taken when a risk meets a trigger point that identifies it as an issue. By predefining the steps to be taken there is no need to panic. People know what to do when the manager tells them what has happened.

The trap some organizations fall into is relying heavily on their contingency plans instead of actively managing their risks. By waiting until the risk becomes an issue to take action on it, projects spend more time and effort dealing with the problem.

The key is to plan for the worst but work for the best.

Friday, November 17, 2006

November 17, 2006 - Risky Business Part 5

So far we have identified, prioritized and defined mitigation steps. We have moved from a list of excuses for failure to a list of things that could save our project. But if we stopped there nothing will get accomplished and we will still get bit.

Assign an Owner. Without ownership being assigned to the mitigation steps, no one will do them. It’s like walking into your messy living room and saying, "someone really ought to clean this up." Chances are it will be messy the next time you walk in, too. It is important that the responsibility of the action be given to a single individual. If 2 or more are assigned they will either talk it to death or assume the other has it covered.

Two quick notes. First, a risk can have more than one mitigation step. Either assign an individual to each step or make one person responsible for ensuring it gets done. Second, the person assigned does have to be the one that does the work. Don't try to micromanage a separate group’s resources, assign it to the team lead.

Set a Due Date. Determine when each mitigation step needs to be completed. If possible allow the individual assigned the step to set the date. A date imposed is "unrealistic" but one that is self-selected carries a subconscious commitment with it. Granted, dates that are too far in the future will need to be negotiated.

Track it. Give things a chance to happen. Although risks can be discussed during status meetings, ideally a separate meeting should be scheduled on a monthly basis to rework the list to:
* Check status on mitigation steps
* Identify new risks
* Re-assess the probability and impact levels
* Modify mitigation steps and dates

By actively pursuing risks you can eliminate potential issues before they even start.

Thursday, November 16, 2006

November 16, 2006 - Risky Business Part 4

In the first part of this series I mentioned the risk of being bit as you walk down the street. As you see the dog you identified the risk and automatically begin assessing the probability and impact of getting hurt. The value you assign to each of these depends on the answers to questions like: Is it a full-grown pit bull or a Chihuahua puppy? Is there a fence between you and it? Does the sign on the fence say “beware of dog?”

Assuming it is a pit bull with no fence and he staring intently at you while growling, several options form in your mind on how to avoid being bit and seriously hurt.

Mitigate. Those ideas are mitigation steps. They are actions you can take now to reduce either the probability of being bit or the impact of the bite. To lower the probability you could slowly backup and turn onto another street. Wearing protective gear with thick padding could lower the impact of the big, sharp teeth.

Review the top 3-5 risks on your list and document action steps that can be taken to either lower the probability or the impact. Make sure the steps are specific and able to be performed. It must be more than “watch it to see if it gets worse.”

As simple as it sounds, this is the first step away from a list of pre-recorded excuses for failure and actively eliminating risks before they kill your project.

November 15, 2006 - Risky Business Part 3

Risks spell danger for projects. There are potential problems lurking everywhere, waiting to become issues and trip up your progress. Identify was the first step in managing risks. The next step involves determining which ones to focus on.

Prioritize. Not all risks are created equal. If you spend your time pursuing those with very little impact on your project or are unlikely to happen, you won’t have time to manage anything else. The key to prioritizing them is to identify a Probability and an Impact for each identified risk.

This is not rocket science so a lot of time should not be spent on each risk. Simply ask the group how they would classify the likelihood of the risk becoming reality on a scale of 1 to 3 where 3 means that it is “very likely to occur” and 1 equals “might possibly happen.” Number 2 naturally falls in the middle.

Once you have agreed on a probability, determine the impact to the project. On a scale of 1 to 5, how bad will things get if the risk becomes an issue? Here a 5 is a major impact and 1 is very little impact with 2 to 4 filling in the difference.

By multiplying the Probability by the Impact you can calculate the PIF or Probability Impact Factor. This is a range of 1 to 15 that quickly ranks your project risks where those with a higher PIF value being the ones to focus on.

The group should then review the numbers to ensure that the risks they think are the most important show up at the top of the list. If not, discuss why and adjust the probability and impact if they don’t make sense. Don’t just change the PIF as we will discuss in the next section.
This step may seem simplistic but it is very effective in helping your team focus on the important risks.

November 14, 2006 - Risky Business Part 2

Yesterday we began a discussion on risk by defining the difference between a risk and an issue. Our ultimate goal is to document, actively work and track progress against the risks until they are no longer a threat. The steps for accomplishing this are Identify, Prioritize, Define Mitigate Steps, Assign Owners and Track.

In some environments project managers identify risks at the beginning of the project and do nothing with them afterward. There is a section in the Statement of Work or Charter that requires them to fill in the project risks and dutifully they put in the standard ones: resource availability, aggressive time frame, etc. These risks are simply there as excuses in case the project fails. The PM can go back and say, “See? I told you we didn’t have enough resources.” The PM failed to take actions to prevent the risks from becoming issues.

Identify. The process for identifying risks is quite simple: write down anything that could go wrong or have an impact on your project. Avoid the temptation to do this in a vacuum. For technical risks, schedule a 90 minute meeting and pull the technical team into a conference room with a white board and brainstorm potential problems. Do the same for the Business. Limit the time to 15 – 20 minutes so you have time for the other steps in the process. Initially there are no dumb ideas and all should be captured as quickly as possible. This is not the time for discussion. Make sure everyone understands what the premise of the risk is, jot down a brief description and move on.

November 13, 2006 - Risky Business Part 1


The picture to the right is of a Joshua tree in the desert of Joshua Tree National Park, California. When you look at the image, what risks come to mind? Your answers probably include:
* Becoming stranded.
* Getting pricked.
* Dehydration.

The answers really depend on your purpose for being there. If you are trying to cross the desert, the answers above may be your key risks. If, however, your purpose is to take pictures of the natural beauty your other risks would include running out of film, over exposure and good angles shots. Suppose your goal was to convince people to preserve the area from development? Or come live there? Each perspective carries its own individual concerns.
Risks are different from issues. The PMI Project Management Body of Knowledge (PMBOK) defines them as follows.

Risk – An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.

Issue – A point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements.
I would add to the issue definition that it has some impact on your project. Otherwise no one would be overly concerned about it.

To help illustrate the different between the two, picture yourself walking down the street. On the lawn up the street you see a dog and identify the risk of being bit. If you don’t take some mitigating steps and the dog bits you, it becomes an issue.

So a risk is something that has a potential impact on your project and an issue is a current event or condition. Issues you have to deal with, but risks are generally overlooked.

Whatever your project, there will be risks involved. In this series I want to lay out some simple steps you can follow to identify risks, prioritize them and either reduce the potential of them occurring or lessen their impact to the project.

November 10, 2006 - Being Heard and Not Ignored Part 5

Over the last week we have looked at ways to be listened to and be taken seriously. The last step involves putting your ideas to the test of others.

Allow questions. Being project manager is not for the faint of heart. Despite your careful planning and communication you will be questioned, second-guessed and challenged on a regular basis. Rather than trying to quell any questions or contrary opinions, I suggest you give a forum for discussion and encourage people to ask. I see 4 things that this does for you.

1. It gives your team a voice and invites them to be involved. This gives them ownership in the process even if you don’t alter your plans after considering their input.

2. You have to think. If you are answering questions, you need to honestly think through your stance and be able to defend it.

3. Questions allow you to refines or refocus your direction. Good questions make you think and good thinking can lead to better results.

4. Discussion gets the dissention out in the open. If you can hear and field the questions you stand a chance of removing opposition. If the second-guessing is being done behind your back it may spell disaster.

There are more ways to keep from being ignored. If you have some suggestions or examples from your experience, feel free to click on “Comments” below and share them.

November 9, 2006 - Being Heard and Not Ignored Part 4

Having something to say, knowing the language and speaking with conviction allow you to get your thoughts out. Now you will need to be quiet.

Listen to others. For those of us who think we have a lot to say, this is the toughest part. We are constantly thinking of the next answer or defense for what the person across the table is saying. I learned some time ago that my ideas aren’t the only ones and sometimes they aren’t evens the best. The team you lead and the people you support, both management and business, are there because they have competence in their area. Granted, there are always exceptions to the competence rule, but in general they know their stuff.

There are many books the encourage “active listening” that involves looking at the individual, nodding at key points they make and commenting back on what they said. These actions make the speaker feel as if she is being heard. This is great as long as you really hear what is said. You can easily nod your head and say “yup…yup…yup” and never hear anything.

Once you have heard what was said, process it. If it makes sense, act on it. Adjust your opinion, thoughts or plans. If it doesn’t fit with the program, explain your reasoning and move on.

November 8, 2006 - Being Heard and Not Ingored Part 3

For the last 2 days we have discussed how to really be heard. First you had to have something to say and then you needed to know the language to say it in. Now you’re ready to speak.

Say it with conviction. One of the things they teach a new referee is to say it like you mean it. If you don’t act confident the parents and kids start to question your ability to ref. The same is true with project management. A weak, unsure PM will not instill confidence in the team and every decision made will be questioned. Be sure of your facts and don’t wimp out. When the budget isn’t enough or the timeframe is too short, say so. If a Change Request is the right thing to apply, let it be known.

Let me be clear, this is not:
1. A shouting match where your voice is loudest because you are in charge.
2. An excuse to skip out on the homework necessary to have a solid plan.
3. A cover up for not having the evidence to back up you statements.

Speak with confidence and be able to back up your position with facts, evidence and good logic.

November 7, 2006 - Being Heard and Not Ignored Part 2

Yesterday I began writing about how to get people to listen to you. The first step was to have something to say. The second may take a little longer.

Know the language. One of the biggest challenges facing PMs as they enter a new environment is being able to speak the lingo. The basics of project management are fairly universal but the specifics of the assignment are extremely diverse. You aren’t required to be the expert on all technical pieces, but you need to be conversant in the language.

Last week a PM was telling me about a recent assignment she managed. She took over an infrastructure roll out of approximately 70 new servers. Being her first infrastructure project, she was basically clueless. Acronyms and phrases were being thrown at her like rice at a wedding. With a little effort, listening and guessing she was quickly spouting words like racks, servers and cabling. As her vocabulary improved, so did her credibility.

November 6, 2006 - Being Heard and Not Ignored Part 1

I spent most of Saturday on a soccer field either watching my daughters play or refereeing. It made me think of the similarities between a referee and a project manager. The referee has 17 rules to remember and enforce. They give him a whistle and everyone has to listen to him. His word is law. If anyone takes a swing at him or even talks harshly to him he can pull out a red card and send them packing.

For the project manager the rules are constantly changing. They give him a budget to balance and nobody listens to him. His word is ignored. Anyone can take a swing at him and he can be sent packing at any time. Oh, and no whistle. Okay, so there aren’t many similarities between the two.

This week I want to take a look at how to be heard and not ignored with or without a whistle.

There was a specific meeting at which I first realized people were listening to me and actually taking me seriously. I don’t recall the exact topic but I remember looking around while I was speaking. I thought, “Wow! They are paying attention to what I’m saying. Oh, crap, what am I saying?”

Have something to say. The first step is to have something to worth listening to. Any fool can blab on for hours about nothing. In that meeting I could have been shouting nursery rhymes and no one would have listened.

November 3, 2006 - Garage Style Status Reporting

My garage is a mess. In addition to the boxes of clothes to be donated, old dressers with broken drawers and the large pile of stuffed animals there are a couple of projects in process. If I were to update you weekly on the activity in my garage you probably don’t care about most of it. This concept hold true for your status reports.

There are infinite variations of information given on status reports, but all of then convey what has been done for the recent period of time. Management doesn’t want details; they want to know what you started and what you completed. Here are some not-so-good phrases to avoid on your status report.

Met with team and discussed testing. Nobody really cares about meetings. They want decisions. You wouldn’t care that my wife and I discussed paint colors for an hour. You may be interested if we decided to paint the living room mauve. Replace “discussed” with decisions such as “Outlined Test Strategy and assigned Joe to begin creating the Test Plan.”

Continued developing Credit Collection application. One of my friends has an old mustang he is refinishing in his garage. It does me no good to have him generically tell me it is still a work in progress. It would be better for him to say, “I had the radiator re-cored and hooked it back in. Now I’m starting on replacing the hoses.” Better statements in your status might be “Completed Module X. Started design of Module Y.” Break it down and report real progress.
Development is about 90% complete. Random, unsupported percent complete is worse than giving no status. It gives the impression of accuracy without the reality. Sometimes the last 10% takes longer to complete than the first 90% did. Break the activity into pieces and reporting the number complete. The 90% complete would then become “Completed 18 of the 20 modules. The remaining 2 are scheduled for completion by the end of next week.”
Once you get your status reports cleaned up, maybe you can help me with my garage.

November 2, 2006 - If you don't know, don't touch

Much of life's wisdom comes from doing stupid things. If at all possible, learn from other peoples mistakes. Like mine...

Many years ago, while I was a UNIX C programmer, I had the grand idea of fixing my own account problem by working directly with the password file. Working in a small company I had the system password and the power but not the knowledge to do it properly.

Being extremely careful, I made a backup of the password file, made the change that I wanted and rebooted. Unfortunately the change I made locked everyone out of the system. Even the system admin login failed. It took all day to get it back up and running.

So, what does this have to do with Project Management? It helped me realize that there are things I shouldn't touch. If there is an issue that is outside of your control it is ok if you can't solve it. Don't ignore it. Get someone else involved that can do it right. In the end you will save time and you won't look like an idiot.

November 1, 2006 - Initial Introduction


Since this is the first entry in my blog, an introduction seems to be the way to begin. Today, November 1, 2006, marks 13 years of consulting with Keane, Inc. Prior to that I worked for Telxon, a hand held scanner company eventually purchased by Symbol, and NetLink, a start up company manufacturing a magnetic stripe and smartcard reader.

Through my career I have enjoyed a diverse set of industries: Retail, Manufacturing, Healthcare, Insurance, Finance, Entertainment and Automotive to name a few. I've even been privileged to work at recognizable companies like American Greetings, Toyota and Electronic Arts.
My point in writing this is that I have been in multiple places and worked with many great individuals. If something I write reminds you of someone you know or, worse yet, if it reminds you of yourself, I will deny everything. Part of this of course is to protect the guilty but most of it is to preserve my own skin.