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

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

I’ve worked on four successive credit union mergers and each time we developed looser success criteria. The reason we did this is integration and success on mergers is complicated and we found the tighter we tried to control it, the less successful we became.

At the beginning of the project, you may not know enough about the technical integration details to develop success criteria. I’ve found it much more useful to start with guiding principles and develop success criteria as knowledge grows.

The integration of the people is somewhat easier to plan – harder to achieve success. The key parts are communication, training, communication, training and transparency – oh, and communication.

Trying to achieve smooth people transition is a false goal. If you acknowledge that there will be challenges and hard times, it builds perspective. The difficult times will be difficult, but no one is measuring them against false promises of easy transition.

Guiding principles can be as simple as – minimize customer disruption, maximize employee involvement, transparent communication.

What this means is that you begin to set success criteria when you know enough to set realistic ones.

As and example, our transition date for the banking platform data was a key criteria.

By setting the date based on executive wishes,

• we had to make changes to the date,
• we had to reschedule training,
• we had to re-communicate information to staff and members and
• we had to work the team long hard hours.

By setting the date based on analysis of the banking platform, we were able to

• pick a date we could stick to
• initiate structured training and change management
• clearly communicate the progress, and upcoming milestones
• clearly communicate to the membership what was happening
• identify innovative approaches to meet the guiding principles
• let the people who were leaving know the date they could go on to their new journeys

Does anyone else have tips for project managers on mergers and acquisitions?

The dream of gathering absolutely complete requirements is just that, a dream.You will find no matter how detailed or complete, or ‘approved as final’ your requirements are, things will change. That isn’t a failure of the requirements, it’s a fact of project management.  If you try to perfect the beginning, you’ll never start your development or build phase.

If there is no element of uncertainty, I don’t think you have a project.

The PM’s job is to manage what happens: issues, changes, delays, opportunities. Doing a great job of gathering requirements only resolves the questions at the beginning of the project. The client or stakeholder, or sponsor will have new ideas as they get new information. The market demands change. The longer the time frame of the project the more likely you will have changes.

Doing a great job of gathering requirements is only one part of the project start. You need to develop your scope change management plan as well. That plan will include your process of assessing changes against the project drivers and making recommendations.

A good scope change plan will help the PM manage ‘pet’ ideas as well as fabulous ideas that everyone loves but will have a significant impact on the time, cost and quality of the original project.

Happy PMing

I’ve been chatting with clients over the last week and I think I now have an answer – at least for me, your answer might be different.

I take the complex and simplify it. When my client says “it’s a lot of work”, I get excited. I can take the ‘lot of work’ and make it manageable. I love doing that!

Yes, I report on status, I manage issues and risks and I communicate and support others in communicating. But, what I do first, is simplify. I remember a book I read on consulting that answered the question ‘how do you eat an elephant’ – one bite at a time.

So, I take the elephant and I carve it into bite sized pieces. I pull the overwhelming list of activities out of my client’s mind and give it back to them as a schedule.

What’s your answer to the question “what does a project manager do?”

Happy PMing.

So, how do you know? As the PM how do you recognize the difference between firefighting and issue management?

What does issue management look like?

No matter how fast the issues come, the PM and the team can assess the issue against the goals of the project and prioritize the use of resources for resolution. The PM can make the distinction between real issues and things that will go away if you wait.

Issues are resolved based on the long view – the desired result, the alignment to strategy, the market place. Any number of criteria that drive the project. The PM knows what the project drivers are. What takes precedence, cost, time, or quality? Recommendations are aligned with that priority.

What does firefighting look like?

Issues come fast and frequently. The same issue keeps rising because it’s not resolved completely. Issues are resolved on the approach of “how do I get this out of my face’. There’s no consistent priority of resources to the issues. People are pulled from one to the other issue, working on the latest problem before resolving the current fire.

Projects overrun schedule and budget and don’t often meet the quality. Scope creeps, customers are unsatisfied.

So, Perry, don’t hold back say what you really mean.

I’ve been in both situations. In the firefighting project, the team was so stressed that I joked about having a counselling shingle hanging outside my door. No one ever knew they had done the right thing. The project was a success but at the cost of 12 – 14 hour days and quality all over the place. There was no clear understanding of what the criteria were for meeting a compliance standard. As a result, time, energy and money were spent meeting the highest overall standard when we only needed to meet the specific standards.

In a similar project that used an issue management approach we met the right standard, with fewer people and money over a shorter time period.

There were fewer real issues, and we knew how to deal with the issues that would go away with time.

In my experience, the keys to avoiding firefighting lie in the initiation and planning of a project. The PM and the sponsor need to clearly determine the priorities on the drivers to allow the project team to produce aligned recommendations when issues need to be resolved.

Clarity between the PM and the sponsor on decision making authority can alleviate the effort required to resolve issues as the project proceeds.

Close and frequent communication with the sponsor at the early stages of the project will build a level of trust between them. When there is trust between the PM and the sponsor, things go smoothly – well as smoothly as a project can go.

What is the one thing you would advise a PM to do if they want to get a better handle on issue management?

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.

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

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