Posts Tagged ‘project challenges’

Issue management or Firefighting

Sunday, February 14th, 2010

The challenge for Project Managers is to keep the project moving through challenges – or identify when the project shouldn’t keep moving forward. If the PM is skilled in issue management they can navigate the daily issues (or hourly issues) on any project. If they aren’t as skilled, the project goes into firefighting mode.

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?

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

Is a list of tasks enough of a plan?

Sunday, December 13th, 2009

When projects struggle with planning sometimes the teams create lists of tasks. To add detail, the lists contain names of people, they estimate how many days are needed for each task, and even list beginning and end dates. So what’s the problem?

If the project is simple and requires a small team of knowledgeable experts, this will probably be enough. I’m a supporter of doing the right amount of  planning rather than completing all the steps and forms.

The problem is when the project is complex. In one of my past projects, the team struggled with the concept of planning. I proposed the process of pulling together a team to plan and spend a day or two for the whole process. At the end we’d have a list of sequenced activities with clear milestones and a resource estimate.

Thinking it would be easier, the team leads sat down and started listing tasks and names. In their defense this was a project that required specific expertise and having the experts do the wbs would be a good approach.

Top three problems with the approach.

No milestones, no deliverables. The list of tasks didn’t lead to a clear deliverable that could be tracked. The team lead was never confident that the tasks listed were complete.

No understanding of overall resource usage. While we knew that Joe had to work a total of 12 days between start and end dates, it was difficult to align the start and end dates of each activity to make sure that the 12 days wasn’t actually over a 3 day period.

No clear reporting ability. When it came to reporting to the steering committee we had to manually pull the information and come to a consensus about status each time.

As a bonus problem – time! Originally I estimated a couple of days for the whole project activities list. It took a week for one part of it.

It’s one of those things that I think we as PMs struggle with all the time. What ideas do you have for selling the client on the process?

Planning, why is it so hard to sell

Sunday, December 6th, 2009

In the theoretical world it is sound practice to plan before you start anything. In the real world it seems so difficult to see beyond the next milestone or the next deadline.

Some projects seem to lend themselves to crisis planning: how to get to the next deadline, the next presentation, the next milestone. It seems to me that it feels easier to see the future in small increments.

Why do I think this is a problem? After all, lots of projects go well this way. Well, what about engagement? What about alignment? And, what about costs?

Engagement is difficult at the best of times; we all know people don’t like change. Even if your project is bringing non-negotiable change, like legislation, then resistance may be futile, but it still happens. By dropping changes on desks or asking for help on a two week or one month basis, you aren’t doing much to engage the people affected by your project. Engagement in the best of times comes when people are involved at the right time for the right things. Could there be a more right time than at the beginning? When people get to step back and look at the whole picture?

Alignment can suffer from short term views. Decisions may get made that resolve the current issue but slide a bit away from the overall goals; if that happens on a regular basis you can find yourself delivering completely the wrong thing. Expediency overshadows long term solutions.

Costs are hard to control when you only see the next milestone. Think about Christmas shopping. How many people overspend at Christmas because they had no plan? Just sitting down in November and making a list of people and potential budgets can make the difference between getting great presents within budget and breaking the bank.  Taking the time to look forward to the end of the project can allow you to anticipate what budget and resource draw is needed for success.

What are your thoughts?

Project data base for questions and answers

Sunday, November 1st, 2009

I received an email tell me to check out askaboutprojects. I’m naturally suspicious of unsolicited emails but then I looked closer, the email had come in response to my latest blog post – yay, someone is reading my posts.

I took a look and I’m impressed. This is a site where you can ask and answer questions about project management.  The questions are all over the board and the answers range from a quick sentence to a detailed instructional message.

This might end up being a common source for lessons learned, a place to hear about new tools and ideas, or a great place to find answers to your common frustrations.

Here are a few samples:

Does it help to use a software to create the WBS

Four PMs gave answers about software and how to do a WBS.

If you had to hire a project manager to work with you which would be your top 5 requirements

A couple of interesting answers there now, neither had certification on their list.

How do you prioritize your tasks

Great ideas posted in answer to this one.

It seems to me that it’s common to hear PMs ask for the best way to develop stronger skills and improve their delivery and approach project after project. Ask About Projects seems like a great place to start.

Leave a comment if you have any thoughts on this.

Dirty little project management secret

Sunday, October 18th, 2009

Project Managers sometime fly by the seat of their pants. Okay, now it’s out in the open.

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.

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.

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