Archive for the ‘Team management’ Category

Prioritization and emergencies

Sunday, September 5th, 2010

So, what happens to a schedule when emergencies happen?
At one time or another the team will have emergencies that take them away from the critical work. In most projects, there will be changes to the market that cause emergency changes to scope, timelines or budget. And, often the PM is the one to direct and support the team through the emergencies.
What happens when the PM is the one who has the emergencies?
Have you set up the project to run without you – even for a short time? Do you have contingencies for your absence?
What are the tips you would give to less experienced PMs?
Happy PMing

Perry

Status reports – useful or not?

Sunday, August 1st, 2010

I’ve been reading a number of posts on LinkedIn and other blogs about status reports and why they don’t work. Most of theses are promoting a different model for status reporting. The problem is not with a format of reporting, but with the process of reporting.

The reason we status report seems to have gotten lost in the search for a new format of status reports. We report to keep people apprised of the status of the project. We use whatever tool fits best within the organization, or methodology.

The key elements of status reporting are,

  1. where we thought we would be based on the last approved baseline and where we really are
  2. what we see as issues that the sponsor needs to help resolve, and how they need to help
  3. what we see coming up that is just a heads up – and what we’re doing about it

If you are reporting clearly and honestly on these three points, the status report has value. If not, here’s the problem,

  1. Where we are v where we thought we would be. If you are trying to provide a more optimistic picture, you’ll mislead the sponsor, and lose your credibility
  2. If you are trying to show you can solve the issues when it’s really in the hands of your sponsor, you are going to have to come to the table for help when you are at the end of your resources. The sponsor wants to help, let them get in there and do their job.
  3. If you don’t tell your sponsor what’s coming up – and say whether you need help or not – you’ll look like you are blindsiding them when they hear it from someone else.

So, the point is, status reporting is communication and if you communicate the right things clearly and objectively, the format is just a tool.

What do you think about status reporting? Do you have a story to share?

Happy PMing

Perry

Team burnout

Sunday, June 27th, 2010

A short post today because I’m suffering a bit from team burnout. It’s been a while since I’ve been here and I wondered how many project managers forget that teams get burned out and they need time to recover.

I’ve been working as part of a team putting together a conference. I’ve never done this before and man did I underestimate the effort. Sound familiar? Well, I wasn’t even taking on the biggest load but today, the conference ended today, I feel wiped. I know I can start controlling my time now, well as much as I’ve been able to control it in the past. And I enjoyed the conference, getting a ton of great ideas and advice.

But, today I have little or no perspective. I see all the tasks I’ve let slip in priority. I look at the pile of new work I have to do and it seems like a mountain. Okay, that’s a bit melodramatic. In my head I know I’m in control, but my tiredness is weighing me down.

So, when your team has pulled a huge effort to meet a deadline, and you’ve celebrated with them, thanked them, and congratulated them. You need to remember that they need a bit of breathing space.

Don’t launch into talking about the next exciting challenge – it can seem like a never ending demand on them.

Don’t expect them to give 110% percent the next working day – they may not have the energy.

Do be clear about the next immediate priorities and what the expectations are for the next few days.They’ll need some perspective.

Do review the project plan with the team – seeing how far they’ve come can re-energize them for the next effort.

Do have the sponsor thank them for their effort – it’s nice to hear the effort is appreciated at the top.

Anyway – I need to do some things I want to do for the rest of the day, rather than things I feel I have to do.

Have a great PMing week.

Perry

People skills and your inner voice

Sunday, June 20th, 2010

Have you ever wondered why that team member suddenly causes you more problems when you have less time to deal with them?

It’s not them.

When you get under pressure, your little inner voice, the one you ignore otherwise, starts telling you how to act. It’s a lizard voice in your lizard brain. Rarely will your voice tell you ‘be patient’, ‘ask questions’. It usually comes in the form of “get it done and deal with the people later”.

My voice tends to tell me to ‘just get it done and don’t wait for people to figure it out. You can always show them how you did it afterward”. Not very empowering for the rest of the team.

The lesson I’ve learned over the years – and still have to remember to learn – is when that lizard starts talking I come to a stop and remind myself to ‘be patient’ and ‘ask questions’.

When you start to hear that voice, whatever yours says to you, take a breath think and then act.

What about when there’s a safety issue? I suggest that the best time to make sure you aren’t causing more problems rather than calmly dealing with the situation.

Happy PMing

Perry

Project Management Office – why do I need one?

Monday, February 1st, 2010

This is a topic close to my heart.  I think it’s because I know that PMO can mean so many things to an organization and the first step is getting the answer to the question posed by the title of this posting.

Most organizations that have a history of project management find themselves all over the success range from Fabulous Success to Spectacular Failure. This variety of outcomes is often the trigger for the executive to start on the PMO path.

In my experience, the reasons to implement a PMO are, in no particular order;

  1. improve and standardize project performance
  2. provide enterprise wide reporting
  3. create a common reporting structure
  4. portfolio management
  5. centre of excellence in project management and related disciplines
  6. a combination of any of the above.
  7. all of the above

Many organizations also cycle between – absolutely need a PMO to why do we need to pay the overhead of a PMO?

I’ve created and collaborated in creating two PMOs and my experience is that a successful PMO starts with the executive backing aligned with the top reasons for creating a PMO.

Just like any project, you need a champion/sponsor, and a clear understanding of what you are going to deliver.  You run the creation and implementation as a project. Develop a clear understanding of the outcomes, create phased milestones, measurements of success (both for the project and the operation of the PMO) and report on the status during the initial period.

The key is that implementation is not the end. When the PMO is running and showing success, the whole reason for the PMO needs to be revisited and refocussed. A PMO is not a product that gets delivered, it’s an operational part of any organization and it evolves.

If the first priority is to create a centre of excellence for project managers, you will likely find that the PMO will evolve towards portfolio management because the executive see more possibilities as the PMs become more professional.

If the priority starts as portfolio management, then it will likely evolve towards a centre of excellence very quickly as it becomes clear that more projects can be done if PMs are supported and developed.

Whatever the starting point, if you are managing/directing a PMO, you need to remember it evolves. Keeping your PMO alive is a process of constant selling of the current and possible value of a PMO.

Have fun this week.

Trust and delegation

Sunday, January 10th, 2010

Hi, this week let’s look at the concept of trust and how it affects your ability to manage a successful project.

As the title suggests, this issue hits on the ability of team members to trust someone to do the job. Sometimes it’s the sponsor, and sometimes a stakeholder, and sometimes it’s a subject matter expert.

Why don’t people trust? Well, I’d say the 99% of the time it’s not about thinking the person won’t do a good job – their desire and motivation, but more about the can’t - about their knowledge and ability. The can’t is where you hear things like ‘it will be faster to do it myself than show someone else’ or ‘they don’t have the experience’ or ‘they don’t have the time to learn’.

In a project the can’t is often true at the beginning. The project is making a major change and only one expert, or the sponsor, knows what the actual outcomes look like. There are two ways I see of dealing with this.

One is to do the upskilling while the project is executing. You involve the team with the experts so they learn the technical differences and develop the new processes. This can increase engagement and adoption, but it will slow the project down.

The other way is to have the experts develop the new processes and then apply change management, training and support at the launch. This can move the project along faster,  but will make the post implementation support longer.

What do I think is the best choice?

As usual, there isn’t a best choice. If you have a legislative deadline your ability to slow down the project to bring everyone up to speed is constrained – deadlines don’t move! So, you use the experts and manage the learning curve.

If you have any ability to move a deadline, I like bringing people along throughout the project. It minimizes the likelihood of the solution failing after the experts leave and maximizes the probability of long term adoption of the solution.

What are your thoughts?

A few interesting links

About. com

neen james

ezine articles

Communication – why is it so hard?

Sunday, October 4th, 2009

I’ve been looking around at blogs for inspiration for today’s post. It seems like communication is a popular topic for bloggers. It is a complex topic with plenty of aspects for thousands of blog posts, even though it sounds simple. How hard is it to be clear, paraphrase for clarity, follow up, listen… and all the other tips people have out there.

Well, the answer is, it’s hard because everyone has buttons that set them off, some people know how to control their own buttons, some people don’t know what their buttons are so they always seem to be going off on an unexpected direction. It’s hard because we don’t communicate in a vacuum; the pm’s voice is only one of many the person is listening to at any given time. And, it’s hard because the project priorities are not the only priorities the person has, often work priorities get drowned out in personal priorities.

Yes, so it’s hard, but you can’t give up. You are a PM; if something isn’t hard, it’s not worth doing. You are super leader, problem solver, communicator, change manager, and there is no kryptonite excuse.

Communication never gets easy. If you think you’ve figured out the team, or the person, you are living in an old paradigm. The expression, the only constant is change, applies to people too. As soon as you find success in working with a team, something will change; you need to keep your spidey senses pinging the environment and adjusting your style to accommodate the needs of your team.

How do you do this? Well, the steps are pretty simple. You need to be clear in your communications, you need to paraphrase, or ask them to paraphrase to ensure common understanding, and you need to follow up.  The caveat to this – aka the first complication – is that you need to do it without coming across as a micro manager.

Complication #2 – you have to understand your own emotional triggers and control them. Just because you’ve told this person four times how to present the status of their work package, doesn’t mean you can snap at them on the fifth time. Their functional manager may have asked for different information and confused the issue.

Complication #3 – rumors can confuse the message. The worse situation is when you need to have the team pull together to meet a deadline and the rumor mill is buzzing with information about your project being cancelled. You can’t control the rumor mill; you can be clear and constant about the truth, as you know it.

Complication #4 – things change. You may have just informed your team about a key decision that impacts the budget, scope or resources on your project, only to have your sponsor tell you the decision has been reversed, deferred, or otherwise changed. Now you will have to re-communicate to the team.  Which is a nice lead into…

Complication # 5 – people don’t trust that the message won’t change. This lack of credibility can cripple a communication plan. You need to figure out how to deliver messages that change or seem to conflict with credibility and confidence. It may sound impossible, but functional managers do it all the time. This is where your ability to be confident and honest in communicating is put to the test.

Here are some links to article on communication.

Communication styles

Communication Styles at Work

Effective Communication

Are you sure you trust the effort estimation?

Sunday, September 27th, 2009

To be honest, I often found myself questioning the reality of the estimates when I started my career in project management. The process wasn’t well managed – there was no consistent process to manage. What often happened was the work package lead would estimate the work to complete a deliverable, or a milestone, and base it on their experience doing the work. That approach goes sideways quickly when they are basing it on having done the work a year ago, or more, and under different circumstances. When the estimate is built this way and you run into delays, you often hear the technical people say, “duh, the estimate was way too optimistic.” It may make you want to scream, but screaming doesn’t help – well maybe for the duration of the scream it will. What the PM needs is a realistic estimate of the effort and duration so that they can manage the deviations from schedule rather than have to micro manage every activity and milestone.

First, let me guess at the process the work package leader goes through to self estimate. Step 1 – when I did this kind of work it only took a couple of weeks to perform this kind of task.  Step 2 – things are easier now, so it shouldn’t take as long let’s say a week. Step 3 – … no step 3.

Now what would I like the work package leader to do? Step 1 – identify the person who will do the work. Step 2 – talk to that person about the effort involved. Step 3 – put all the effort estimates against the activities and review with the work package team for reasonableness. Step 4 – make the updates (there will be updates). Step 5 – present a worse case, best case, likely case estimate.

Why is there a gap between what the PM wants and what the work package leader does? There are as many reasons as there are people involved. Here are what I think are the two reasons that can be changed to help improve the reliability of the schedule.  And, that’s all we really need, right?

Number 1 reason for the gap…….. lack of communication of expectations. As the PM, you need to communicate what you need from people. When you ask the work package leader to develop the estimated effort and duration, tell them what process you expect them to follow. In an organization with a clear and communicated methodology that includes an estimating process, you need to remind the work package leader to use that process. Don’t have an estimating process? Communicate what you need as though there was a process – enough success in estimating will create a de facto process. Don’t like the process that is set up? Communicate what you need based on the agreed process and the lessons learned from other projects. Work in an organization that values seat of the pants heroics – get out if you can; you’ll only be frustrated – okay really, communicate what you need and the benefits to them that come from having a realistic schedule. Do you see a pattern here? Communicate based on what you need them to produce.

Number 2 reason for the gap…… cultural issues that support “fire, ready, aim” or lack of attention to planning. This is a much harder nut to crack. If the culture is acknowledged as ineffective then you have a chance to prove the value of proper planning but you’ll be fighting an uphill battle until you have successes to point to for proof of your approach. Until then, you have the undesirable job of pointing to failures and offering opportunities. If the culture isn’t acknowledged as ineffectual or even celebrated as innovation and creativity… get out?  Obviously, that’s not the best approach. You need to examine the reasons why a corporate culture would see this as success. Have they been successful but at high cost – a common outcome of this culture – approach it from a “let’s be more successful” approach adding metrics for efficiency. Or, is it a fear that process and structure will stifle creativity or innovation? This one is more of a gut feeling culture. You might want to approach it in a “process and structure free people to be creative” approach.  Michelangelo didn’t just slap paint on the ceiling; he worked through a process so that the painting on the ceiling part was as simple as possible. A more current metaphor for structure – you don’t create a good website by getting a domain, host and then sticking some pages up. You have a process to develop a good website.

It comes down to this, you can be successful if you don’t have a schedule, it will likely take a lot of crisis management and overtime, but you can’t sustain the energy or engagement of the team over the long term. With good planning and estimation, you will still have excitement in your project (don’t we all like that part of project management?) but you will also have a way to alleviate anxiety about the project and more confidently predict outcomes.

There are plenty of workshops and sessions on line about best practices for estimating. Add your comment about a best practice you have seen, or used.

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.

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)