Posts Tagged ‘project challenges’

Using your lessons learned. How to make the next project easier

Sunday, August 8th, 2010

We all know the value of using lessons learned from other projects,but how often do we get to use them?

What gets in the way?

I know it’s often difficult to find the lessons learned on any project, let alone a project that is comparable to the one you are about to start.Time,or lack of it, often gets in the way of thinking about any lessons you might want to implement in your new projects. And, organizational assumptions can seem like a barrier to making changes: “we’ve always done it this way and there’s really no way to make it better in this company”.

What I suggest is to take a small step. If you don’t have time to read up on previous projects before you start, build it into the kick off meeting. Ask the team what they think is the one consistent challenge on projects. Use that to try some new tools, tactics, or techniques.

If the team decides that requirement gathering is a consistent challenge, why not try a new approach – maybe moving from one on one meetings, to a series of large group sessions that get refined in one on one sessions. Or, maybe checking where you start requirements, if you attempt to get requirements all at one time, try iteration techniques.

If the team decides it’s communication with stakeholders, how about looking at how the communication normally flows, and bringing something new to the process.

You’ll have different issues depending on your organization. By trying one new thing, and including the team in developing the new method you can take small steps that improve the project performance in your organization.

Any other ideas on common lessons and new approaches?

Happy PMing

Perry

Making decisions, the project manager’s challenge

Sunday, July 25th, 2010

Often the project manager is in the middle of a push and pull about decisions. Everyone wants to get started, but key decisions aren’t made. How do you keep everyone engaged when this is happening?

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

Communication Plans, the key to project success

Sunday, July 18th, 2010

It may be too much to say a communications plan is the key to success, but certainly not having one is going to cause everyone much unneeded stress. This communication plan is not the internal plan of status reporting, issue resolution and periodic updates, it’s for your stakeholders whoever they may be.

If you have never created a communication plan, here’s the short list of things to consider;

  • start with a strategy – what are you communicating
  • create an objective – what are the concrete goals for the communication plan
  • identify your audience – there may be several different groups
  • develop the key messages – the key messages usually are the same no matter how many audiences you have
  • identify the communication channels
  • deliver and assess

Now that you have your plan, and you are working the plan, let’s talk about what benefits you will see.

When you are communicating the right information to the right people, in the right way, everyone has the opportunity to understand the project. Note, I said they have the opportunity, not that they will understand. For the people who still require help you also have consistent messaging to use.

When you focus on communication it becomes easier to find your audience and align the messaging. If there is no plan for what and how to communicate, often you find yourself pulling communications together on demand and finding the closest channel rather than the right channel.

Planning early for communication allows you to set measures for communication success and that allows you to adjust the communications if it’s not meeting the objectives.

Having a schedule to communicate can sometimes help meet a goal or get a decision tied down. Why? Because when you have a plan your driver is to get information into the communication. When you don’t have a plan, there may be no driver, and communication gets delayed rather than driven.

Do you have any thoughts on communication planning?

If you would like a template for a communication plan, send me an email, and I’ll forward one to you.

Happy PMing

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

Informal Communication, the one key project tool

Sunday, March 28th, 2010

The value of communication for the project manager goes beyond the communication plan. It is the one key success tool for any PM.

In the communications plan, the PM and sponsor agree on the basics. They identify the frequency and form of the status reporting, and may include informational communication to the stakeholders, clients, end users, media, community, you can probably think of a slew more.

What isn’t in the communications plan, and I’m not sure how you would put it in there, is the informal communications. The elevator conversations, the water cooler sound bytes, the hallway decisions, you know what I mean.

Even if you can’t document how you are going to deal with the informal communications, you need to talk about it.

One topic to discuss with the sponsor and the team is key speaking points. Throughout the project, people will ask you and your team ‘what’s the project about?’ If everyone gives a different answer, it can dilute the message and drop your project down the visibility and priority scale. If everyone says the same thing, in their own words, your project comes across as focused and well thought out.

Another question that is more difficult to ’script’ is “how is your project going?” The reason this is difficult is that the answer will be different for every person. To use an IT project for simplicity, a business analyst who is struggling to get requirements from a client, may see the project very differently from a developer who isn’t yet engaged in the work. The optimistic sponsor will see things very differently from the QA tester.

I’ve found that the best way to get a clear message out is to communicate perspective to the team. For the sponsor, who sees the big picture, they need to understand it’s normal to have challenges at the detail level and that they don’t need to act if someone hears from QA that there are problems.  The end user who might be going through a difficult learning curve, needs to hear the end goals to give them perspective.

There are other communications that need to be considered but it’s important to keep in mind that the communications plan is only the beginning of the project communication. The project manager who doesn’t pay attention to all communication will find themselves surprised by what people think or what they say.

Happy PMing

Perry

Earning PDUs – Free

Sunday, March 21st, 2010

Hi, those of us with our PMP designation know the  PDU stress. Some leave it to the last minute, some gather PDUs over their three year cycle. But, whatever approach you use, you can pay for them in money or time.

Money can be as little as the cost of your chapter event. PMI West Coast chapter has monthly events, lovely dinner, great speakers, and 3 PDUs for $45. Or as expensive as a PMI seminar. Great workshops, fabulous advice, and usually a great location. Moneywise, cost of event + cost of hotel + cost of travel = expensive.

Time can be based on volunteering, writing articles or books, or simply doing project management work.

At the West Coast chapter event this week, I heard from a fellow PMP that he was running out of time. He has 3 PDUs and 6 months to get the other 57. I suggested he write an article for the chapter newsletter. Something he hadn’t considered.

If you write a blog, you already have at least the start of an article. I created an article for ezinearticles.com from a blog post about estimating. This site is great for building your credibility and driving traffic to your website.

Most SGIs have newsletters and will be happy to include articles in an issue.

Have a great week of project management.

Gathering requirements is it ever complete?

Sunday, March 14th, 2010

This blog post was inspired by a post on LinkedIn

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

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?