Five Indicators that Your Project May be in Trouble

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.

The world of project management is not always black and white. Sometimes that’s good and sometimes that’s bad. Actually, there are some things that are cut and dried….

• You’re project budget is either green or red
• A milestone is either met or it isn’t
• A customer either accepts a deliverable or they don’t
• You either get to keep your job at the end of the engagement or you don’t

However, so many things in the PM world are not that clear. And you have to learn to look for the subtleties at times to gauge certain things about your project, your customer’s satisfaction level, your team’s focus, etc. New project managers won’t be there yet. Experienced project managers learn – over time – to look for certain indicators that will help tell them how things are going, how the project is being perceived, and if there are some corrective or evasive actions they may need to be taking.

Here are some signs I’ve observed in the course of my career in project management that usually will raise a red flag:

• Executive management has a sudden interest in your project. This one could be good or bad – but it’s usually bad. The project may have taken on a higher level of visibility within the organization due to many reasons or factors. However, it’s also very likely that your customer is troubled by something and has contacted someone higher up resulting in this new interest. This indicates both that your customer has a concern and that they went around you as the PM and discussed it with executive management without your knowledge. Not a good sign.
• New staff has been added to your project without you requesting them. When management starts to add staff to your project – look out. They are likely putting someone senior on the project to baby-sit it and the PM. I’ve seen it happen to project managers on projects. Somehow, along the way, confidence in the PM has diminished. It may be because of something the customer said or because of activities that have been observed, but it’s not usually a good sign. Requests for resources should always come from the project manager.
• Your PMO director has started dialing in to your customer status calls. A sudden interest in your project from the PMO director when they were hands-off before may be a bad indicator. Again, it may mean the customer has gone around the PM and complained about something, but for whatever reason the PMO director is indirectly expressing concern about the project status.
• Accounting is asking you about unpaid customer invoices related to your project. This one is bad because it means that, for whatever reason, your customer has become slow in paying their bills. It’s up to the project manager to engage the customer in a discussion about the outstanding invoices and possible discuss overall satisfaction. Only two things will slow a customer down in paying their bills and both are bad – customer cash flow issues and customer satisfaction issues.
• The customer has been less communicative / more distant. If the customer has been less involved, less communicative, slower in making decisions or you’re just sensing a lack of commitment to the project on the part of the customer, it may be a bad sign. What it can mean is that the project has lost priority on the customer side. Or that it has lost funding. Or that the customer team is about to be re-assigned elsewhere. No matter what the cause, it’s not a good sign because it may mean the project is going to be slowed way down or that it is going to be canceled completely. It’s a good sign that you should contact the customer project team lead and have a serious discussion about the project direction and customer commitment to finishing the project.

The Onsite Visit Progress Report

Here’s a template that may or may not be applicable to your project situation.  I’ve only had to use it a couple of times because, in general, the regular status report will usually suffice.  The topic: The Onsite Visit Progress Report.

This type of document is not really meant for routine customer onsite visits.  I would never use it for an onsite visit to kickoff a particular phase of the project.  You could, but I believe it would be overkill as that is just routine activities and is covered both by the project schedule and the project status report.

However, if you must go onsite to the customer for some corrective-type action, then it is entirely possible that a communication mechanism such as this document may be your best way to get down in writing what you plan to do, what you actually accomplished and problems that were encountered.  This will help justify what work you performed, the hours expended, etc. as you get further down the road and need to justify budget overages to your executive management and/or your customer.

For me, it was very helpful to use when I had to take a team onsite in the middle of a the development phase to break through some barriers we were experiencing due to some requirements confusion.  It was helpful for our team to have the purposes and outcome documented, and it was very helpful for the customer and for my management to see the progress in a separate document from the regular formal status report.

PROJECT ONSITE PROGRESS REPORT

[Save file name as: client name ONSITE PROGRESS yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

TRIP OBJECTIVE

Provide a brief description of the onsite objectives. (1 or 2 sentences)

PROGRESS

Provide the progress notes from the onsite visit.

PLANNED

Provide a list of the planned activities for the next visit or to be performed remotely that have been taken away from this onsite visit along with expected completion times (List of action items to be addressed).

ISSUES

Provide information on issues encountered during onsite visit along with items to be addressed by vendor and client.

The Business Case Document

I’m trying to get on a roll providing our readers with some hopefully meaningful samples and templates of documents that may be needed on their projects.  These are templates that I created a few years ago – basically from information I think I probably found somewhere else…(isn’t that always the case?).

As I stated in The Project Charter Document article, if our readers have samples or templates they’d like to share, I’ll be more than happy to provide alternate versions of documents that I’m including here or examples of documents that I’m not covering…either will be much appreciated.  And I’m also very willing to send along Word doc versions of these templates to anyone who asks…just email me.

Here I am presenting a template for a Business Case Document.  If your customer is external, you may never see this or may never be involved with it.  If your customer is internal, it’s very possible that you’ll not only see it, you’ll be asked to help create it.  The key is to try to justify the existence of the project and the work to be performed.  The best way to do that is to show some cost/benefit analysis or return on investment (ROI).

This doesn’t have to be an extremely detailed document – leave that for the statement of work (SOW) and, of course, for requirements documents.  It does, however, need to speak very well to executive management and the key decision makers if there is to be any hope of kicking the project off.  Someone, somewhere, makes the final decision on whether or not to throw $$ and personnel resources at this effort and this document needs to convince them to approve that effort.

PROJECT BUSINESS CASE

[Save file name as: client name BUSINESS CASE yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

SOLUTION

Describe the proposed solution.

COST MODEL

ROI SUMMARY

Describe when the break-even point of the project will occur and expected annual revenue generated by the project.

PROJECT RISKS

Describe risks that may impact the cost/benefit of the project performance.

The Project Business Case

Every project needs a business case. This may be informal – especially for small and/or internal projects. It may also be very formal, as is likely the case for very large and very visible projects run for customers outside of your organization. In most cases, the customer has put together a business case in order to gain their own funding for the project. In some cases, they’ll need your help – as the project manager – in putting together the project business case and thus justifying the project and associated expenses to others within their organization.

Below is Carl Pritchard’s take on the Business Case documentation as outlined in his book “The Project Management Communications Toolkit.” I found it to be an interesting read and hope that some PMs find this of value on the projects they are working or getting ramped to work on.

The Business Case Documentation

Purpose

The business case establishes the fundamental rationale for a course of action. It is the documented history of why a project, effort, or approach was selected. It details the objectives, the projected outcomes, and the projected investments associated with the effort. As such, it allows decision makers to examine the breadth of information currently known about the effort to determine whether or not the project is a good idea in terms of cost, benefit, and organizational objectives. It may include statements about the impacts on existing business practices, resource constraints, and environmental considerations so as to provide a comprehensive understanding of the project. In some instances, risk analysis is a key component. It is the primary document defending the rationale for the project.

Application

The business case is normally applied early in the project and may be developed by senior management, marketing groups, the project office, or by any group or organization responsible for initiating large-scale activity within the organization. Business cases in mature organizations follow consistent formats to allow managers to review multiple projects in similar contexts.

The business case will list the key proponents of the project, the sponsor, the users or beneficiaries of the project, and any deliverables. At a high level, it will describe the approach to be used and the business justification or rationale for that approach. Normally, that rationale will incorporate some form of cost/benefit analysis, although the types of cost/benefit analyses and their applications vary widely.

A general outline for a business case might look like this:

• Executive Overview
• Project Description
  • Proponent(s)
  • Sponsor(s)
  • Users/Beneficiaries
  • Deliverables and Quality Criteria
  • Rationale
  • Cost/Benefit
  • Schedule/Time Frames
  • Communications and Reporting Requirements
• Environmental Considerations
  • Project Development Environment
  • Project Implementation Environment
  • Organizational Processes
• Risk Factors/Risks
  • Risk Management Approach
  • Preliminary Risks Identified
• Assumptions

Content

The information supporting each of those outline components should be developed as objectively as possible. To achieve that, each element should be reviewed by at least one other person. The content may be expanded (or compressed) based on the business needs of the organization conducting the analysis. At a high level each section should contain the specific information discussed in the following subsections.

1.0   Executive Overview

The executive overview is a general scope statement identifying the time, cost, and requirements for the project, as well as the business need driving the effort. It should include the names of the project sponsors and project manager, as well as a description of the beneficiaries of the effort. The executive overview should provide a synopsis of the cost/benefit analysis, regardless of whether those costs and/or benefits are tangible or not.

2.0   Project Description

The project description should provide more depth on most of the issues raised in the executive overview, including the background, sources, and history for any data provided as rationale for the project or the cost/benefit analysis. This section may include cross-references to other project documentation, including draft plans, product descriptions, and stakeholder analyses or surveys.

3.0   Environmental Considerations

The cultural, technical, or physical environment may described here in depth, providing information on the practices and protocols typical within the environment.

4.0   Risk Factors/Risks

The risk approach described here may include the means and practices to

be employed for risk identification, qualification, quantification, response development, contingency allocation, and risk reassessment. Any initial or signifi

cant risks identified in developing the preliminary information (like the cost/benefit analysis) should be identified here as well.

5.0    Assumptions

Assumptions are beliefs that are held as true to allow for ongoing planning. In an effort to ensure that they have value, assumptions identified here regarding all aspects of the project (resources, environment, client culture, organizational behavior, and so on) should be validated as practicable.

Approaches

Business cases in some organizations may be voluminous and detailed. Others span only a page or two. Regardless of the level of depth, they should provide insight into the considerations that were used to determine if there is a valid business reason for moving forward with a project. They should be directed at an internal audience, because they may include information about the internal response to and structure for the customer relationship. The internal audience should, at a minimum, include the project sponsors, the project manager and executive management.

Considerations

Because the business case may contain sensitive competitive information, it should be disseminated only to those who have achieved a level of trust within the organization. The author of the document should be clearly identified, and contact information for that individual should be included as well. Although the business case is an initiating document, it should be reviewed and revisited on a regular basis to ensure that the cost/benefit analysis and proposal are still being pursued.

Criteria for Successful Project Management Offices

I was recently reviewing articles that I’ve written about successes and failures of Project Management Offices (PMOs) and some of the things that make that success or failure happen. I started making a list of these items and thought it might be helpful to share that info with the readers here on PM Tips again in this very condensed format. Remember, these are just my opinions that I’ve expressed in some of my articles along the way.

For PMO to be Effective:

• Director must be a key role in the organization
  • Must have backing and support of executive management
• Director must champion the efforts of the PMs
  • Don’t take credit for their actions
  • Provide ongoing support
  • Assist on critical/visible projects
  • Help breakdown resource acquisition barriers
• Director must run the PMO, not many projects
  • Project focus for the director should mainly be on the highly visible projects where exec decision-making is going to be needed on a regular basis or the business is extremely critical to the organization
  • Organization must value the PMO enough to ensure the director is not bogged down too much to be a successful leader

PMO Promotion

It is the responsibility of the PMO leadership to properly promote the PMO and help ensure its viability and visibility. Its viability is maintained by doing the following:

• Implementing proper and repeatable processes to consistently and successfully manage projects
• Implementing consistent templates for managing project and reporting status to customers and executive management
• Hiring competent, experienced Project Managers to lead projects for the organization
• Implementing proper compensation plans to retain good PM resources
• Implementing adequate training and on-boarding programs and processes to ensure that PMs are well-trained and up to speed on the PMO processes and practices

The PMO’s visibility is maintained by doing the following:

• Reporting project portfolio status on a regular basis and in a meaningful and useful format so that executive management realizes the PMO’s value
• Implementing solid PMO practices to ensure that the high-visibility customers are happy and referencable and the high-visibility projects are successful
• Inviting executive leadership to regularly attend weekly PMO meetings and sit in on project status meetings for the critical, high-visibility projects
• Managing project budgets thoroughly and reporting budget status up through executive leadership to show bottom-line PMO and Project Manager value

The PMO Director, as the leader of the PMO, must be a strong leader with pull inside the organization to ensure that these things happen. Otherwise, the PMO runs the danger of becoming obsolete or, at the very least, insignificant…and the mission critical projects will pass right by the PMO to special teams outside the PMO’s jurisdiction. Executive leadership must see value and ensuring that happens begins with the PMO leadership.

PMOs fail usually for one of the following three reasons:

• Lack of strong, focused leadership
• Lack of repeatable process
• Lack of executive leadership support

Five Signs Your PMO is not Meeting Your Organization’s Needs:

• Executive Management is not Included in the PMO Process
• Training Plans are Non-Existent
• Common Templates and Processes do not Exist
• Poor Upward Project Reporting
• Major Projects Circumvent the Process

All successful PMOs feature four basic components:

• The right processes
• The right tools
• The right people
• Executive level organization support

You can always hire different people. You can bring in consultants to help define better processes or identify better tracking tools. But without the executive-level support, none of it will happen or at least it won’t succeed.

Successful PMOs make an impact on organizational success by performing the following tasks:

• Aligning project delivery with strategic business goals and priorities
• Requiring that every project have an effective PM
• Implementing an appropriate PM methodology
• Consistent management and oversight of the project portfolio
• Obtaining and maintaining company leadership support