If you can’t figure out how the positive people are feeling, you will focus on the verbal negative people.

Good luck

Perry

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

I find this one to be the most interesting challenge, and the one linked tightly to corporate culture.

Sometimes it’s a good idea to go ahead with some of the project while you wait, and other times, delay in decision making is a sign of trouble brewing.

Sometimes the corporate culture is ‘just do it’ and sometimes it’s about careful analysis before acting – and usually somewhere in between the two extremes. If your organization leans towards the ‘just do it’, you need to get an idea of the direction and then go forward. If your organization leans towards the analysis scenario, you need to get documented agreement to go forward before the decision is complete.

How does the PM know which scenario is true for their project?

History will help, what has happened in previous projects when decisions are delayed? Your sponsor will give direction to help determine what to do. And the way the team reacts is also a good indicator.

If you determine you can go ahead while waiting for the final decision, there are some ways to ensure you are doing the right thing. First, your sponsor needs to be on board with what you are doing. And second, develop a way to document both the reasons for going ahead and the implications.

How do you determine what to do? That’s probably the easiest part. Look at activities that need to be done regardless of the decision. Can you start drafting risk plans, communication plans, or resource plans.

Can you develop marketing plans? Will the decision have an impact on the way you’ll market the product?

Can you analyze some potential solutions?

The overall question in this circumstance is depended on the decision you are waiting for. If the decision could determine whether the project goes forward or not, or is a fundamental decision about the product features, you probably don’t want to use resources of any kind because the risk of wasting resources is high.

If the decision is a refinement of the features, or a buy/lease decision, there are a lot of activities that can be done to move the project forward while you wait.

Happy PMing

Perry

Well, we know the answer to that is at least two sided. First, they need the skills and then they need time. Department managers learn to put out fires and ‘deal’ with problems. They don’t achieve success by keeping their boss informed of problems and challenges and they don’t necessarily provide periodic status reporting. And, they have day jobs. They can’t set aside their day job to do a project.

The reality right now is that operations and projects are getting mixed together. Whether that can be successful in the long term is questionable, history doesn’t predict that it will be, but I think in the short term, there’s a way to support businesses through successful project delivery.

Some project managers who go the self employed route set up as contractors. They go in and do a great job managing a project and then they get out.

Others go the route of consultant. They may still go in to do a project, the difference is that while there, a consultant will look for opportunities to improve processes, set up new ways of dealing with projects in the future and leave lessons behind purposefully.

From a perspective of the business, project management contractors fill in shortages of capacity. Too many projects for a short term to complete with internal leadership. As the company grows, some of the contractors will be invited to become permanent employees.

For the business person, a consultant will suggest changes to improve, streamline, and change, the business processes to increase capacity of the internal team. As the company grows, consultants are asked to do more of this work and may temporarily fill a gap in competency.

The world needs both, contractors and consultants, as much as it needs employees. The key to success for the project professional is to know which you are, consultant or contractor. The key to success for the business person is to know what you need.

Have a successful week.

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.

Some PMs do this all the time. They like the rollercoaster ride, they love the heroics and they see creativity in the pressures of the deadlines and drama.

This approach can be successful depending on the culture of the organization, and the complexity of the projects. Low complexity projects can be successful with a pantser approach; high complexity projects can’t always (I’d say more like can’t ever) be successful this way.

So let’s think about a big complex project and how pantsing can work, or not work.

Can work – in unforeseen risks and issue resolution. You can find creativity in groups when you start with “so what might we do” rather than “what are the main strategies we can apply to this issue?”

Can’t work – if it’s your main risk strategy. You will have risks that you identify and can’t think of a strategy – the strategy becomes, we will try to figure it out if it happens. If all your risks have this strategy you are going to burn people out and destroy your credibility.

Can work – when you are trying to create a new and innovative product or service. When gathering requirements for your product, you can engage the stakeholders in free form sessions of what might be possible.

Can’t work – when your project has complex regulatory requirements. You need to have controls and a clear direction to meet all the requirements. You can’t figure them out as you go along.

Can work – when you are trying to find a way to recognize and reward people. It’s fine to figure out fun things to do at milestones. It can bring the team together to create an on the spot celebration.

Can’t work – in resolving conflicts within the team. You need to have a consistent and clear approach to managing conflict. It creates trust within the team if they know how things will be dealt with.

Tell us about your thoughts on planning v spontaneity.

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

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.

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)

At the beginning of your project you go through the process of developing your list of stakeholders, some of us even go to the next step and analyse the strategy for managing stakeholders. What doesn’t always happen is a refresh of the stakeholder list and plan as things change in a project.  So, no wonder you suddenly feel like stakeholders are popping up every time you turn around as soon as something changes.

I can think of a lot of examples where this has happened to me.  Any number of projects looked like they had little or no impact on the Marketing team, for example, until the scope changed to include not only regular customer updates, but also a special communication about a new project deliverable. The Marketing team did a great job but I needed to make sure they didn’t feel ambushed with the change. I’ve had the Technology team suddenly get excited about changes to the infrastructure or architecture areas long before the sponsor signed off on a scope change.  I’m sure you can come up with your own examples of stakeholder triggers beyond scope change and rumour mill.

Putting aside the fact that some stakeholders don’t pay attention until the project has a real impact on them; I call it organizational denial when people don’t recognize how interrelated everything is in a company. Here are some tips to minimize the surprise.

Set up a meeting with your team leads and specifically review the stakeholder management plan, just the same way you do with the risk management plan. You do review the risk management plan don’t you?

When there is potential for a change in stakeholders, set up a meeting with the person who leads that team. This can be a new stakeholder or an existing one where the impact has changed substantially.  Remember the new stakeholder will need to be brought up to date from the beginning of the project – don’t assume everyone knows what your project is about. I’ve had major cross-divisional projects that people were not aware of when I met with them.

Don’t assume you’ve always identified the stakeholders by going through a scope statement. Use your organizational knowledge to think about the people who might make themselves stakeholders. There are always people in the organization who don’t agree with the use of resources for your project; sometimes they have a project they think takes precedent and sometimes it’s a principle thing. Think about who might be threatened by the success of your project – is there any area that might lose staffing levels. Is there someone who’s pet project was declined, will they start putting up obstacles for you?

The important skill to remember with these stakeholders is you have one mouth and two ears. These people are usually not out to get you, they have something important to contribute. If you listen and clarify any misunderstanding, you might gain an ally from a potential blocker.

Here are a few links that might be interesting:

Mind tools – an article on stakeholder management and a tool to use – a good community to join

Project Smart – a UK site with great information on stakeholder management

Wikipedia – definition

Max Wideman pm guru, it’s not the prettiest site but it’s practical