Read the case study below and answer the questions that follow. Case 2.1: Specification Clarifications with a Customer in Germany I had a nine-month project to develop the software for a mobile phone wireless application connectivity chipset for a German customer. I had six chip software design and test engineers working on my team on a full-time basis. Our offices were in California and my customers offices were in Munich, Germany. This nine-hour difference in the time zones brought to the surface several communication challenges, especially as the chipset specifications were written in a very concise fashion and they were open to many interpretations. As the design progressed, my team started to have numerous questions about the specifications that needed clarifications. Also, the customer wanted to add on several enhancements to the chipset design along the way. I was lucky that this custom chipset software development project was not a fixed price contract. It was a time and materials agreement. I had to inform the customer weekly of how his money was being spent on the project. There were no punishing scope changes and specification revisions. I only had to record every specification clarification and every additional specification enhancement as the project moved on. This custom software development project required precision and on-time communication methods with the customer. These communication methods had to eliminate any specification ambiguities in their fluid state. At the project kick-off meeting with the customer, I offered to have a daily one-hour telecommunication with my team and on his end with him and the others that he wanted to bring into the teleconference from Monday through Friday. The teleconference time would be at 8 a.m. Pacific standard time, which would make it 5 p.m. in Munich, Germany. He accepted my meeting proposal. I also proposed that we both record the teleconference proceedings so that we would not miss any specification clarifications, additions, or deletions. I also told the customers project manager that I would review the meeting tape recordings daily and summarize the contents and issue the meeting minutes by e-mail to him for his approval within 24 hours. I would update the chipset design specifications weekly, release the new revision to our document control, and distribute them to the customers project manager and to my team. The customers project manager was very happy with my specification control procedures. We started the project this way. After the second week into the project, I started seeing delays in my engineers performance. Specification clarifications and customers additions or deletions were not being handled on a timely basis. This was such a dynamic project that my engineers required instant clarifications and solutions to specifications. My team and customers interface had to be in more real time. We could not wait 24 hours to get a response from the customer for specification clarifications. The communication setup was bogging down my engineers and hampering their progress. I had a team meeting to discuss the specifications and customer interface issues. Two of my senior software engineers offered to change their schedule and work a swing shift from 6 p.m. to 3 a.m. from Sunday night through Thursday night. They were used to these kinds of odd work hours from university days. They thought they would be more productive by not being disturbed by other colleagues in the office. This setup would give my team four hours of direct interface with Germany from 11 p.m. to 3 a.m. These two software designers were responsible for the most critical segments of the chipset. I told them that their proposal would be a great solution for our teams progress. This new setup would give us five hours of real-time interface with the customer.

My condition was that they had to tape record every conversation with the customer so that I could collect all the clarifications and changes regarding the chipset specifications. Also, I would have a meeting with these two engineers from 6 p.m. to 7 p.m., Sunday through Thursday, in order to review their progress, to discuss the issues they were having, to give them updates as to what was happening during the day shift, and to bring them up to date from the results of my morning call with our customer. I told them we would propose our new interface setup to our customers project manager in the morning. I also told them that I would discuss new working hours with their supervisors and with human resources so that there were no hidden kinks in the new proposal. There could have been company security issues. There could have been overtime payment requirements. These engineers were salaried engineers and there was no overtime work adjustment to their salaries. The supervisors of the two engineers and human resources found no drawbacks for them to work from 6 p.m. to 3 a.m., Sunday through Thursday night, for the duration of my project. The next morning, during our teleconference with our customer, we discussed the new working hours of my two senior engineers and how this new setup would improve real-time communication to clarify ambiguities in specifications. The customers project manager was very receptive to our proposal. My two engineers started to work in the swing shift and this new setup increased our real-time communication with the customer to five hours a day. This new setup was very effective in getting quick responses to questions regarding chipset design specifications and it lasted for six months. Also, these two software designers worked very efficiently without being disturbed. My team finished the chipset software design and test on time. I generated a complete set of specifications for the chipset which was up to date. My customer appreciated the complete set of specifications tremendously. At the end of the project, I wrote a resounding recommendation for the two software engineers who had volunteered to work the swing shift. The beauty of this solution was that the swing shift idea came from the engineers. This was a win-win situation for my project, for my company, and above all for the customer. LESSONS LEARNED FROM THIS PROJECT EVENT In a global project environment, real-time communication between your team and your customer might require unusual work schedules. As project managers, we have to notify our project team members supervisors and get their approval for changing work schedules. Keeping track of all changing project specifications and their clarifications during the execution of a global project can be very time consuming. Source: Atesmen, M. K. (2015). Project Management Case Studies and Lessons Learned. Boca Raton: Taylor & Francis Group.

QUESTION 1 (40) 1.1. Our offices were in California and my customers offices were in Munich, Germany. This nine-hour difference in the time zones brought to the surface several communication challenges, especially as the chipset specifications were written in a very concise fashion and they were open to many interpretations. Provide a brief evaluation of the team setup the two offices were using during the software project. (10)

1.2. After the second week into the project, I started seeing delays in my engineers performance. Specification clarifications and customers additions or deletions were not being handled on a timely basis. Given the problem being experienced, the Project Manager is had to take immediate action. Provide a detailed discussion of how the Project Manager can apply the Problem Solving Cycle to solve the problem.

1.3. Communication in any institution is critical to its success, and this is certainly true of projects. A project communication plan defines the generation and distribution of project documentation among stakeholders throughout the project. Given the information in the case study, develop a Project Communication Plan for the software project. (Use the template provided).

Communication Frequency Goal Owner Audience

Please answer each questions with a maximum of information. It is a question of 40 marks.