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.