"Diplomatic" Software: Customer Relations
Summary: Sometimes, your biggest architectural challenge is the customer's technical staff. (12 printed pages)
Your goal is to deliver a set of architecture strategies and software projects for outsourced contracts. However, what do you do when your main challenge is not to implement a complex and heterogeneous platform integration, or perform under a tight schedule or budget, but instead to manage your relationship with the customer's technical staff? How do you deal with them to avoid compromising the entire project and avoid pressing the wrong key?
Monday, November 21, 2005. John began to review the existing documentation for a new and ambitious project. He was charged as project manager and designer to a complex system, one that involved a heterogeneous environment and several security restrictions. He had been hired to manage the entire project and, together with an architect, design all the components for a sophisticated service-oriented system. He was also accountable for people and technical resources as a custom software-development provider. His company, Datum Corporation, had 150 employees. His customer, the Phone Company, was one of the market leaders in the telecommunications industry. The project was meant as a software solution for internal use at the customer's site.
November 26, 2005. The Phone Company was not willing to invest too much of their technical staff's time on the project, because they were constantly engaged with other projects that required their attention and dedication. So, it was not possible to assemble a team comprised of both Datum personnel and those from the Phone Company. The customer did, however, name a project manager—the visible face of the Phone Company—to be responsible for the project delivery and functional goal fulfillment of the solution. Similarly, they also named a "technical leader" to the project, or a person who would take charge of all the steps of approval of the project architectural and infrastructure design, and would coordinate testing and production deliveries. Therefore, the Phone Company put the implementation of the solution in the analysis, design, development, tests and production setup Datum's hands. This scenario is represented in Figure 1.
Figure 1. Initial scenario, blue lines representing information flow (Click on the picture for a larger image)
Business requirements were elicited from the various customer stakeholders:
- User leader—The users were the ultimate beneficiaries in terms of time saved from the integration between a client management system and the billing system. They were the project's financial sponsor.
- Stockholders—They were interested in whether or not the system's integration would permit significant savings financially and in terms of internal processes.
- Marketing—They were interested in offering their customers better response times by accelerating their internal accounting processes.
- DBA and IT staff—This group's purpose was to manage everything related to the platform and the company's communications infrastructure. Their functions included applications setup, security check procedures, and general platform maintenance.
- Chief Technology Officer (CTO)—As usual, the CTO managed the company's core technical and human resources, and the fundamental base for the execution of company operations.
Using a little perspicacity, intuition, and emotional intelligence, John created the following table to help him understand the skills of the people who represented his customer's interests:
|Stockholders||CTO||DBA & |
|Interested in the project||X||X||X||X|
Table 1. "Customer-side" taxonomy
December 12, 2005. The situation:
- The project manager on the customer's side was not present most of the time, because he had to take care of other projects.
- The technical leader was a bad-tempered person, with many personal problems, but had the CTO's support.
- The IT staff had strict rules about security management, to the point of absurdly sacrificing the performance and functionality of some applications.
December 13, 2005. The situation:
- The absence of the customer's project manager resulted in their loss of initiative to push forward with the project.
- The software deployment fell way behind schedule, because the technical leader was busy on other matters. The technical leader did not bother to check the technical documentation, integration design, or even system-security requirements.
- The technical leader suggested that Datum have direct contact with the IT staff to save time. However, the Phone Company's IT department had already rejected the project, because it did not fulfill security-policy requirements.
- As a result of frustration caused by the absence of the customer's project manager, the lead user representative started a series of conversations with the technical leader, in which the technical leader complained about "several problems" with Datum.
- As communications degenerated between customer and provider, the case was scaled to the CTO, who did not provide an immediate resolution to any of the problems. See the communication channels change that is depicted in Figure 2.
Figure 2. Communication channels modified (Click on the picture for a larger image)
John examined the individuals and their characteristics, from a very "human" point of view. He leveraged aspects of everyone's general behavior in order to "play a chess game." He determined some alternatives and worst-case scenarios.
Alternative 1: Direct Escalation
Figure 3. Direct-escalation scenario (Click on the picture for a larger image)
John could address the customer's project manager and team leader directly. The sequence of events could have been as follows:
- John would ask the Phone Company's project manager to return to the project (cordially, and using "diplomatic means").
- The customer's project manager would initially agree, then request help from the technical leader again.
- The technical leader would announce that all was under control and that the deployment depended upon Datum's actions.
- Given the project manager's divergent behavior, it would not have taken much time for him to turn his attention towards other projects, temporarily dismissing this project.
The situation would not have improved. The project would not be running on time. This would have a negative impact upon both John and Datum.
Alternative 2: Second Instance Escalation
Figure 4. Second instance escalation (Click on the picture for a larger image)
John could try to influence events indirectly. In this case, the following scenario could occur:
- John would take his case directly to the Phone Company's CTO, explaining the situation and the urgency needed to wind up the project.
- The CTO would request the immediate support of the appointed project manager. However, as evidenced by his recent lack of participation in the past several weeks, he would probably repeat his ineffectual behavior once again.
- The CTO would also request an explanation of the situation from the technical leader. Both the CTO and technical leader worked for the same department, however, and they would likely collude to protect themselves against project failure—perhaps, at the expense of the project's outcome.
- The Phone Company's project manager would not reestablish effective communication with John, because his attitude toward the project has been permanently changed (the damage was done).
- The user leader would probably not be informed of the lack of action on the part of the Phone Company's project and technical leadership. He could begin to have doubts about the success of the project, and begin to doubt the effectiveness of both John and Datum Corporation.
- Without effective communication, a bad disposition toward Datum could become a permanent aspect of their relationship.
Broken communication channels and personality issues would affect project continuity negatively.
Alternative 3: Talking with the User, Exclusively
Figure 5. Talking with the user, exclusively (Click on the picture for a larger image)
John could bypass his customer's leadership and take his case directly to the user community. This could trigger a number of events, with unpredictable outcomes:
- The user leader could determine on his own that some of the project's problems were the result of actions of their technical leader. Confronted directly by the user leader, the technical leader would likely defend his work and blame the problem on Datum.
- The user leader might contact the Phone Company's project manager to verify the situation. The project manager, however, might just rely on the assessment of the defensive technical leader. In this case, Datum would still be blamed for the problems.
- Another possibility would be that the user leader could give the stockholders information about the situation, who would definitively take a position against the project, with the corresponding aftereffects.
The project would be absolutely compromised, from the administrative point of view.
Alternative 4: "Multiple-Conversation" Strategy
Figure 6. "Multiple-conversation" strategy (Click on the picture for a larger image)
None of the previous scenarios appealed to John. After much contemplation, and a little bit of worry, he decided on a bold strategy. He decided to talk to everyone, but not without arming himself with a specific set of recommendations that could solve some of the problems that everyone was facing:
- John expressed his "concern" about the lack of progress on the project to his counterpart. John's initial objective was to try to persuade the other project manager not to take any immediate action to terminate the project. He accomplished this by compromising over a revision to project status, and compromising on his own expectations of the technical leader's activities and accountabilities.
- In a similar manner, the technical leader compromised by committing to review security issues with the DBA and the IT manager, to reading corresponding technical documentation, and to understanding the work schedule for the software components installation.
- Instead of expressing a concrete complaint to the user leader, John proceeded to look to his sponsor for direct support in the finalization of the project. He asked the user leader to express John's technical direction directly to the stockholders.
- Gaining the user leader's direct involvement with the project helped the leader acquire a sense of confidence about the project's eventual success. His sense of confidence was, in turn, related to the stockholders.
- John told the CTO that the user leader had expressed confidence in him as an important factor for the project's success.
- John suggested to the CTO that the IT operations team take responsibility for security policies, and the prioritization of project testing.
- With his own sense of confidence, and with a plan to help ease the burdens on his staff, the CTO encouraged the technical leader to collaborate positively in the technical solutions, and also encouraged his project manager to prioritize his work more carefully.
Final result: March 14, 2006. The project goals were successfully fulfilled, with the help of the technical leader and three of the customer's IT specialists. The users were very satisfied with the solution. Budget and time deviations were minimal, and the Phone Company's team was left with a very favorable impression of John and Datum.
One of the main objectives in any software-development project is to preserve the original channels of communication and, therefore, to be in touch with the customer's employees, so as to empower and motivate them to achieve project goals. It is best to form a provider-customer team. When this is not possible, all the communication channels must remain open.
It is essential that the strengths and weaknesses of each one of the "characters" who is involved in a technology solution be identified, to determine what actions should be taken in any given situation. Develop a "character taxonomy," as part of a risk-management discipline.
When a project manager is trying to involve a customer in the project solution, it is important to try to avoid conflict. That is, avoid generating situations in which you "awaken" the real "personality" of the individual and it interferes with the project resolution. Trying to force people to make decisions is not a good idea. It is always better to encourage them to make their own decisions, based upon their commitments, instead of telling them what to do. It is important to encourage the project sponsors to "sell" their own project within their organization.
- How were the actor's personality traits, as shown in Table 1, leveraged effectively? Which personality traits contributed to the project's success, and which threatened to derail it?
- Which factors directly contributed to delivering the project on time? How was the business relationship between customer and provider preserved while doing this?
- How was customer-side management motivated to rejoin the project-development effort?
- Could the situation with the technical leader have deteriorated even further?
- Could the whole situation have been prevented from happening in the first place?
- Flannes, Steven, and Ginger Levin. Essential People Skills for Project Managers. Vienna, VA: Management Concepts, 2005.
- Project Management Institute. People in Projects. Section 6. Newton Square, PA: Project Management Institute, 2001.
- Pryke, Stephen, and Hedley J. Smyth. The Management of Complex Projects: A Relationship Approach. Section III. Malden, MA: Blackwell Publishing, 2006.
About the author
Henry Rosales is a project manager and software architect for Informática & í, a Colombia-based company, specializing in custom software and business-intelligence solutions. He has been working professionally in software development for 12 years, after coding his first software program at the tender age of 8. Henry is currently working on a book titled Software Development with Humans.
This article was published in Skyscrapr, an online resource provided by Microsoft. To learn more about architecture and the architectural perspective, please visit skyscrapr.net.