Overcoming Common Project Issues – Part 2

No matter how well you plan and no matter how organized you are, there are still some common problems that can rear their ugly heads and try to derail your projects.  Sometimes, no amount of lessons learned sessions will get you past these issues, so we need to examine them further and discuss ways to eliminate them or at least minimize their affects.

In Part 1 of this two-part series, we discussed the first five of ten problems commonly experienced on projects.  In Part 2 we’ll dive further into these issues as we examine problems six through ten.

#6 – Communication with top management while the project is underway is not effective

How do you handle the problem of poor communication with top management? Even when you make the effort to keep the lines of communication open, management may simply fail to keep you up-to-date on priorities.

Your solution: You cannot force top management to improve their communication skills, but you can do your best to present status reports, ask for continuing definition, and convey information to the top—even if your only avenue is the interoffice memo. If you can’t even get an executive to take time for a brief meeting, chances are your communication link will suffer. You may find that management does not respond to your requests or suggestions, fails to confirm project goals, and offers little support; but when the project is completed, you are told that “this is not what we wanted.”

In most cases, management wants to support you, and will try to maintain morale. So even though the problems seem formidable, if you make an effort to communicate, they can usually be resolved – even if you have to train top management in the development of communication skills!

#7 – The schedule is difficult to control

Coordinating the many ongoing efforts of your team members and successfully completing many different phases within the same limited time period may be a struggle. If so, examine the method you are using to develop and control your schedule. You may have to invest more time in developing a detailed network diagram and showing team members how to use it as a control document. Most instances of scheduling control problems are created by a lack of preparation in creating the schedule itself.

Your solution: Revise your methods.

#8 – Deadlines are not being met, and projects are completed late

You may have an excellent process for schedule control, and team members are working well together. But in spite of that, you simply don’t meet phase deadlines, and projects aren’t completed on time.

Your solution: Allow more time, or increase the size of your team. Your schedule is not realistic, and phases cannot be executed at the pace built into it. You may have been forced to accelerate your schedule because management imposed an early deadline. When you first organize your schedule, the realistic completion time will be dictated by the scope of the job. If the final deadline is unrealistic, convey this fact to management, explain why there is a problem, and ask for a later deadline or a larger project team.

Read more »

Overcoming Common Project Issues – Part 1

Even when you organize and lead your projects well, there are still some common problems in the project management world that you may continue to run into on your engagements.  Learning how to effectively deal with these recurring issues will both improve yourself as an effective project manager and also increase your chances for project success.

In Part 1 of this two-part series, we’ll examine the first five of ten problems commonly experienced on projects.

#1 – The team doesn’t work well together

When you struggle to create a team but don’t succeed, first examine your own management style. Do you truly offer team members an opportunity to participate? Or do you discourage them from speaking out, offering ideas, or suggesting changes? Teams work only when you encourage participation and then follow up on it.

The problem may also be caused by excessive diversity in the team. If you have the chance to pick your own team, try to limit as much as you can the involvement of a large number of other departments. Projects often demand help from people other than those you supervise directly, but it is not always necessary to strive for participation beyond those resources you absolutely need.

#2 – Other managers resist having their employees recruited to your team

You face a formidable task just in getting cooperation from other department managers – no matter how diplomatically you approach them or how well you define and explain the project. To solve this problem, you will need to convince the other managers that their priorities will be respected.

#3 – Management skills that work in the department don’t seem to work on the project

Be aware of the important differences between departmental and project management. They often require different levels of supervision and leadership. In fact, skills that work for you as a department manager may interfere with team participation, so you will probably need to develop a completely different approach to supervising the project team.

Read more »

June 2010 PM Survey Results – Managing the Project

My apologies for breaking this survey into two parts – I don’t think I’ll do that again.  The responses to parts 1 and 2 were uneven, but it didn’t seem to affect the overall findings.  There were still enough responses to each to make the numbers meaningful.  For the purpose of this analysis, I’m going to combine everything as if it were one complete survey.

Characteristics of a good PM

The first question dealt with the survey responders’ concept of the #1 characteristic of a good project manager.  Not surprising to me at least, 52% responded that the project manager needs to be a Good Communicator.  In fact, Good Communicator far outdistanced everything else.  Experienced Leader garnered 22% of the responses.  Wise Decision-Maker came in third at 12%.  11% of the responders selected Organized Professional and 3% wrote in Integrity as being the top characteristic for a good project manager.

Primary causes of project failure

According to our PM Tips readers, the biggest cause of project failures from their experience has been Poor Communication – as selected by 40% of the survey responders.  26% selected Poor Requirements/Planning as the top contributor to project failures.  15% selected Poor Project Leadership.  11% indicated that Lack of Senior Management Support was the top contributor to project failures.  6% attributed project failures to Untracked Issues/Risks.  And finally, 2% wrote in that Poor Project Governance and/or Role Defintion was the top contributor.

Conducting lessons learned sessions

We all know that lessons learned sessions can be valuable for all participants going forward – whether the project was a success or not.  But do we actually conduct these sessions?  Yes and no.

The numbers were high at both ends of the spectrum.  57% of survey responders either Never (19%) conduct them or conduct them less than 10% of the time (38%).  Conversely, 34% said that they conduct post-project lessons learned sessions more than 50% of the time.

Read more »

Should Requirement Quality be Measured?

Measuring requirement quality can reveal opportunities for long-term improvements in requirement definition, can show you where to invest for improvements, and can help you develop your team.

Opportunities for improvement

If requirement quality isn’t measured, there will be no future improvement in requirements. Every project – in terms of requirements quality – will be a rerun of the last project. No lessons learned. No forward progression.

Did your last project have rework? Were there any crisis situations in testing? Were there customer complaints? A review of the last project’s requirements may show you how to avoid some of those same headaches on your current and future projects. Read more »

Five Key Steps to Closing Down the Project

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

A lot of text and attention is given to how to start projects, and how to run projects. But process of properly closing down a project is overlooked. Why? Well, since I can say from experience that I’ve been guilty of this in the past, here are my reasons, at least:

• Implementation and transition to support happened so moving on seems reasonable
• Have 4-5 other projects I’m also managing
• Just received a new, hot project and I’m preparing for kickoff
• Problem-free implementation means no worries, right?

Look at that list…none of them are good excuses for just basically dropping the ball – and the customer – post-deployment. Things still need to happen, proper hand-offs may still need to be taken care of, information needs to be transitioned. It will happen anyway through frantic phone calls and emails, so why not take care of it in an organized fashion? Because we say we’re too busy…but that needs to change.

Here are my list of five key activities that should happen to ensure proper closure of the project you’ve just finished. Your list may differ and I’d love to hear from you if it does. Feel free to comment and share with our readers here on PMTips.

My list:

• Make sure all pertinent documents and deliverables have been signed off by the customer. You don’t want this coming back to you after the project is over – especially if there are any question marks our payments outstanding.
• Get a final signoff on implementation/solution acceptance. You may have the best relationship in the world with your customer, but don’t skip this step.
• Conduct a lessons learned session with the customer and your team. The information you glean from this type of session can be invaluable to you as a project manager going forward, to your customer as they go forth with the implemented solution, and to your tech support as they provide the ongoing support for the solution with the customer.
• Hold a proper handoff to tech support. Make sure they have all necessary information in order to properly support the client post-deployment.
• Keep in touch with the customer post-deployment. You may have a 30 or 60-day agreement to remain available to the customer and for your team to remain available before the formal transition to tech support. But don’t just drop them at that point, keep checking back. It’s good for your reputation with the customer and for your company’s reputation.