Posts Tagged ‘solutions’

Newer Entries »

Are you getting the truth?

Sunday, September 20th, 2009

A project manager needs to hear the truth from the team and the sponsor. In a project that is making significant changes in an organization, the PM can only be successful if they get the truth. It’s not a case of “you can’t handle the truth” but more of a case of “you can handle anything as long as you get the truth.”

Let’s look at this from the team, then the stakeholders, and finally the sponsor.

The project manager is responsible to ensure the project team has the information they need to successfully deliver on the project objectives. The other side of that coin is that the project team needs to make sure the PM knows everything they need to know to successfully manage the budget, schedule and scope of the project.

What happens when the team starts cranking the sunshine pump? Let’s say there’s a deadline coming up and it’s a key decision point. The PM follows up on the progress half way through the work package. The team states everything is on track, they’ll make the deadline. Well, great news! Except, the team knows that they might be on time but the next task needs to be completed by a person who isn’t dedicated to the project and is known for being late with deliverables.

As the PM, you need to know what issues are coming up so you can handle them. As the team, they may not want to get the other person in trouble, or may have spoken up in the past and been ignored. Your job is to dig a bit deeper. You don’t ask how the team is doing and leave it at that; it’s too easy for them to dodge the hard message. What you do is ask the next question, too; do you see anything coming up that might change the status of the deliverable? Or, you can try to challenge them by asking what could we do to come in early?

The trick is to ask more questions until you are sure there’s nothing hidden, without interrogating your team.  Don’t worry; over time you can build a level of trust with your team that will reduce their need to protect you from the truth.

Moving on to stakeholders; you may not get the truth you need from the stakeholders if there is something happening in their functional area that is considered confidential. This can slow down your project, or even put it off track.  How does this look? Often stakeholders will lose interest, or suddenly become more interested in your project. Or, they will question the goals of your project all over again. These behaviours should make your spidey senses tingle. I’ve had mixed success in dealing with this type of ‘untruthiness’. The most effective approach I’ve found is to take the helpful route; ask what you can do to help them deal with their concerns.. Unfortunately, I have sometimes found myself plugging ahead with the project knowing something is about to go sideways but not having anything to hang a risk or issue on.

Finally, your sponsor may not give you the information you need. It seems counter intuitive that your sponsor, the person you are doing the project for, would not provide you with what you need to be successful. Believe me, it happens. In my experience, it is usually politics underlying this behaviour. The only effective way I’ve found to deal with this is to accept that the sponsor has information they can’t share, and keep the project as on track as you can. The politics maybe temporary, or it may be the first steps towards closing your project. The important thing to remember is that it is not within your control. Unless you are given other directions from your sponsor, you have to assume nothing has changed. You are still expected to deliver on your project.

One of the underlying causes of sunshine pumping is simply organizational behaviour. No one wants to seem negative, or finger pointing. No one wants to get someone in trouble. I’m sure you’ve all worked with the team member who consistently gets things wrong, or causes problems on the team. Did anyone try to get the problem resolved, or did they just work around it.

Another cause of, is lack of trust.  People may have been burned in the past when they raised an issue and don’t want to risk the fall out again.

The important tip this week, handle what you can. You are responsible for ensuring the project is successful. You are not responsible for changing the organizational culture of the company – except if that’s what your project is supposed to accomplish.

This site has some good tips on questioning

Here’s another site with tips on questioning

Good luck out in project management world this week.

Tags: , , , , ,
Posted in communication, organizational savvy, Professionalism, Team management | No Comments »

Why you should welcome conflict?

Sunday, September 6th, 2009

Most people would say they hate and avoid conflict. In this environment of staff cuts, there are probably a lot of people ducking conflict to keep under the radar. In my experience it’s not conflict, but confrontation that people hate.  The problem with that is they avoid conflict; that’s one straight path to confrontation in my experience. By the time the issue becomes critical – or often, not that issue but another – there are so many frustrations in the emotional saddle bags that situations go from nothing to confrontation like a Ducati on the salt flats.  Handle conflict well and you show up as a valuable employee; handle it badly, and you are part of the problem.

Let me explain why I think these two similar concepts are so different. Confrontation carries with it a winner loser relationship, a sense of battle. Conflict leaves an opening for clarification and resolution. For example, as PMs we often have issues relating to resources. Taking a confrontational approach means everyone who needs the resources decides their need is the most critical, and they all fight over that and the winner gets the resources and everyone else get a problem project. It becomes all about who’s the winner, and not about the project or the project portfolio. Taking a conflict resolution approach means everyone comes to the table to discuss solutions that best serve the project or portfolio. They work together to present recommendations to sponsors and everyone can win.

So, let’s step back into the real world where even I live. The real problem happens when people take a confrontational approach to conflict resolution. Some organizations have a culture of confrontation; the meaner dog will always win. If that’s your organization, play that game, or find a new organization. If you want to make a change in approach and your corporate culture is not junkyard dog, start by putting aside the idea that your needs are more important than anyone else’s.

You want to get to the point where people seek out conflict to resolve. When you get there, or even when you get nearer to ‘there’ than you are, confrontation will die away. Let’s go back to the resource example.

Your project and another project need the same QA resource at the same time to do the same task. Using conflict resolution means, you need to meet with the other PM. Your agenda is to discuss solutions to the conflict. Start with the other PM presenting their issue. That’s right, let them go first; that way you will be able to listen to their issue, paraphrase back and build trust before you state your issues. That means you listen to their needs, ask questions to clarify, and paraphrase from their point of view. It doesn’t mean you sit there nodding while you wait your turn to speak.

When you’ve understood their issue, you present your needs. How much of the capacity do you need; what wiggle room do you have in scheduling; why this QA resource is the only solution, and what is the ultimate impact on your project if you don’t get the resource. A key tip here, is to make sure you talk about the project, not you, and if you can talk about the impact on the organization’s portfolio, or even the business goals if you can. The purpose is not to build a case for how important your project is, but to build the resolution to a bigger goal than just the project.

The next step, after you’ve both laid out the issues, it’s time to look for mutual solutions. Often that’s possible; in fact, you might want to ask the QA resource for solutions, they are closest to the problem, after all. Most of the time, you will find a resolution in that meeting because you have both understood the facts of the problem. Sometimes, though, a problem is tough and will need more work.

The tip for this week: don’t avoid conflict, use this model for resolution

Start by understanding the problem from a project impact perspective

Then meet with the parties involved

Listen, ask questions, and paraphrase to understand the other point of view

Search for mutual solutions – meet as many of the project needs as you can.

Some interesting links

Academic Leadership Support

Mind Tools

Susan B Wilson (no relation)

Tags: , , ,
Posted in communication, organizational savvy, Team management | No Comments »

Scope expansion, or scope creep

Saturday, August 29th, 2009

Scope can be the most difficult thing to control in a project. We all want to make sure we meet expectations, and, often it takes a long time to define the expectations. So, where does scope definition end and scope creep begin?

Scope on target or off target

Scope on target or off target

I have drawn the line for scope clarity at the point when the charter is signed. At that point, you should have had sufficient discussion around scope, using the WBS and the scope statement, to get the right scope. The right scope for every project is different. It can expand and contract through the planning process. The important thing to remember is that you need to spend the time in the scoping and planning process. If you rush to get sign off, you’ll be making scope changes as you execute – and your project will look and feel out of control.

When you have achieved sign off, and you have the right scope for your project, then you enter the scope management process. Scope creep can happen now. All scope creep means is that you have allowed – yes, you the PM – the project scope to increase without analysing the impact on the triple constraint, and getting an approval. You need to start scope management as soon as the ink dries on the charter.

Where does scope creep usually come from? In my experience, your sponsor is actually the least likely to contribute to creep. The sponsor is usually more aware of the costs of adding scope than other people, and if between you, you’ve diligently identified scope, they won’t need to add anything. I think there are 3 sources of scope creep.

Stakeholders, some may not understand the goals of the project and some disagree with the goals.  They ask to add in the little things that will take the project off course, and closer to what they need. How to deal with this? I’ve found success in a two-step process. First, review the goals and scope with them to identify where there may be alignment between the project goals and the changes. Then, unless they agree to withdraw the request, go through the agreed scope management process.  If the sponsor signs off, you change the scope and no creep exists.

Project team workers are a second source. This usually comes in the form of enhancements during design. This source of scope creep is probably easiest to prevent and the hardest to control. Prevention comes in the form of early and clear communication of the scope and the process to change scope on the project.  Control is difficult because the changes are generally small but the cumulative effect can be significant. Often you are playing catch up and managing after the fact.  When this happens, discuss the consequences of the change with the person who made it; remind them of the process, but be careful not to stifle creativity by over reacting.

The final source of scope creep, you the PM. Some time you’ll have a great idea to incorporate a strategic change into the project, or a new technology, or a budget savings, or any number of great ideas. It is critical that you follow the process of scope change; your sponsor is counting on you to manage the team and yourself.  I remember the time that I dropped in on a new PM at the end of the day. She was staring at the charter; it didn’t take a lot of perception to know something was wrong. She confessed that she’d gone ahead with her project and incorporated some great ideas. The problem was when she checked the charter in preparation for meeting with her sponsor, she had moved away from the original purpose of the project. Your best tool for keeping yourself on track is to check your great idea against the charter, just the way your handle stakeholders, you need to asses the impact of the change, and follow the change management process.

Here are a few good articles relating to scope creep.

Collegiate project

Project Perfect

Tech Republic

Tags: , , ,
Posted in Planning, Scope | 6 Comments »

How to manage the schedule for a 1200 line project

Sunday, August 23rd, 2009

I was at a PMI chapter event last week and the presenter asked how many people in the room had heard the term work breakdown structure. Only about a 3rd of the hands went up. I have to admit I was surprised at how many people hadn’t heard of it, we were all project managers after all. I did wonder, though, of the third who had heard of it, how many had used it.

When I started in project management, I had to do a lot of research on the terminology, tools, and processes. I came into it from line management and so a lot there were a lot of techniques that I didn’t understand, both what it was and why it was useful. It didn’t take me long to learn what a WBS was, but it did take me a few years to understand the value, and then even more time to really understand how to lead people through the process.

Let’s start with what a WBS is all about. It’s the process of identifying the work that needs to be done at a level that can be managed – the work package. It looks like an organization chart of your project, and that’s more or less what it is.

Here’s a simple representation of a PMO development project (ah, if it was only this easy).

WBSfor a PMO

WBS for a PMO

The project team and any stakeholders who have an understanding of what it will take to get it done create it. I generally start with a brainstorming session to identify the work packages and then group them together. Until we have a structure that captures the right grouping. The right grouping? – that depends on your project. You may want the first layer to be phases, or major deliverables, or something that relates to your organization. The important aspect of this level is that it forms the groups. Then each layer below will logically fit into the group. In the example, the top row is phases, and the next row is work that fits into that phase. You can see from the example that the bottom row is not consistent in each group. The work package is the lowest level, whether that’s one or ten layers down.

A work package is a group of tasks that have one logical leader and result in a deliverable. As the PM, you manage at the work package level and you may want to limit the length of the work package to allow you control. For instance, if you have a three-month project, any work package over 2 weeks in duration can get behind without you knowing. How do you know when you’ve got it all? One thing to remember – if it’s not on the WBS it’s not in scope. So, check the scope statement to see if everything is listed. What will also happen is new scope will appear as you and the team develop the WBS, if you work to get clarity on the details of the new information, you’ll capture the full extent of the new scope.

What’s the process after you have created the WBS? You need to review the scope with your sponsor to get approval for anything new. You need to work with the work package leaders to develop the estimates for duration and resources. As the PM, you need to pull the WBS into a project schedule and add dependencies and milestones. Here’s the Gantt of the WBS with dependencies.

Gantt from WBS for PMO development

Gantt from WBS for PMO development

The question that usually comes up about here is why can’t I just do this in MsProject, or other software? I wondered that myself. There are 3 benefits to creating the graphic.

For your stakeholders and team – it is reassuring for them to see the project scope laid out this way. It is easy to see what’s included in this format.

For you as the PM – it will remove the temptation to put every detail into the plan. Each work package has a whole list of activities that the work package leader will coordinate and you manage a shorter list of deliverables and milestones. I was able to reduce a 1200 line merger project to 160 work packages. I could manage that because I didn’t need updating on the small details of a deliverable.

For everyone’s peace of mind – creating a WBS is not done linearly, it is a brainstorming session. That means you are less likely to forget a steam of work because you are following a deliverable through its logical process.

There are a few tools I’ve discovered that will help with the process.

For the meeting to develop the work packages – Post It notes are great. Numbering the notes and entering them into the Gantt chart by hand is a good manual process.

Using MsProject with Visio. You can link from the Gantt to a Visio WBS. It’s static and you work only from Project to Visio.

Using MsProject with WBS Chartpro. WBS Chartpro is the tool I used to create the graphic. It allows you to work back and forth between Chartpro and Project.

Tip of the week try a WBS session for your project.

Tags: , , , ,
Posted in communication, Planning | 2 Comments »

Encouraging innovation, can it lead to chaos?

Sunday, August 2nd, 2009

If it did, would that be so bad; isn’t chaos the place where new and great things are discovered?

I think the most difficult thing for a project manager to do when it comes to innovation is let it happen; in a group, someone will always have an idea for improvement. Project managers want to be able to predict the progress of the project to the plan; how can you do that when someone says, “I think I can come up with a better way to do this if you give me some time to investigate.” What goes through your mind?  “Yikes, how much time? What is better, anyway? Who do you need how much is it going to cost?”

If you don’t keep that in your mind, you might find yourself killing a great idea with questions.

I managed a series of projects with my last client and by project number four we were pretty set in the routine of what needed to be done, how much it would cost, when we’d be finished. And we were great at delivery, the problem was with one deliverable. The process we used minimized the customer disruption, but still caused disruption, no one was really happy with the outcome. The deliverable required customers to change a code that couldn’t be translated automatically. One of the team members, new to the team for this project, said, “I think I can come up with a better way to do this if you give me some time to investigate.”

If he reads this blog, he’ll recognize the situation. What I’m hoping he won’t recognize is my internal reaction; “What the @@##!!, do you mean? We’re on track, we can’t divert for an idea. And other similar thoughts.”

What I said was something along the lines of, “tell me about it.”

We had a quick discussion and I asked for this information; how long do you need, who do you need, how comfortable are you that this could work.

The result was a solution that resulted in no customer complaints, little manual support, and overall savings of a week of post launch assistance, as well as a reusable solution for future projects. Man, am I glad I had my internal filter running.

So, the tips for this week are,

  • Be willing to listen when someone has an idea, it can be someone new to the team, someone on a completely different work stream or any stakeholder who comes up with an idea.
  • Try to find the resources to investigate the idea if it has some potential to improve your project.
  • Don’t ever think that a solution is perfect; someone will always have an idea to improve it.

Some resources for innovation online,

The always informative and entertaining Tom Peters has a video

An article on developing innovation

Steven Shapiro’s 24/7 innovation site

Tags: , ,
Posted in Innovation | 3 Comments »

Newer Entries »