UNDERSTAND AND RESPOND TO THE CUSTOMER
|
As the CSM project manager, Uma felt that some of the team members were concerned that they did not know all the requirements of the project. Since Uma had not yet initiated conversation with her counterpart at Buslog Technologies, she asked Bob, as the CSM project sponsor, to schedule a meeting of the project core teams at Buslog and CSM. Bob arranged for a conference call with Terry Andrews, project sponsor, Cecil Jones, project manager, and the other key people from Buslog.
Bob facilitated the call and introduced everyone. He conveyed to Buslog that CSM is committed to working with them to make the project successful. He also mentioned that the interface between the two companies would start in a couple of months, after CSM completed its project plan. Bob mentioned that the CSM project team would like to work with Buslog to create the project plan for the B2B implementation. Terry concurred. Bob explained that the purpose of this meeting was to understand the customer's high-level needs. Various Buslog people discussed their expectations. After the call the CSM core team felt that they generally understood the needs of the people within the customer organization.
Uma facilitated the meeting, using the supplier-input-process-outputcustomer (SIPOC) model to identify customer needs. She explained that the SIPOC is a tool that can be used to improve the project process by clearly identifying relationships among suppliers, inputs, processes, outputs, and customers. She said that they would work backwards from the customer's needs. They identified the needs of Buslog and then the internal stakeholders for the order processing system. The B2B project SIPOC model is shown in Figure 3-1.
Figure 3-1: B2B Project Supplier-Input-Process-Output-Customers (SIPOC) Model
The team thought that this would provide them the input they needed for the scope definition. Since an error in a single transaction could cost millions of dollars, there could be no compromise in the quality of the B2B system.
Bob began by setting the priorities for the team. He told the group that quality could not be traded off. Cost could be traded off only if the steering committee approved.
Uma had another conversation with her counterpart Cecil to get more specific inputs on project priorities. Cecil mentioned that the go-live date is a hard one and Buslog can't compromise on that. From his perspective, the only thing they can trade off is the scope of the project.
Project Leadership Considerations
Documentation is needed for all meetings, both internal and external, and everyone needs a chance to respond to and correct errors or misunderstandings.
There are several aspects to understanding and responding to the customer, and this project team did a good job on most of them. First, the team needs to understand who the various customer groups are. The SIPOC model is very useful for this task. Working backward from the identification of all the customer groups, the core team can discover much useful planning information regarding customer needs. The SIPOC model should also serve as a starting point in the prioritization process.
Typically, a project is planned assuming that if everything goes right, the project team can successfully deliver all four customer priorities: the full project scope, on the agreed-upon schedule, at the agreed-upon cost, with the agreed-upon quality. However, on most projects unexpected things happen that either allow a project team to improve upon one or more of these four customer priorities or prevent the full attainment of one or more of these priorities. The project leaders should have frank discussions with the key customer groups (often this means both the external paying customer and one or more key internal stakeholders within the parent organization). The focus of these discussions needs to be which of the customer priorities take precedence.
For example, if things are going very well, should the project team try to lower cost, speed up the schedule, add more features to the project scope, or improve the quality of the project deliverables? The same understanding must be developed if things go poorly: Which of the customer priorities can be compromised and by how much? Many customers will tell a project leader that all four must be achieved. The wise project leader should respond that if all goes according to plan, that will happen, but as a responsible leader, she wants to make the same kind of decisions the customer himself would make if he were on the jobsite every day.
One area in which the project team could have done a better job is in documenting the conversations with the customer. In Chapter 2, simple minutes forms were introduced for use in project meetings. The intent of these minutes is to capture important information shared, decisions made, upcoming issues identified, commitments agreed to, and a meeting evaluation. The same type of information is appropriate to capture from other kinds of customer contacts such as conversations. After a conversation with a customer, a simple email to the customer confirming this information can be sent and a copy kept as project documentation.
Whenever possible, the first meeting with the project customers should be in person. Much of communication is reading and interpreting body language, and this is not possible by phone. A videoconference might be a useful compromise. Also, it is often wise to have a first meeting with the senior players: the project sponsors and managers from both companies. It may well make sense later on for members of the project teams to talk with each other directly, but a phone conversation with seven plus people is not an ideal way to start.
 |
A Project Leader Needs to:
Accept that the customer has multiple, often conflicting wants
Have the courage to prioritize the customer's true needs
Exercise the wisdom to understand the difference between wants and needs.
|
|
