Doing the Right Things for Your Customer

Customers are a demanding group … that’s a given. When we have all of our regular project responsibilities to deal with on a daily and weekly basis, how do we know when we’re doing the right things for our customers? How do we know we’re managing them well, responding to the right requests, saying ‘yes’ when we should and saying ‘no’ when we should, and ensuring that our actions are not detrimental to the forward progress of our project?

You can’t always base it on customer satisfaction levels. Because attentive ‘do-anything-for-the-customer’ behavior may get a project manager and team high marks mid-way through a project. But upon implementation, if they’ve said yes to too many things that ended up modifying scope and delivering a system to the customer that is ultimately not what they ordered, then that customer satisfaction at the end of the project will be low. The end user community will have a product that they didn’t sign up for and that’s a very bad thing.

In order to ensure we’re doing right by our customers, we first need to have confidence in what we’re doing. And we need to have confidence that we’re doing the right things for the project. We can do that in a few ways, including:

Read more »

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.

Defining Implementation Success or Failure

Sometimes indentifying whether your project or implementation was a success or failure is not as straightforward as just looking at the metrics involved with project management. It’s not always about on time and on budget. And it may not entirely be about customer satisfaction either.

In Henry Lucas’ book “Information Technology for Management” he defines first what an Implementation is and then looks at some of the possible criteria for determing that implementation’s relative success or failure factors.

What Is Implementation?

Implementation is part of the process of designing a system and is a component of change. We develop a new information system to change existing information processing procedures and often to change the organization itself. Implementation refers to the design team’s strategy and actions for seeing that a system is successful and makes a contribution to the organization.

Our definition stresses the long-term nature of implementation. It is part of a process that begins with the very first idea for a system and the changes it will bring. Implementation terminates when the system is successfully integrated withthe operations of the organization. We expect most of implementation to be concerned with behavioral phenomena since people are expected to change their information processing activities. Implementation becomes more important and difficult as systems design becomes more radical. If a firm undertakes a maj or reengineering project, it should make major changes in tasks to reduce costs and improve productivity in the organization.

Success or Failure

How do we know that we have successfully implemented a system? Researchers do not agree on an absolute indicator for successful implementation. One appealing approach is a cost/benefit study. In this evaluation, one totals the costs of developing a system and compares them with the dollar benefits resulting from the system.

In theory, this sounds like a good indicator of success, but in practice it is difficult to provide meaningful estimates. Obtaining the cost side of the ratio is not too much of a problem if adequate records are kept during system development. However, an evaluation of the benefits of an information system has eluded most analysts. There are a number of categories into which we might classify the benefits or value provided by an application of technology. These categories include:

• Infrastructure
• Required applications
• Applications where technology was the only solution
• Applications providing a direct return
• Applications with indirect returns
• Technology initiatives that are a competitive necessity
• Strategic applications
• Transformational information technology

For only a few of these categories are we likely to be able to demonstrate a direct financial return, which makes it difficult to perform a cost/benefit analysis to determine the “success” of a system.

As an alternative, we can choose among several indicators of successful implementation for an individual application, depending on the type of system involved. In many instances, use of a system is voluntary. A manager or other user receives a report but does not have to use the information on it or even read the report. Systems that provide interactive retrieval of information from a database also can often be classified as voluntary. The use of such a system is frequently at the discretion of the user. A manager with a personal computer in his or her office is not required to use it. For the type of system in which use is voluntary, we shall adopt high levels of use as a sign of successful implementation. We can measure use by interviews with users, through questionnaires, or in some instances, by building a monitor into the system to record actual use.

For systems whose use is mandatory, such as a production control system or a computer that provides stock market quotations for a broker, we shall employ the user’s evaluation of the system as a measure of success. For example, onecan examine user satisfaction, although it will probably be necessary to measure several facets of satisfaction, such as quality of service, timeliness and accuracy of information, and quality of the schedule for operations. An evaluation might also involve a panel of information processing experts reviewing the design and operation of the system. We should also note that managers might well consider a system to be successful if it accomplishes its objectives. However, to accomplish its objectives, a system must be used. We would also hope that one objective of a system would be extensive use and a high degree of user satisfaction.

Finally, though it is difficult to do, we can try to estimate the impact of a system on individuals and the organization. How has a system affected personal productivity and output quality? Can the organization point to added sales or increased revenues from a competitive application? Can we show that IT has had an impact on performance, either for individuals or the organization?

A Lessons Learned Template

Lessons Learned – often talked about, a discussion that is usually planned…but often forgotten.  You’re at the end of the project and the plan is to pull both teams together to go over lessons learned in great detail and for the benefit of all – but it often doesn’t happen.  Team members move on to other projects or post-deployment issues are taking up everyone’s time.

Lessons Learned sessions can be very helpful – and if you’re luck enough to keep yours on the project schedule, then this template may help you.  It looks a little rough pasted into this post and one of the tables turned into a bullet list, but I think you’ll get the idea.

As always, if you want the Word doc template, let me know…and please feel free to share your version as well.

PROJECT LESSONS-LEARNED DOCUMENT

The purpose of this template is to help the project team share knowledge gained from experience so that the entire organization may benefit. A successful Lessons-Learned program will help project teams:

• Repeat desirable outcomes
• Avoid undesirable outcomes.

A. Your project team should begin to use this document at its first project meeting. Continually recording Lessons-Learned throughout the project is the best way to ensure that they are accurately recorded. Topics to consider include all of the following (feel free to change the list). The Lessons Learned Checklist is also available as a guide to discussion.

B. At the end of your project, use this document to summarize your experience.

During your discussions:

• Be positive
• Do not place blame!
• Focus on successes as well as failures
• Indicate which strategies contributed to success
• Indicate which improvement strategies would have the greatest impact

The signatures above indicate an understanding of the purpose and content of this document by those signing it. By signing this document, they agree to this as the formal Project Lessons-Learned Document.