Customer Management in Project Management

Customer Management in Project Management
By Dave Nielsen

It is fair to say that good communications is essential to the task of managing the customers of a project, but good communication is tool that will enable you to improve on your management style. Managing your customer requires you to understand who your customer is, what they need from the project you’re managing, how to set reasonable expectations around what you can deliver, and demonstrating to them that you’ve delivered.

Here are some tips that will help you establish and maintain a good working relationship with your customer from the beginning of the project, through to closeout.

Identify Your Customer

This may sound simplistic, but in most software development projects distinguishing customers from other stakeholders can be tricky. Here’s a golden rule for identifying your customer: the ultimate customer is the one that signs the cheque. This person is frequently referred to as the business sponsor in software development projects. If you are doing a software development project “in house”, that is the software system being developed will be used by your organization only, the business sponsor is the person who initiated the project and who will pay for the system.

The ultimate customer will also be the business sponsor when you are developing the system for an external customer. You can manage the external business sponsor in the same way as you would your internal business sponsor in the absence of a project manager working for the purchasing organization. You will need to defer to the purchasing organization’s project manager where you are the vendor in a vendor client relationship.

In more complex client/vendor relationships the actual customer can be more difficult to distinguish. The actual customer is still the purchaser of the project’s goods or services but your focus should be on the organization purchasing your services. Your vendor will have someone from the business who is responsible for managing you and that person is your primary customer. You will need to defer to your vendor’s project manager in cases where this person is responsible for managing you. You cannot forget the overall customer for the project though. Guidelines for communicating project results, issues, and escalation paths should be established at the outset of the project. Encourage your ultimate customer to adhere to the guidelines in cases where they wish to communicate with you directly and established guidelines dictate they should go through your client.

Identify Your Customers Needs

The starting point for your project will be in the form of a scope statement of some sort. The scope statement may come to you in a business case, an e-mail, a memo, or a contract. It is highly unlikely that anyone outside the project management fraternity will call it a scope statement. This statement is why the project was initiated in the first place so is the well-head for all future requirements definition. The scope statement itself will not be sufficient to design the product or solution though. The scope statement must be expanded on until it is at a sufficient level of detail to organize the project and direct the work. “The devil is in the details”. The journey from scope statement to Business Requirements document, Commercial Specification, or other document capturing a description of the functionality of the software system is where you must apply your project management expertise to accurately capture the customer’s needs. The same principal will apply to projects covered by contracts. The contract will contain a Statement of Work in some form which serves the same purpose as the scope statement. The Statement of Work may be written to a greater level of detail than the scope statement but will still have to be expanded on to develop your design.

I have written an article, also appearing on PM Hut, entitled Requirements Gathering for Software Projects. This article contains all the expertise you need to capture your customer’s needs accurately. I’ll cover some of the points contained in this article briefly here.

Your first step must be to communicate the 1st commandment of scope management which is: “If it isn’t in the Statement of Work/Scope Statement/alternate source, it won’t be in the project unless it comes in through an approved change request.” We’ll talk a little more about managing change later in this article. Developing the detail design documents from this point forward is an exercise in balancing budget and schedule against scope.

Identify the appropriate stakeholders to deliver detail requirements. These people should be the ones who will use the new system once it has been implemented. Don’t forget the stakeholders who are not users of the new system but who are downstream of it. These stakeholders include the consumers of reports from the system and existing systems with which the new system must interface. Your customer should approve of all the stakeholders you engage in the requirements gathering exercise and identify any they believe you have left out. Your customer will identify the goals and objectives of the project in business terms – their thinking is strategic, not functional. They will think in terms of improving their organizations sales with a new product, or reducing order processing costs.

You can’t forget the project related deliverables in the process of requirements gathering. This is where you should be able to establish the communications approach which will satisfy their need for project information. Extracting these requirements from your customer may not be easy as they are likely to have little time to devote to describing their exact communications needs to you. You’ll have to be inventive to get around this constraint. What were their preferences on the last project they initiated? What were their preferences on the past project they sponsored? Talk to project managers in your organization (or your customer’s organization where these differ) to find out what their experience with your customer have been. People who are inundated with e-mails and other written communication tend to prefer reports they can read at a glance. Where no detailed information on your customer’s preferences is available, try various chart and graph models on them. Mock the reports up using Excel, or some other graphics tool, and present them (or e-mail them) to your customer and ask them to indicate their preference. If all else fails, put yourself in their shoes. What would information would you like about the project and what information, in what form, will you have time to read?

The requirements gathered during the planning phase of your project will determine the budget and schedule for the project. You should have all the requirements you need to gather in order to achieve the goals and objectives of the project stated in the scope statement or statement of work, providing you have selected the right stakeholders to contribute. You now have to fit them in the “box” your project’s budget and schedule has built for them. One trick for making this exercise easier is to have the stakeholders prioritize the requirements they identify. You can use cardinal (numeric), or ordinal (high, medium, low) systems to do the prioritization. You can also order the requirements by complexity or estimated development effort in the same fashion. You should have an ROM estimate for the requirements as well to determine if you have a scope reduction exercise to perform at the outset of the project. You will have an idea of the requirements which will be sacrificed first as development work shows you that the scope must be reduced further to meet budget and schedule objectives. The business sponsor should sign off on the set of requirements selected for the project. They should at least have delegated the sign off to another stakeholder if they are not comfortable with the sign off themselves.

Your customer should be prepared to provide you with guidelines for quality as part of identifying requirements for the project. Quality will be measured in defects when the project delivers a software system and the requirements should be set to limit the number and severity of these defects. The critical measures will be taken at the time the system is ready to implement. How many severity 3, 4, or 5 defects are acceptable to go to production with? How many severity 2 defects can you go to User Acceptance Testing with? These goals should be clearly stated for both your customer and the team.

Keep Your Customer in the Picture

Your customer is a mature, experienced business person. They don’t need to be insulated from bad news, least of all by you so make certain that you communicate any major project challenge as soon as you have all the facts. I say “major” because your customer does not want to know, or need to know, every issue you are faced with in the course of managing the project. You will have to use your judgment to identify the issues they should know about, but here’s one rule of thumb: anything that could cause the project to finish late, finish over budget, not deliver the requirements specified, or not to deliver the degree of quality specified.

Your principal tool for keeping your customer in the picture will be the reports your customer has requested. You should include any major incident or issue the project has encountered with these reports. You may also want to identify the highest scoring risks with the reports, along with the mitigation strategies chosen to address them. You should work with your team to identify corrective or preventive actions when you are reporting any deviation of planned schedule or budget from actual results. You should never report a deviation without a corrective action even if implementation of the corrective action is beyond your ability. Don’t ask the customer for help unless you can identify exactly what it is you would like them to do.

Give your customer as accurate a picture of project performance as it is possible to give them based on the data your project gathers. Always accompany the reports with a disclaimer identifying any areas of potential inaccuracy in that data.

Invite your customer to team meetings, team building exercises, award ceremonies, and etc. is another way you can keep your customer in the picture. Your customer has an ability to affect team morale because of their position in the organization. Use that influence to your advantage. Having the customer hand out awards to team members rather than hand the award out yourself. Make the ceremony into a special occasion by having the customer hand the award out in front of the entire team. Having the customer attend your team meetings is a great way of communicating the importance of the project. They won’t attend every meeting, they may not attend any meetings, but if you can manage to have them attend one or two it will tend to motivate the team to meet their objectives. Be careful to prepare the team for the visit though. You don’t want to air any dirty laundry in front of the customer so make sure that your team meetings are conducted in civilized fashion before turning them loose on your customer.

Changing the Project

You first have to come to terms with the need to change the project on the fly before you can deal with changes that either affect the customer, or are initiated by the customer and affect the project. Your project should have a change management plan which deals with all aspects of managing a requested change and is custom tailored for your project. Communications management plans and change management plans will tend to overlap in the area of communications definitions and schedules, but your change management plan should tell your customer how they would go about requesting a change, and how they would be notified of a requested change that would change the project. Let’s deal with the case where your customer requests a change to the project first.

There are many valid reasons for your customer to change their requirements for your project such as a changing market place, a change in the way they do business, a change in the financial status of the organization, or a change requested by their customers. Your obligation to your customer is to turn their change request around in a reasonable amount of time. The definition of what is reasonable and what is not should be in your change management plan. You should tell your customer what the next steps are and when they can expect the next communication upon receipt of their change request.

The next step will depend on the structure of your project. It should be an estimate of the cost for analysis if the relationship is customer/vendor, and your contract supports this form of revenue. It could be an estimate of the completion of analysis if you are doing the project for an internal customer and the request is large and complex enough, otherwise it should be the analysis itself. The purpose of providing the customer with an estimate of the cost of analysis is twofold: it allows you (the vendor) to avoid costly analysis for requested changes that won’t be implemented because of their cost, and it allows the customer to avoid an expenditure they aren’t prepared for. The next step will be an approval or rejection by the customer. An approval will trigger the next step which is the analysis.

The analysis of the change request produces a cost estimate for implementation of the change. You need to remember that you are working with the customer so implementing the change in the most cost effective manner possible should be the goal. Once a cost estimate has been calculated the customer can weigh the cost of the change against the expected benefits to be derived from implementing it. Try to give your customer options for implementing the change. One means of giving those options where the requested change is an addition to the project scope is a reduction in scope in another area. Prioritized requirements will make this easier for you to do.

Communicate the date and method any accepted change will be implemented to your customer. You might also inform them of the first opportunity they will have to see the change implemented in the system, for example a pilot, or a User Acceptance Test environment.

Change requests are frequently outcomes of variances to scope, schedule, or budget baselines, and sometimes more than one baseline. For example, it is rare that a schedule for a software development project is overrun without an attendant increase in budget. The desired corrective action to address a variance will be something that will succeed in getting the project back on track but that isn’t always possible. Effort estimates for project activities are often done at a high level at the outset of the project and then refined as more is learned about the work. These high level estimates will have a high degree of risk or uncertainty. You need to communicate this fact to your customer before implementation. At the gate, phase exit review, or business decision point meeting is an ideal time. You may find that your estimates were too optimistic and the project cannot possibly be completed by the deadline, or on budget no matter what action you take.

You will need to author a change request defining the proposed corrective action and that change request will need to be reviewed and approved (or rejected) by your customer. A change that entails a change to one of the baselines: scope, schedule, or budget may not be possible if you are working with a fixed price contract. Otherwise you will need to describe the change to the baseline required to get the project back on track. You should give your customer options when presenting them with this type of change. You may be able to preserve a critical deadline with the addition of resources, efficiency tools, or overtime. You may be able to preserve the deadline by reducing the project’s scope. Keep in mind that the change you are requesting is bad news for your customer because you are telling them their project will not be able to meet its original goals and objectives. Do your best to minimize the negative impacts and make the news as palatable as possible without altering facts.

You must change your project’s baselines when an approved change request impacts them. The baselines don’t necessary have to change at the highest level. You could implement a change that would extend the development phase by 1 week and make that week up during testing. You could increase the budget for the development of a database and decrease it by an identical amount in testing so that the overall budget is preserved. These are still changes to the project baseline and these must be communicated to the customer as part of your announcement of the accepted change. A change to the project schedule will also bring about a change in all reports that reflect performance to schedule. A change to the project scope or budget will bring about a change in all reports that deal with project performance in those areas. Your customer should be prepared for those changes before they see the first report.

Conclusion

The customers of your projects are people before they are customers. Treat your customers the way you would like to be treated if you were in their shoes and you won’t go far wrong. If you are a home owner you have likely dealt with a contractor at some point and may have had a negative experience: the final bill came in at twice the original estimate, or the job took a month longer than the initial schedule and you were not aware of the changes until you got the bill or until the job missed the deadline. Don’t ever treat your customers this way. Treat them as partners in your project – partners that are footing the bill!

Dave Nielsen is a principal with three O Project Solutions, the vendors of AceIt©. Dave was also the key architect responsible for the creation of the product. AceIt© has prepared Project Managers from around the world to pass their PMP® exams. You can find endorsements from some of his customers on three O’s web site (http://www.threeo.ca/).