| This section describes the key roles in an outsourcing organization. Depending on the project's size, some of these roles may be shared by the same person. Also, some roles may be needed in only certain circumstances. These roles are the project manager, lead user representative, PMO project architect, internal project champion, contracting officer, and IT manager. Figure 4-1 identifies these roles in relation to the project manager. Let's examine each of these roles and how they interact with the contracting organization. Figure 4-1. Roles in the outsourcing organization 
The Project Manager Certainly one of the most common and familiar roles is that of the project manager. This role is required for all projects. The project manager in the PMO has different responsibilities than one who manages software development directly (such as for the contractor). However, the position is similar in that most of the activities involve making sure all members of the extended team are engaged in the proper activities at the right time. In essence, the project manager serves as a "traffic cop." The next section lists and discusses the responsibilities of the project manager for an outsourcing organization. Responsibilities of the Project Manager for an Outsourcing Organization The responsibilities of the project manager of an outsourcing organization include the following: Ensure that all contractual mechanisms are established and in place to permit all contractors, subcontractors, and consultants to perform their work. The project manager should examine each Statement of Work (SOW) to ensure that it clearly specifies the responsibilities and tasks of the applicable organization. This is not a one-time task. It's not uncommon for the nature of a contractor's tasks to change during a project, particularly on long-term projects. The project manager should take the initiative to review these SOWs periodically and, if necessary, involve the contracts personnel to modify the SOW as needed. This is of great importance to contractors. At the conclusion of the contract, some organizations (particularly in government projects) rate the contractor's performance against the tasks listed in the SOW. The tasks listed must be an accurate reflection of the actual work performed, or the contractor risks getting a poor performance rating. The project manager must arrange for the user community to work with the contractors so that they are available to help determine the project's requirements. This generally involves a representative (or group of representatives) meeting with the contractor analysts to discuss the business process and the specific problem that needs to be solved. The project manager should ensure that these user requests are properly documented and recorded. (This artifact should be listed in the contractor's SOW.) A good project manager ensures that users are available whenever needed so that the contractor doesn't have to chase them down. The more efficiently this process is, the more likely it is that the requirements artifacts will adequately capture the users' needs. The project manager monitors contractor performance, typically through a number of different methods: Regular written status reports Periodic status meetings Monitoring of Earned Value calculations, perhaps once a month Monitoring of other trends, such as defects, requirements, and enhancements
On most contracts, especially fixed-price contracts, users have a tendency to request everything and anything they anticipate needing to perform their work with the software to be built. In fact, they probably have been encouraged to do so. Despite this fact, a finite amount of time and resources is available to the contractor, and the contractor may not be able to accommodate every request. The project manager in the outsourcing organization should serve as the mediator to help the users narrow down their "wish list" to an amount that the contractor can accommodate. In other words, the project manager should prevent the contractor from having to negotiate directly with the users in this regard. The project manager needs to inform the contractor exactly what its responsibilities are when development is complete and the software is ready for production. The following are some typical issues that must be dealt with: Will a formal User Acceptance Test occur? If so, when will it be conducted, how long will it take, and who will have the authority to sign off on the results? What will the contractor's responsibilities be during this test? Will there be a "pilot" period or a "beta" release where users can try out the system before depending on it for production work? Must the product meet any security standards? Who will conduct the evaluation? What are the criteria for passing any applicable tests? Who will conduct any applicable training? Who will produce the training materials? If the system under development is replacing another system, is any data migration necessary? Will a Help Desk be set up by the organization operating the software, or does one already exist? Who will train the Help Desk staff? Is any special documentation required for Help Desk personnel? Who will maintain and troubleshoot the software if this is not already accommodated for in the existing contract?
Project managers also need to help manage change. For software projects of significant size, project managers should set up and chair a Change Control Board (CCB). The participants on the CCB should include the contractors (project manager, analyst, and technical lead) and lead user representatives. The purpose of the CCB is to analyze change requests, prioritize them, and agree on what is within the project's scope. The CCB should also agree on what constitutes an enhancement not covered in the work's original scope. Although this is an important function, it becomes even more vital when multiple contractors are involved. Multiple subcontractors could all be affected by a proposed change. Depending on the nature of the contract, subcontractors have a tendency to focus only on what is in their own SOW. In other words, there may be little communication between subcontractors. The CCB is an opportunity to discuss and resolve how the change may affect each contractor's work. Finally, project managers are responsible for the project's financial performance as well. Is the project on schedule and within budget? Is the outsourcing organization receiving a good value for the money spent? In this capacity, the project manager works closely with the contracts officer to be sure proper accounting practices are being followed and that the financial milestones are met.
Attributes of a Good Project Manager for an Outsourcing Organization Good project managers need the following qualities to be able to function well: Knowledge of software engineering standards that are applicable to the organization, such as the RUP, CMMI, and PMI. Ideally, experience as a software developer, IT manager, and end user. You may not find someone who has been all of these, but experience in as many areas as possible is helpful. Experience managing enterprise software development projects. If an experienced individual is not available, a strong support system, including a senior project manager that can act as a mentor, must be available. If development will take place overseas (offshore), experience with the culture, business customs, and language of the country involved is very helpful. The ability to manage and negotiate with stakeholders who have opposite goals (such as users who want the maximum functionality possible and contractors who want to be able to deliver on time and make a reasonable profit). An understanding of and experience with supporting organizations, such as IT, Training, and the Help Desk. A demonstrated ability to motivate people is a requirement. Any software project has many stakeholders, and there are times when the project will run well and other times when problems occur. The ability to motivate when the situation is difficult is one of the most important attributes of a project manager. A demonstrated understanding of managing a business. Understanding profit and loss, hiring the right people, and so on are important skills.
The Lead User Representative The lead user representative in an outsourcing organization acts as a liaison between the organization's user community and the analysts who work for the contractor. This person's purpose is to communicate the needs of the user community to the contractor analysts. Responsibilities of the Lead User Representative The responsibilities of the lead user representative include the following: The person in this role participates in the outsourcing organization's CCB. In that capacity, this person's purpose is to communicate the importance of requested changes and enhancements and rank their priority. The lead user representative should also be involved in reviewing significant artifacts produced by the contractor, such as prototypes or executable releases produced by iterations. The lead user representative also advises the contractor and the outsourcing organization's project manager on transition issues, requirement issues, and anything else that reflects the end users' desires, concerns, and issues.
Attributes of a Good Lead User Representative The attributes of a good lead user representative include the following: A typical lead user representative has been with the outsourcing organization for many years. She must be familiar with all aspects of the organization's business processes. For those areas of the business in which she might not have the latest information, the lead user representative should know exactly who to contact. In fact, the person in this role is generally very well known and respected throughout the organization and is recognized as an authority figure. The lead user representative should be able to carefully and fully articulate the organization's needs. This person needs excellent oral and written communication skills. The lead user representative should be able to take the time to answer ad hoc questions from both the contractor and the outsourcing organization's project manager.
Typical lead user representatives are very busy people who have other jobs they must perform and are not dedicated to a specific project. However, it is vital that they have the time to adequately support the project and to answer questions. The attitudes of other users in the outsourcing organization often depend on their perception of the lead user representative's attitude. The PMO Project Architect This role is optional, because it may not be needed on smaller projects. It is generally required when a project is large enough to need multiple contractors, and each contractor is developing a portion of the system. Why Is This Role Needed? I have been involved in several large projects that had multiple contractors. As with any project, SOWs are written and given to each contractor. At that point, most contractors adhere to working on the tasks specified in their SOW. This makes sense, because by definition, if the contractor successfully completes all the tasks in his SOW on schedule and within budget, he has done his job. Accordingly, the following are actions I have seen on projects in this scenario: Each contractor performs development on his own servers. If the application has a Web interface, the contractor acquires his own Web server, application server, and application server software. If persistent storage is required, each contractor has his own database server, database software, and database instances. This decision is good for the contractor, because he maintains control over the environments in which he develops. This minimizes interruptions from other contractors, the customer, and so on, thus ensuring maximum availability of the environment required by the contractor to meet his deadlines. The problem happens during integration, when the use of different servers by different contractors results in difficulties. In some cases, the system gets delivered with multiple database servers, multiple application servers, and so on, which is unwieldy and more expensive to maintain. The contractor tends to make decisions about the environment that are not specified in the SOW. In some cases, the information may be conveyed to the outsourcing organization, but it seldom gets communicated to the other contractors. Although each contractor presumably has been given a different portion of the system to develop, some data elements are common to all portions of the system. This makes sense, because the project as a whole is for the same customer, and the same business process drives the system design for all portions of the system. Unless specific measures are taken, each contractor develops her own code to describe and manipulate these data items. This code should be written only once. Developing her own code is a duplication of effort and can result in problems during integration because the common data items might be treated or defined differently by each contractor. "Glue" code is developed. When integrating portions of large, complex systems, some code might be needed to interface the components. An example is a component's application programming interface (API) and the associated code for integration. These items may not be anticipated and spelled out in the contractor's SOW. If they are not, the contractors will not pay much attention to them, to the detriment of the system as a whole. The PMO project architect recognizes these situations and takes steps to ensure that this aspect of the project receives the proper attention.
It is not possible to anticipate all these situations when a SOW is written. Without someone to champion the cause of the tasks in the SOW, these and similar issues can undermine the architecture and the integrity of the system as a whole. This is the purpose of the PMO project architect. The PMO project architect reports directly to the project manager of the outsourcing organization. As an important member of the PMO, this role is empowered by the project manager to work closely with the individual architects and technical leads at each contractor. Responsibilities of the PMO Project Architect The PMO project architect provides many benefits to a project. This person works to establish architectural standards and ensures that all contractors consistently follow these standards on the project. The responsibilities of the PMO project architect include the following: The PMO project architect identifies and establishes standards for the environment in which the software to be produced will operate. For example, does the outsourcing organization operate only Windows-based servers in its data center? If so, a solution involving UNIX may be unacceptable. If these sorts of decisions are known before the project starts, the architect's job in this regard is to publish the standards and then make sure all contractors abide by them. Otherwise, the PMO project architect works with the architects on each contractor team to develop standards that satisfy the needs of all the stakeholders involved. When the system has been partitioned in such a way as to allow the work to be delegated to two or more contractors, there may be interfaces between the portions of the system. The PMO project architect works with each contractor to make sure that the interface is accommodated in the design and that any appropriate APIs are built. If the organization has established an Enterprise Architecture, the PMO project architect should ensure that the solution proposed by the contractor is compliant with it. The PMO project architect either develops or provides a set of user interface design standards to each contractor. If each contractor's portion of the system has a user interface, these standards enable consistency between the user interfaces built by each contractor. The PMO project architect verifies enforcement of these standards. The PMO project architect should establish or provide standards for other software needed by the systems as well. Some examples are database, application server, report generation, and other Commercial Off-The-Shelf (COTS) code. Many outsourcing organizations with large IT needs may already have site licenses for some applications, thus making certain choices cost-neutral. Every IT application has certain abstractions and core functionality that are part of the environment and that are needed by applications operating in that environment. When multiple contractors are involved, each contractor focuses on developing their portion of the system. This means that without careful coordination, each contractor develops his own code to manage and represent the abstractions and functionality that are part of the environment. This means that each contractor is creating duplicate code. In addition to wasting resources, this can result in integration problems, because the representation of the data defined by this code may vary between the implementations. The PMO project architect should identify potential areas of duplication and prevent it from occurring. Refer to the "Other Role Issues" section near the end of this chapter for a suggestion on managing this situation. The PMO project architect should work closely with the architects of each contractor. In particular, the PMO project architect should be satisfied that the architecture proposed by the contractor architects will meet supplementary requirements, such as performance, response time, scalability, failover, reliability, and redundancy.
Attributes of a Good PMO Project Architect The PMO project architect is technically proficient but is more interested in seeing the big picture. Most likely, the PMO project architect was once a very experienced developer and technologist. Instead of progressing to a project management role, his desire to "stay technical" and his disinterest in the more mundane activities of project management led him to this role. The PMO project architect is fascinated by technology and is knowledgeable about the latest technologies. He is also a trusted advisor to the project manager of the outsourcing organization. The PMO project architect has technical depth, plus the time to investigate technical issues at length, and he advises the project manager on these issues. The PMO project architect is also very familiar with the needs, plans, and goals of the IT organization for which he works. The Internal Project Champion The internal project champion is vital to a project, especially during the initial stages of the product's being rolled out to the user community. Ideally, the internal project champion is a respected member of the user community. Occasionally, on smaller projects, this person may also perform the roles of lead user representative, project manager, or PMO project architect. Why Is This Role Needed? The internal project champion can have a significant impact on a project's success during two periods in the project lifecycle. As explained in Chapter 9, "Navigating the Requirements Management Process," user involvement during requirements elicitation activities is vital to ensure that the developed product meets user needs. Users generally are very reluctant to get involved with these activities. The internal project champion role generates enthusiasm in the user community to encourage active participation in the requirements elicitation activities. The second period when the internal project champion is important is during the project rollout. The acceptance of a new product and the incorporation of it into the users' work generally follow a standard bell curve. The acceptance and attitudes developed toward the product are heavily influenced by perception. The internal project champion, forever the optimist, encourages users to try the product, to overlook its immediate shortcomings, and to see value in adopting its use. If the internal project champion is a respected member of the user community, her message will be heeded and will positively influence acceptance of the product by the user community, making the project a success. The Contracting Officer The contracting officer is an often-neglected role on projects. This person manages all contracts relating to contractors and vendors for a project. His expertise is strictly related to managing a project from a business perspective. This person's work helps ensure that all contracts adhere to the laws, rules, and regulations affecting the project. If the project involves offshoring and use of vendors from other countries, this person needs to be familiar with the differences in contracting law between the countries involved. I frequently hear contracting officers complain that they never hear from members of a project (even the project manager) unless the project is in trouble. Although the contracting officer may not have expertise in software, his opinions can offer a unique perspective on the project's performance from a financial viewpoint. Furthermore, during any contract negotiations, if the contracting officer understands the project manager's position, he can negotiate more effectively. The IT Manager In most organizations, the IT manager is responsible for operating and maintaining the product developed by your project. The IT manager is not hired for the project's purposes. You will work closely with the IT manager in your organization. The IT manager's typical concerns and responsibilities are as follows: When will the application be installed in the environment? What additional hardware will be required to run the new application? Does the hardware conform to the specifications required by the IT manager's organization? When will the IT manager assume responsibility for the new application? Have all the outsourcing organization's applicable standards been taken into account? These include the following: Does the application conform to the organization's security needs? Does the application work with the current configuration of the systems used by the end users? In other words, is any special software required to be installed on enduser systems? Can the new application work with the versions of browsers, operating systems, and so on currently running in the organization? Does the application have any special consideration for backup and restoration? Can the current backup/restoration solution in use by the organization work correctly with the new application? What COTS software does the new application use? What software licenses need to be maintained, and how much will this cost annually? When are the licenses due to be renewed?
What does the Help Desk need to know to successfully field calls about the new application? What is the expected level of usage? How many calls will the new application likely generate for the Help Desk? If your IT organization also handles the training for your users, who will train the trainers? What training materials will be produced, and by whom? Who will be responsible for maintenance and upgrades of the new application? Will any legacy applications need to be deactivated when the new application goes online? If so, which applications? Who uses those applications?
These are some of the questions the IT manager is likely to face. The project manager of the outsourcing organization should have the answers. The most common complaint heard from IT managers is that they are not involved in the advanced planning for new applications. They often find out shortly before the application is delivered that they will be receiving a new application and a new set of servers to maintain. Involving the IT manager well in advance helps the new application's transition to production go much more smoothly. |
