1. ANALYSE the case study provided. This will form the basis for your Project Charter, because you will assume that you are the project manager for this project. 2. After reading the case study, begin to develop your project charter.use minimum of six referencesand industry publications.

3. The Project Charter must include the following headings and should be written as if you are presenting it to the project team that will build this project. You are the project manager. The contents of your Charter should include: . Background of the project b. Reasons for the project c. Project objectives d. Proposed project management approach or methodology/methodologies e. Constraints, limitations, and risks f. Leadership structure (project manager and his or her senior aides: list their roles and explain what each does in the project. You need to cite four (4) roles) g. Project risks and their mitigation h. Project stakeholders and how to interact with them i. The vision of the project and the type of project team culture you wish to promote in your team.

Case It was a tough time for Mr. Shankar Elan, the program manager responsible for rolling out Helpdesk Management (HDM) in all the divisions of The Clementon Company's (TCC) IT operations. A month ago, when the base version of HDM was rolled out to the Latin American users, it turned out to be a nightmarish situation for Mr. Elan and the whole HDM team, as they got to know that there were more than 80 post-production defects. While the HDM team is still clearing away all those defects, the client management is insisting on the successive roll outs of the product to other geographies and other operational units with the requested functionalities within 5 months from now. The roll out that went ahead last month was limited to only less than a hundred users of the Incident Management functionality of the product, and these were all people who have not used any sophisticated tools for this functionality prior to this roll out. Other features of the product such as Change Management, Configuration Management and Problem Management were not required for the users in Latin America. In comparison, the final roll out is aimed at several thousand users across the globe, including those who have used other sophisticated tools for functionalities such as Incident Management, Change Management. This would mean that those users would be more critical in reviewing the features of the product and the number of defects reported could go very high, if proper attention is not given to the requirements or if the expectations about the product are not set right in the minds of the users. Only the help desk users (of TCC) of Latin America are using the product right now, and in a few months' time, the same tool has to be rolled out to all other operational units. Mr. Andrew Partha, vice president, Infrastructure Delivery Unit of Iota Consultancy Services (ICS), is also the head responsible for all the proprietary software products developed and owned by ICS. He has entrusted Elan with the huge task of successfully deploying the HDM product in TCC's IT landscape. The recent customer complaints about the poor performance of the product have annoyed him and the pressure has percolated down on Elan. He has to find out ways to ensure that the product implementations in other geographies planned in the coming months will go smoothly. About TCC TCC is a leading market research firm and has its operations spread across the globe. In order to expand its scope and scale, the company acquired several smaller research agencies in various countries. The IT operations of the organization are broadly classified into four divisions: 1.TCC Helpdesk; 2.Application Development and Maintenance; 3.HR Payroll and Benefits; 4.IT Infrastructure Services. TCC Helpdesk is the entity responsible for handling all the calls from TCC's internal and external customers, who call to report the issue they face. The operations of TCC Helpdesk have increased significantly after the recent acquisition of many smaller firms; hence, their call handling is done in silos these days. For instance, if a customer calls the help desk of Australia to report an issue, and if the customer service representative finds out that the problem is because of an application hosted in a server located in Hungary, the incident record created for the call cannot be transferred to the team in Hungary. Instead, they have to call the help desk of Hungary and create another incident record. Thus, they are in need of a tool that would enable them to handle not just their regular activities, but will also have a provision to transfer tickets to help desk teams located across different geographies. Application Development and Maintenance team, simply known as the ADM team, has its presence in different parts of the world, though not as geographically diverse as the help desk. However, a vast majority (70%) of the members of this operational unit are located in North America, while around 20% of the team members are located in their offshore development center in India, and the remaining 10% are located in France, Australia, South Africa and Brazil. This ADM operational unit was not greatly affected by the merger activity, except for the addition of a handful of software engineers and managers. The members of this unit have all been using a single IT Services Management (ITSM) product and this tool helps them handle processes such as Change Management, Problem Management and Incident Management. It is a highly sophisticated tool and the users are exposed to the comfort offered by this tool over the past 5 years. HR Payroll and Benefits team is undergoing a sea change in the past few months, following the acquisition of several companies. Although the team is not as big as the help desk team, the complications with respect to aligning the HR policies and other employee benefits of TCC to that of the other acquired companies have been extremely challenging. Some of the users have been using industry products for Incident Management, while others are tracking incidents just in an excel sheet. The head of this operational unit is determined on rolling out a single tool to handle their incidents, in an effort to streamline their day-to-day operations. IT Infrastructure Services team is another operational unit that manages the complete Infrastructure Services required to run the business of TCC. Recently, as part of the contract signed between TCC and ICS, this team is in the process of handing over a majority of their responsibilities to the ICS team. A large part of the transition is already over and the ICS team has started taking ownership of several infrastructure operations in multiple geographies. This team uses the same tool that ADM was using to handle Incident Management, Change Management, Configuration Management and Problem Management. The different operational units of TCC and the geographical locations of these operations are shown in Exhibit 1. ICS is responsible for rolling out HDM in all the operational units located in all the geographies. The aim is to streamline and standardize the key processes of their IT operations, namely, Incident Management, Change Management, Configuration Management and Problem Management. Although both the companies had access to skilled manpower and related resources to do this activity, the whole exercise was quite complicated. About ICS ICS is one of the rapidly growing software exporters in India and has started competing with bigger players in the Indian software industry. Over the past 10 years, ICS has grown steadily; today, it is one of the leading software service providers in India. ICS is capable of providing IT services and Business Process Outsourcing to many of the Fortune 500 companies across the globe. The company also has quite a few software products, but none of them were major hits. HDM is one such product designed and developed by the R&D team of ICS. This is a tool that is supposed to govern the key IT Service Management processes such as Incident Management, Change Management, Configuration Management and Problem Management of any organization. ICS has been using this product for its internal needs for a few years now. Exhibit 1: Structure of The Clementon Company Long Description One of ICS' largest deals in recent times and in its 10-year-old history is that of providing IT services to TCC. As part of the multi-million-dollar agreement signed between the two companies, the maintenance of TCC's entire IT infrastructure was outsourced to ICS. This entailed that all the data centers and servers that supported the various business processes of TCC would be supported by ICS. The various processes that comprise IT Service Management should be streamlined as well. The complexity of this task was aggravated by the recent acquisition of many companies, and also by the fact that the operational units of TCC are located at different geographies, serving different purposes. Background of HDM Program One of the major challenges faced by ICS was of standardizing the IT processes practiced, followed by TCC's business units spread across the world. Prior to the merger, all the different units followed their own IT processes. For instance, the Incident Management activity in the North American regional offices was handled by a popular ITSM product in the market, whereas the Incident Management activity in TCC's help desk was handled by a different product. Although the basic functionality offered by different Incident Management tools is similar, the workflows configured in these tools were obviously entirely different. Both TCC and ICS wanted to cull away the discrepancies regarding the way certain key IT processes are executed. ICS is a leading player in the IT Services domain and also has a few IT products to its credit. One of their tools is HDM. This is also an ITSM product that can be implemented in any organization to handle key IT processes, namely, Incident Management, Problem Management, Change Management etc. Since TCC's entire infrastructure is outsourced to them, ICS felt that HDM can be considered as the single tool that can be deployed across the organization. The initial survey by the process consultants of ICS to select a product for the IT enterprise of TCC resulted in a listing of the major requirements sought by different operational units. After consolidating all the requirements, the process consultants did a feasibility study to determine whether the requirements could be satisfied by the HDM product of ICS. They also did a comparison against standard market products. Although the market products were superior in functionality as compared to HDM, the ICS consultants voted in favor, due to the following reasons: Products offered by external vendors are costlier to procure and install as the licensing cost was significantly high. Ongoing maintenance of those products will also result in higher expenditure as compared to HDM. The requirements of multiple operational units are still not standardized and hence even if an instance of the product offered by external vendor is rolled out for a specific unit/geography, there are high chances that they might undergo revisions later and the product should be customized according to evolving needs. In such a scenario, HDM would be a better bet as it costs less to customize, since it is an in-house product. Multiple tools deployed for handling similar processes would mean the overhead expenses are huge. For every tool, there is a need to pay licensing fee, annual maintenance charges etc. If HDM is deployed, there won't be any licensing fee as ICS is the product owner. Also, since there are many software engineers in ICS who have the expertise in working with the product, the maintenance charges would be less, as compared to that of a product owned by an external vendor. Structure of HDM Team Once Elan was identified as the Program Manager in charge of rolling out HDM for TCC, he did not waste time in framing a structure for the new team. He decided to divide his team into two unitsone responsible for product development, including activities such as Customization, Migration of data from older tools and the other responsible for product deployment, including activities such as setting up the configuration of the various parameters for the users of the tool and the technical architecture for hosting the HDM application for end users. (For a detailed organization chart, please refer to Exhibit 2.) Exhibit 2: HDM Project Team Structure Long Description The different modules under product development are as follows: Integration TeamResponsible for integrating HDM with various other tools and products available in the IT environment of TCC. To name a few, there are network monitoring tools which constantly examine key parameters with respect to servers and other network devices. Any alert or warning should be notified to the respective support group. When HDM is rolled out, an incident record should be automatically created and assigned to a specific support group to handle the alerts raised by the network monitoring tool. Similarly, when the TCC help desk receives a call from a user, she or he may be asked to enter the incident record number over the dial pad, when that person asks for an update on the incident record that was already created. In such a case, the corresponding incident record should be opened for viewing in the desktop of the help desk agent who attends the call made by the user. Customization TeamResponsible for enhancing the features of the HDM tool, based on the different requirements proposed by the clients from TCC. They work with the representatives of each of the four operational units, understand their requirements and take them to the next level to incorporate those features into the product. Many a times, this team feels the heat while convincing the representatives to standardize the IT Service Management processes across different operational units. Data Migration TeamResponsible for migrating/changing the existing incident records from the products that are currently being used by the clients to the new tool (HDM). This is necessary because once the new product is rolled out, the clients would want to refer to any older tickets in the same tool, rather than opening the old product and pulling up a record from there. Testing TeamResponsible for testing the new features developed by the other teams. They have the critical responsibility of ensuring that the products comply with the requirements and also that the tool functions smoothly, without breaking up in the middle of any activity. The different modules under product deployment are as follows: Data Configuration TeamResponsible for configuring the various users of the tool and also the information about the support groups, who will be part of this tool. The right permission has to be set for the right users. Similarly, the workflow configuration for different kinds of incidents and the change of records are done by this group. They interact with TCC's clients to understand how the incident records were classified and determine how the workflow should be configured for the differently classified incidents/changes. Infrastructure Architecture TeamResponsible for deciding the required technical architecture for the product roll out. Decisions about the numbers and types of servers, the software applications that are to be installed in the server, the hard disk capacity etc. are all taken by this team. This team is in charge of the database and application server and they also devise strategies for backup and disaster recovery. Production Support TeamResponsible for supporting the HDM product. All issues reported about the HDM tool are handled by this team in tandem with other development and configuration teams to set right the defects detected. This team runs 24*7 as the issues can be reported by anyone from anywhere across the globe. As one can notice, the teams here have been structured on the basis of different capabilities. The work products are passed sequentially from one team to another. For example, the tool was customized to build all features, then the testing team validated the features and then the data migration team ported data from older systems to HDM. Then the production support team was addressing the issues reported by users in the production environment. The structure of the teams did not provide for closer collaboration and identification of defects earlier in the lifecycle or receive constant feedback. What would have been interesting is having a different blend of the teams in order to have people with multiple capabilities working together in a collaborative environment, seeking feedback and addressing issues on the go. Challenges Ahead of Elan and His Team The process consultants decided to go ahead with HDM for the standardization of IT processes because of the reasons stated above. However, they overlooked the fact that HDM had not been deployed as a comprehensive ITSM product for any organization as big as TCC. The previous implementations of HDM were to clients in a much smaller scale, with a maximum of a few hundred users, who were neither geographically dispersed, nor had used any ITSM products in the past. Unlike the TCC clients' demands now, they had not had varying requirements. The architecture used for those earlier implementations was very similar to the one used by ICS for its in-house implementation. Now with the proposed implementation of HDM for TCC, the tasks ahead are daunting. Also, the final architecture is not decided by the team headed by Prasad, who reports to the deployment manager Vivek, who in turn directly reports to Elan. The user community from different business units wanted to retain the functionalities that they experienced with their old tool, in the new tool as well. As a result, the number of requirements that had to be customized was too huge. This was the case with all those users who had experienced the top ITSM products. On the other hand, in certain geographies, the clients were just using the excel sheet to record incidents reported by callers and didn't have any sophisticated ITSM product. For them, any dedicated tool was good enough to support their business processes. By and large, the product team figured out that the requirements of the HR Payroll team and the Helpdesk team were similar, as were the requirements of the ADM and the infrastructure teams. Thus, the HDM team initially tried to create two instances of the same product, to tackle with the problem of varying requirements from multiple operational units. There were new initiatives inside the operational units, with provisions to transfer incident records or change requests across these units. Such a provision did not exist before the merger activity. Now as the organization wanted to roll out a single ITSM product across the globe, they wanted to have seamless integration across multiple operational units and that necessitated such transfers across units. Elan has been pondering over a few questions. Was the decision to install HDM, to cater to such a diverse group of users with diverse requirements, a good one? Did the process consultants really compare the capabilities of HDM vis--vis the more flexible products in the market before taking this decision? Were they aware that HDM had never been rolled out in such a big scale before? Had they simply overlooked these important facts? Have I made any mistake in terms of structuring the teams for this program? The development teams follow a waterfall model to incorporate the features in the tool. Given the very short time frame to integrate all the requirements into the tool, will this team structure hold good or should I weigh other options? Should I go to Mr. Andrew Partha and explain to him frankly that the product is not very efficient, and trying to pitch in this tool against the market leaders is not a good strategy? Will he understand and appreciate my viewpoint, or will he get irritated, as he is also under pressure? ICS wants to showcase the successful roll out of HDM for TCC to the outside world, and thereby earn a reputation as a good product company too. This tag will help gain more projects and hence more revenue for ICS. If that happens, my team and I will be greatly appreciated and rewarded. Can I still hope for success, or should ICS not have thought of entering the software product space dominated by market leaders? Should we have just concentrated on software services and outsourcing, which until now has earned millions for the company? Project Planning Requirements Gathering The customization team conducted several requirement gathering sessions with multiple stakeholders. Following is the exhaustive list: 1.Infrastructure leads from United States; 2.Application support leads from United States; 3.Third-party ticketing tool admins from United States. Once the requirements were collected from these various stakeholders, a consolidated list was prepared and sent out to the same stakeholders for validation. The sign-off was not formal; the offshore development team manager and the onshore coordinators were finding it difficult to obtain an approval for the understanding of requirements. Some of the stakeholders were reluctant to freeze the requirements until and unless they saw the new features and were able to use them in the tool. Nevertheless, the offshore team started their development work and started prioritizing, designing and developing the features. Little did they know that whatever they develop would go through a lot of changes. It so happened that the requirements were not standard across all the modules (Incident, Problem Management etc.) or across the various teams, and they were certainly not etched in stone. As there were multiple teams who were used to different ITSM products, just collecting all the features across the tools and drafting a consolidated requirements document turned out to be a mammoth task. Realizing those requirements using HDM, given the inherent constraints and limitations of the tool, was a challenge. The users of the system were better off working directly on the tool to understand the various features and improvise upon those than trying to finalize the requirements on paper before the commencement of the design and build activities. Project Planning and Testing The project plan prepared by the development team was as follows: There are 2 major releasesV1.0 and V2.0. The first release is slated for March 201X (around 5 months from now) and the second release is scheduled 3 months later (i.e. June 201X). Each release will have 4 phasesfirst for EMEA, then for APAC, followed by LATAM and finally for US. There are sessions scheduled to demonstrate the product features, exactly 2 weeks before each phase of every release for each geography. Hence it is decided that the complete testing, including UAT, should be completed a week before the demo sessions start. The task is cut out for the project delivery team. In 4 months' time, all the 190 requirements listed in the consolidated excel file are to be completed. The project manager will have an internal interim checkpoint to ensure that the team completes at least 100 requirements by end of this year. After investing significant effort in building the system, the project team realized that there were too many defects in production, mostly because the validation with stakeholders on various features happened only toward the end. As per the sequencing of the current project development approach, user testing was done only after developing all the stated requirements. Instead, having frequent test cycles, where the users are given an opportunity to play around the tool and provide instant feedback, would have been more effective. Had this happened, the development team would have had ample time to resolve the issues and to implement a relatively more stable application in the production environment. What lies ahead? It was the end of the calendar year. The project manager directed all the team leads to check whether all the interim milestones had been met with. After a detailed verification of how the project was progressing, the team leads were happy to note that about 105 requirements were completed in the development environment. The unit test cases had been developed for all of them and the test results were clearly documented as well. When the project manager heard this, he was confused and skeptical because while he had set the interim milestone as the completion of 100 requirements in the development region, he had not mentioned anything about testing the features overall or performing an integration testing. He comforted himself by thinking that if the unit testing is good, then it is more likely that the end product will also turn out to be good. He cheered the team by wishing them a happy New Year and was hopeful that things will be completed satisfactorily in the New Year. It was New Year's Eve and one of the development leads, Karthik, was on a trip to Goa with some of his old friends from college. Most of them are now working for IT services firms and consulting firms. Over a drink in the resort, they were sharing some of the trends and things that interested them the most. One of Karthik's friends, who is a consultant in agile methodology of software development, was very passionate about what agile can do and how it can help organizations. When he said, "Organizations have to choose the right software development methodology very carefully, if they are to succeed," Karthik interrupted, "Hey! I'm with this same IT services firm for the past 8years. I've never used a different development methodology than waterfall. Is it not true that agile is only for product companies?" His friend replied, "What if your IT services firm gets into developing a product?" The bartender intervened with another round of tequila shots. The friends toasted the New Year as the clock struck 12. It was celebrations all over and the conversation digressed after that. When he woke up the next morning, Karthik remembered his conversation with his friend about agile methodology and decided to find out more about this methodology. He spent a couple of hours reading about stories, scrum, sprint etc., but he was not able to comprehend these terms completely and relate their relevance to his current project. The teams resumed their work in the New Year and were determined to finish the remaining requirements well before deadline. Soon came the end of January, and the manager decided to kick start integration testing. On 31 January, all the development work was completed and the User acceptance testing started. At the end of Day 1, 75 defects were reported by users across multiple business teams and geographies. The leads and managers took a close look at the defects. A couple of them are listed below: 1.In the Incident management module, three severities were requested "High,," "Medium" and "Low.." They are listed in the drop down, but we want it this way "1High," "2Medium," "3Low." 2.In the Change management module, the task created always gets routed to a default group. However, it must be routed to different groups depending on certain parameters. 3.In the Incident management module, when the incident is about to violate the response SLA, a reminder should be sent 15 min before the violation. We would like to have a provision to configure it differently for different severities. The team watched in horror as the challenges started piling up. Someone said, "These are new requirements. We have to turn down these requests." Another said, "Whoever had gathered requirements didn't do a thorough job to capturing all the requirements." A few were apprehensive that some of these requirements will not be satisfied by the out-of the-sbox product functionality, and may require heavy customization. Karthik wondered, "Would this scenario have been better if we had engaged with the clients more often and much earlier?." The clients were used to traditional software development methodologies like waterfall. They are comfortable operating in an environment, where they state their requirements, validate them and then perform a detailed User Acceptance Testing much later, when the project team has completed the development. The moot question here is whether the clients can adopt a culture where they sit together with the development team, provide continuous feedback and evolve the product in an iterative fashion? This clearly requires a different cultural mindset, and more importantly, a different set of capabilities. Karthik arranged a brainstorming session with all the leads and the manager, to discuss the various queries that haunted him, regarding the team structure, the requirements of management's approach etc. Brainstorming sessionoffshore delivery team The meeting, as one can sense, was very intense, and the participants were in a mood to blame each other for this state. Vikram wanted to ensure that there was some order and meaning to this discussion and invited the leads to talk about the problem and their proposed solution. Karthik was prepared to drive his points at any cost. He was ready to present a few slides that highlighted the differences between agile and waterfall models of software development. He also was keen to justify as to why he felt that the agile model was more appropriate for this engagement. He also had a few additional slides that explained about scrum, sprint, stories etc.