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.

Strategizing Project Delivery

The purpose of strategy is to provide direction and concentration of effort as organizations continually strive to improve their position or gain the upper hand within the marketplace. Basically, it’s a struggle for advantage, and the one with the best advantage wins. It’s that simple. On what areas must businesses concentrate? Businesses clearly have to:

• Gain new advantages that increase or improve customer satisfaction, which will differentiate them from their competitors
• Either eliminate or minimize their competitors
• Achieve speed to market
• Re-engineer business processes for improved competitiveness
• Align their organizations to the latest economic trends
• Implement the strategy through projects
• Evaluate the success of the strategy by measuring project success

From project management’s point of view, there is no need to manage any project if the project manager has no idea why it’s being done in the first place. It’s crucial for any project manager to address the larger issues of the business strategy and see where the project fits in the overall framework. It isn’t easy—but it needs to be done.

Therefore, organizations must focus on project management as the key business driver that will achieve these advantages for them. With sound project management methodology and processes in place, project management is able to support the overall business strategy of an organization with these logical benefits:

1. Reduced delivery costs. Project management can provide products and services more cheaply by following a structured and formalized project methodology and by ensuring that excessive costs are not spent without due consideration.

2. Quicker product to market. The advantage permits the business to deliver products or services more efficiently than the competitors and the business is able to react more favorably to market demands.

3. Focused advantage. The projects will be focused more on the client needs and products, instead of having a solution that does not deliver the expected returns.

4. Quality and timely deliverables. Project management builds quality into the products or services right from the start, ensuring that the right things are developed at the right specification.

5. Proven customer advantage. Project management gains advantages for their organization by working together with the customer and by accommodating their needs and requirements.

Summary

Today’s organizations are challenged, as they need to keep pace with competitive markets, client needs, and marketplace trends. Winning is basically about who has the upper hand – either with new technology or quicker project implementations. The only winners will be those executives who are able to reinvent their companies quickly enough to take full advantage of the efficiencies that solid project management practices can offer.

The Project Resource Request

Here is yet another template that I am digging out of my archives to provide here.  As you can easily guess, this document is designed for requesting resources at the beginning of your project based on information in your statement of work (SOW) and the estimates of resource requirements that either you or Sales put together in the pre-engagement process.  It is also helpful for requesting additional resources during the project.

How useful this is to anyone depends on the organization they work in.  If you have a mature PMO with processes in place, then I would guess that you already have a standard form or spreadsheet to use to request resource for your project.  However, if you’re one of just a few PMs or personnel acting in a PM role in your organization or you’re in the process of building some PM processes for a newer organization or even setting up a new PMO, then any template may be better than nothing.

As with all of these documents, if you want the original Word doc file, just email me if you think this will be useful or helpful.  And please, provide your own example if you wish.  We’re looking to learn and share information so I’m happy to use and post whatever you would like to provide to the readers of PM Tips.

PROJECT RESOURCE REQUEST

[Save file name as: client name RESOURCE REQUEST yyyymmdd]

PROJECT DESCRIPTION

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

WORK DESCRIPTION AND ROLE

Describe the work to be performed on the project by the resource(s) and what role the individual(s) will play on the project team.

DESIRED SKILLS

Describe the technical, business or professional skills needed by the resource(s) to successfully meet the needs of the project.

DELIVERABLES

Describe the deliverables the resource(s) will be responsible to complete as a result of their work on the project.

DATES REQUESTED

Starting: mm/dd/yyyy Ending: mm/dd/yyyy

HOURS OR % FTE

Provide the estimated number of hours or the percent of time the individual(s) will be need to be allocated to work on the project.

WORK LOCATION

Describe all of the locations the resource(s) will be expected to be located – if multiple locations, provide dates as they are know at the time of the request.

REPORTING STRUCTURE

Describe the reporting structure for the project and how the individual(s) will be expected to operate within this structure.

Project Transition to Production Support

As part of methodologies I’ve previously discussed, the final phase is something that I call the Post-Deployment phase.  Once the project is implemented – or deployed – the delivery team, the customer, and the project moves on into the Post-Deployment Phase.

The Post-Deployment Phase is the period of time when the delivery team remains as intact as possible to support the customer and the deployed solution before a final and formal transition to technical, or production support.  This post-deployment period is usually somewhere between 30 and 90 days in length (30 is more likely) and that time period is set either during the sales process (and becomes part of the statement of work) or during the kickoff session.

Upon satisfaction of the post-deployment timeframe, support formally moves over to the company’s techical or production support team.  The template I am unveiling here is a formal document to record that transition process, allowing the project delivery team to identify specific things about the project that the production support team will need to know.  While reviewing this document, keep in mind that there are really three very key pieces of information in here that the support team will need to know the most about:

• Schedule
• Communication
• Change Control Process

PROJECT TRANSITION TO PRODUCTION SUPPORT

[Save file name as: client name PRODUCTION SUPPORT yyyymmdd]

PROJECT DESCRIPTION

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

SCOPE

Describe the deliverables/actions to be supported. Provide additional documentation as appropriate.

SCHEDULE

Describe the timing for support activities to be performed. Provide additional documentation as appropriate.

COMMUNICATION

Describe all required communication needs for support – What to communicate, to whom, in what format, and when. Provide additional documentation as appropriate.

QUALITY ASSURANCE

Describe the Q/A processes to be performed. Provide additional documentation as appropriate.

COST

Describe the support costs estimated by the project. Provide additional documentation as appropriate.

CHANGE CONTROL PROCESS

Describe how changes to the Production Support process will be addressed. Provide additional documentation as appropriate.

Detailing the Project Management Audit Process

Diving a little deeper PM audit process as described in the book “Information Technology Control and Audit”, we will look at the audit planning, the actual PM process review, the act of working with the PM and team to identify risk, and the communications necessary to ensure that the audit process is as successful as possible.

Audit Plan

The audit plan will detail the objectives and the steps to fulfill the audit objectives. As in any audit, a project management audit will begin with a preliminary analysis of the control environment by reviewing existing standards and procedures. During the audit, these standards and procedures should be assessed for completeness and operational efficiency. The preliminary survey should identify the organization’s strategy and the responsibilities for managing and controlling development.

Project Management Process Review

A project management process review would assess the adequacy of the control environment for managing projects. The review points listed represent checkpoints in the project management process. Auditors can use these checkpoints to determine both the status of the project’s internal control system and the status of the development project itself. These reviews eliminate the necessity of devoting large amounts of audit resources to the development effort. As long as the development process is well controlled, the need for audit involvement is minimized.

Project Management

Auditors may assist the project manager in identifying project risks and evaluating plans to mitigate and manage risks (e.g., training, devoted resources, management support, and end-user commitment). Auditing can provide management with an independent review of project deliverables (e.g., project charter, task list, schedule, budget). Auditing may also review the project task list and budget to verify that all project tasks are defined and all milestones have a deliverable.

During the planning phase the auditor can facilitate communication between functions and raise issues that may impact the quality or timeliness of the project. In a development project, resources from various departments need to come together to implement an automated process that may affect multiple user functions. Because of various audit projects, auditors develop an overall knowledge of the organization and establish relationships in multiple departments. These relationships are helpful in a development project for making sure information is flowing between the development team and other functionaries. Consider the following groups:

• Primary users
• Secondary users
• Vendors and consultants
• Programmers and analysts
• Database administrators
• Testing teams
• Computer operations
• Interfacing systems
• Implementation team
• Production support (i.e., maintenance programmers)

Verify that adequate resources are assigned responsibility for tasks and have the time to complete assignments. This includes development, computer operations, user, and support functions (e.g., help desk).

Communication

The first area to communicate is the auditor’s role in the systems development project. It is very important to make sure that the management and development teams’ expectations of the auditor’s role are understood and communicated to all participants. In order to influence the systems development effort, the auditor must develop an open line of communication with both management and users. If a good relationship between these groups does not exist, information might be withheld from the auditor. This type of situation could prevent the auditor from doing the best job possible. In addition, the auditor must develop a good working relationship with the manager, the analysts, and the programmers. Although the auditor should cultivate good working relationships with all groups that have design responsibilities, he or she must remain independent.

Recommendations

Throughout the development project, the auditor will be making control recommendations. Depending on the organization’s culture, these recommendations may need to be handled informally by reviewing designs with the project team or formally by presenting recommendations to the steering committee. In either case, the auditor must always consider the value of the control recommendation versus the cost of implementing the control. Also, recommendations should be speci?c, identifying the problem and not the symptom. This allows the proper controls to be implemented and tested.

Recommendations are often rejected because of a time and cost factor. Managers may sometimes feel that implementing an auditor’s recommendations will put them behind schedule. The auditor must convince management that if the recommendations are not implemented, more time and money will be spent in the long run. Informing management of the cost of implementing a control now rather than shutting down the system later to repair it or leaving possible exposures open will help convince management of the need to spend time and money now.