Early Indicators of Project Trouble

A slipping schedule, lack of engagement, and cost overruns are common and easy to spot indicators of project trouble. Here are five other early indicators of trouble that aren’t often recognized.

Team member hours are less than planned. Hours dedicated to project tasks can fall short due to differing business priorities or lack of confidence in the project direction. These shortfalls often start early and get worse as the project continues. Check the actual hours worked by team members. If those hours fall below plan, find out what’s going on to see whether there is a problem.

Stakeholders aren’t arguing (when they should be!) Stakeholders often have different opinions about project requirements, priorities, or the solution approach. If stakeholder response to projects requests is lackluster, hidden dissension may be present. Ask your stakeholders direct questions about their concerns. This helps you avoid problems before it’s too late to change priorities or direction.

Inadequate sponsorship is in place. An effective sponsor must:

· Have access to funds

· Control areas where the project will create process change

· Secure team members for the project

· Be able to establish project-related business priorities?

· Have time to be the sponsor

Sponsorship inadequacies can create project delays and arguments. If this happens, encourage management to form a sponsorship committee. This can help cover the authority needed to guide the project.

Requirements address “what to do” and not the business problem. Requirements often convey how something is to occur. An example is “Reconfigure the mail room business processes.” What’s the intended outcome? Is it a desire for fewer people, or is mail processing taking too long? Is automation to support mail processing working as hoped? Requirements that don’t specify the actual business issue are a problem. Projects that satisfy these inappropriate requirements might not fix the underlying business problem. Ensure that every requirement focuses on the real issue. Perform business analysis to figure out the best options to address the problem.

Requirements and deliverables are validated with the customer and NOT the end user. Let’s start with definitions. The customer is the person who supplies requirements and reviews your deliverables. They sometimes provide funding. The end user is the person or group who will use the deliverable regularly. What if the end user and the customer differ? For example, the customer and end user are different when a project is creating a product for the marketplace. In this case, validate requirements more thoroughly. More testing might also be appropriate. Extra validation and testing can be time-consuming and costly, but it is vital to success.?

If you have experienced other situations that cause problems early on, share with us in the comments section.

For more about identifying indicators of trouble early on in the project management process, check out my Project Management Foundations course.

Coming Up

I’m almost done updating Project Management Foundations. In a few months, you can look for the updated edition, which includes some info on PMBoK7 and other changes.

_______________________________________

This article belongs to the?Bonnie’s Project Pointers newsletter series, which has more than 14,000 subscribers. If you like this article, you can?subscribe to receive notifications when a new article posts.

Want to learn more about the topics I talk about in these newsletters? Watch my courses in the LinkedIn Learning Library and tune into my LinkedIn Office Hours live broadcasts.

_______________________________________