Challenges facing a program manager operating in a product company when located in a region attuned to services-based project management
Program Manager, Adobe Systems
The following study attempts to analyse how Program Management is being taken up at some of the product companies in India. It also tries to compare this relatively nascent profession with the much established Project Management which has been existence since the advent of software development in the region. Since the author hails from the Software Engineering industry, the data and opinions in this study are reflective only of that industry. If they are applicable to any other industry, then that is just coincidence. Further in this study, services organisation would refer to an organisation whose business is to deliver projects for another organisation. Product organisation would refer to an organisation which creates its own products which might be sold off the shelf or integrated as part of solutions by 3rd party services organisations.
The first part of this paper looks at how a project manager, raised in an environment where delivering IT services was the mainstay of the job, adapts to the need to lead and work with cross-campus, cross-functional teams engaging in product development activities. The second part looks some of the challenges faced in this role based on inputs from a number of software engineering professional from India working in various roles.
“A project is complete when it starts working for you, rather than you working for it.” (Scott Allen 2005)
For those of us who come from Asia and specifically India/China, it is easy to believe that we have computer science knowledge running in our blood. Why, from the time a child is born, the parents have already decided that she would become an engineer or a doctor of medicine. Globally the Indian subcontinent has been hailed as the software superpower, churning out more software engineers in current times than any other region in the world. The software engineers from this region have had a chance to work for various large corporations and in regions as diverse as North America, South America, Continental Europe, Great Britain, Scandinavia, Asia-Pacific, Africa and Oceania. Thus the South Asian software engineer has gained an experience of working and delivering for the corporations so that their operations are taken care of. Lately Asia-Pacific (India, China and Singapore in particular) are fast becoming the hub of development and testing for many of the multi-national corporations which earlier imported software engineers from here. Since a lot of these corporations are into developing products of their own, this brings in a whole new opportunity for the services project manager, Program Management. This rise of product-oriented development executed by these corporations within this region has brought in the need for uniquely different project management skills. It has also brought in some of the terms associated with job descriptions more prevalent in the regions where these corporations came in from.
Project Management as Practised at a Software Services Company
Securing the work
A large Personal Computer manufacturer in US brings forward the issue of creating an online PC diagnostic controller framework in front of a Business Relationship Manager of a large Indian consulting company. The controller would allow them to test their PCs while not having physical access to them. A team of software engineers from the software consulting company is already busy developing Linux and Windows based diagnostics for their PCs. Owing to time and cost constraints and in an effort to maximise revenue from this project, the Business Relationship Manager routes this case to a delivery centre head of the consulting company who is based in India. The centre head passes it to the Group Lead who realises that he has to pick up some experienced member from his team of 60 odd members to lead this project to completion.
The team gets formed
The Group Lead finds that Mr. Ramesh is the right person for the job with his technical background in this domain and assigns the project to him. This would be his only project till delivery is finally accepted by the customer. Ramesh communicates with the Business Relationship Manager and after this discussion realises that he would require a team of eight to ten software engineers within the 3-month deadline. The Group Lead can only assign him five engineers at this time and two out of these would be fresh out of engineering school. One engineer would have to come in as Technical Lead from the onsite team which is developing diagnostics for the customer. Even for these resources, the Project Manager has to talk to other Project Managers via the Group Lead for getting technically competent staff. Ramesh agrees for now and starts technical dialog with the customer through the Business Relationship Manager.
With the technical hurdles cleared, Ramesh knows that he would have to interact with the following project entities.
|Team||Team Role||Points Of Direct Contact for the |
|Personal Computer Manufacturer||The customer for whom the controller is being developed|| |
|Software Consulting Organisation||Organisation employing the Project Manager which has to deliver the project|| |
|Internal Quality Assurance (QA)||Maintain audits and checks for maintaining the quality certification for the organisation as a whole|| |
|Local Infrastructure Support||Infrastructure resources and support during development and testing|| |
The interface specifications, scope and technology have already been specified by the customer in the Statement of Work. The initial estimates are done by the Project Manager and communicated to Group Lead. They have to be retrofitted into the timelines suggested by the customer which means an average work week of over sixty hours for engineers and even more for the Project Manager over the project's development cycle.
The development takes place with risk, requirements and results consistently communicated to the customer's Program Manager and issues resolved when highlighted. Technical issues are handled by the Technical Lead. Project resources, team management, customer communication and high-level technical inputs are maintained by the Project Manager. Project Manager and Tech Lead do the design while everybody codes and unit tests. The documentation for the project is also undertaken by the project team itself.
The processes for development and testing are very well defined in terms of expected metrics adherence. They follow a standard such as SEI-CMM or ISO under audit and guidance from the QA group.
Testing the deliverables
Once the controller has been developed, the integration testing is done by the development team itself. The QA group ensures that the project related metrics are in conformance to the centre level ones so that the quality certifications can be maintained. For this there are quite a few activities the project team is supposed to perform and metrics they have to capture.
Customer acceptance and hand-off
Once internal tests are successful, the Project Manager travels onsite to the customer site for acceptance testing. When the customer's Program Manager has accepted the deliverables, he fill the customer satisfaction survey and return to the Business Relationship Manager who passes it to the Group Lead and finally the Project Manager.
The Project Manager gives his inputs to the Group Lead on each of the team members which would be used during the annual performance appraisal cycle. His role is over and the team is disbanded. The Group Lead assigns him another new project.
Program Management as practised at a Software Products Company
Securing the work
The E-team at the product company comes up with a corporate strategy to enter the Linux market. It is evident that the corporate global systems need to be geared to support the product availability and support for the target market before the product is ready. The strategic milestones are set and communicated. One of the required components is the Download Manager which would be able to service the Linux community. The Head of the relevant Business Unit (BU) pitches to the corporate strategy team and secures the work. There is a strategic fit for the component in the business unit. While all resources might not be available in this group, it will be managed by a Program Manager who reports into this business unit. In most cases, the Program Manager is already managing several other projects which are in a similar domain. Thus the Program Manager is empowered with the project charter of having this component made available and supported.
The team gets formed
The BU head pulls in Mr. Ramesh, the Program Manager who reports to him and asks him to come up with various teams that need to inter-work to deliver. It is decided that Engineering would be taken up by an Engineering Manager in the group, Quality Engineering by a Quality Engineering (QE) Manager in another Business Unit. Rest of the interfaces have to be worked out by the Program Manager. The Program Manager receives the very limited set of documents that have been developed by the remote team based in US which had initially developed the Download Manager for the Windows and Macintosh platforms.
An initial meeting is setup between the Engineering and QE teams based in US and India. There is an understanding which needs to be developed about the people, processes and deliverables. It is soon realised that there was a very lightweight process that was being followed earlier. This is common to most product companies working in an environment where market requirements are changing dynamically. The Program Manager realises that there is a major personal effort which would be required since the limited time and fixed cost model in which he has to deliver has also to take into consideration for an agile development methodology and low process-orientation.
Based on past experience and discussion with some of the stakeholders, he foresees that these are the following teams he would have to work with over the estimated nine month Product Life Cycle.
|Team||Team Role||Points Of Direct Contact for the Program Manager|
|Product Team||Involved in developing the Linux-based product to be shipped using the Download Manager|| |
|BU managing the component development||The team which will hold the overall responsibility for the program undertaken|| |
|Other BU||QE Manager's BU|| |
|External Vendors||Linguistic testing of localised builds|| |
|Worldwide Information Services||24x7 infrastructure support during development, testing, deployment and customer availability|| |
|Worldwide Technical and Customer Support||24×7 technical support for component and related products|| |
|Online Store||Final deployment environment team|| |
|Legal||Guidance on legalities of 3rd party code reuse and Licence agreements|| |
These teams are located in India as well as multiple locations in US. Thus there are multiple potential challenges.
A kick-off meeting is followed by a Project Plan which clearly highlighted the team members, roles, responsibilities, work breakdown structure and timelines. The subsidiary technical plans were based on inputs from that particular technical team. Example is Configuration Management plan from the Engineering Manager. This clearly sets the tone for integration and escalation paths.
The Program Manager works with the Product Manager from the products teams and also inputs from engineering manager's teams participating in this effort on features and their priorities for the current release of the component. A Product Lifecycle (PLC) is chosen which is suitable for the type of component and the timeframe in which it is to be developed, documented, tested, deployed and supported before work on its next release can begin.
The technology options are open-ended as long as they serve the purpose of the accepted requirements. The Engineering / Quality Engineering Managers have a direct say in what they want to use as long as that technology passes legal compliance which is also moderated by the Program Manager.
During development, constant communication is passed from the Engineering via the Program Manager so that any changes, requirements from other teams can be assessed in real time. If any change requests come in, they are handled by a Bug Review Council which is usually led by the Program Manager. The geographically distributed nature of this development makes the communication task extremely challenging.
Initially the English version of the component is built with a localisation/globalisation framework. This would allow the localised builds to be created with minimum development effort once the framework is in place. This development is managed in many cases via a Localisation Engineering Manager.
The Download Manager would first need to install itself and then install the download product. This would mean that the customer who downloads should be able to set the install directory, preferred language etc when she installs the Download Manager. Thus an installer has to be created which would allow a pleasant user experience for this install. This parallel development is managed by the Installer Engineering Manager.
Any infrastructural support is managed by the Program Manager who ensures the project does not starve of them. If any new 3rd party equipment/software is required, the Program Manager checks with Legal and also runs the software tool to ensure legal compliance of the code.
The final deployment and customer support teams are managed by the Program Manager who has to ensure that their systems and people are geared to support the component for the end consumers once it is released to market or shipped. Ship readiness approvals are required from all support groups before product ship.
The Program Manager actually manages the overall schedule while not diving deep into any other manager's low-level schedule.
Testing the deliverables
There are many tests that are run on a component developed in a product development environment since recall costs and image loss have to be minimised if not avoided by the product company.
All these tests are managed overall by the Program Manager but may actually be executed by teams led by Quality Engineering managers or external vendors. Some of the tests conducted are functional test, integration test, API test, smoke test, regression test, performance or load test and customer acceptance test. The Quality Engineering Manager is entrusted with creating the low-level schedules and plans for these tests. These plans are communicated to the various stakeholders through the Program Manager. The Program Manager steps in to ensure that the expectations of customer teams of product quality can be satisfied within the resource (time and cost) constraints of the test team. He also ensures that the Quality Engineering team is on track and making the necessary PLC milestones to ensure compliance to the suggested Ship date.
For linguistic testing of the component in languages for which expertise is not available in the associated groups, an external vendor might be employed. This is usually managed through the Localisation Program Manager.
There is another type of field-testing which can be planned directly with consumers outside the company i.e. Prerelease or Beta testers. This is usually arranged with the Program Manager delegating this to a Pre-release Program Manager who devises that sub-program in which the component is provided to a limited set of consumers and innovative means are applied to gain feedback on new features as well as bugs from this set.
Customer acceptance and hand-off to Sales and Support
Customer and team acceptance is actually sought at every milestone in the Product Lifecycle (PLC) since all are invited including the Executive team. Thus quality is certified at each milestone. The final acceptance is known Gold Master where the final main deliverable and all its related deliverables are packaged and supplied to the consumer. The component is made available in the deployment/sales environment and the PLC for that particular release of the component is over. The next component release would include inputs provided during this entire PLC and before the next one begins.
The Program Manager gives input on performance appraisal on all team members who had worked with him to their respective managers on request.
All along, the other projects being undertaken by the Program Manager are might be running in a different phase of their own PLC.
Challenges facing a Program Manager in a Product Environment vis-à-vis Services Environment in India
Summary of Survey Results
The author conducted interviews with various functional managers in an assortment of software engineering companies based in India. Following is the summary of findings in descending order of the frequency of report.
List of Top challenges faced by a Program Manager
- Responsibility without commensurate authority
- Understanding of the level of technical depth required by the role
- Missing role clarity and hazy demarcation of responsibility
- Skewed focus of senior management to development versus other areas of product development
- Gaining a realistic understanding of product customers when located in a geography distant from them
- Resistance to process-orientation in product development companies
- Managing expectation when stakeholders span multiple time zones and cultures
Distribution Of Respondents To The Study
I. Responsibility without commensurate authority
In most cases, the Program Manager role is defined as that of an Individual Contributor. Thus while the role places overall responsibility for successful delivery of a project and its deliverables, no direct authority in terms of the 3M i.e. men, money or materials is entrusted to this role. Thus the enforcement of a schedule and budget constraint becomes a degree more difficult when working with other teams in the project. In a few cases the Program Manager does have a few reports but they are mostly junior Program Managers or Business Analysts.
II. Understanding of the level of technical depth required by the role
It is not apparently clear as to the level of technical depth required for the Program Management role. It has been observed that Program Managers in India are at the top end of being technically experienced for many engineering issues.
While recruiting Program Managers in India some companies look for software engineering practitioners and once recruited expect them to work as non-obtrusively with engineering managers as their US counterparts.
In US, there are many successful Program Managers who manage large projects without knowing much about the technology that teams work on.
III. Missing role clarity and hazy demarcation of responsibility
Other managers might feel that the Program Manager is overstepping his boundary into their domain.
The development manager / testing manager of a team which is involved in the project might feel that the Program Manager does not need to talk directly to his team for daily task status or provide technical inputs.
Other individual contributors might see the Program Manager role as equivalent to theirs.
IV. Skewed focus of senior management to development versus other areas of product development
In some organisations, Program Manager reports into Engineering. In others it reports into senior Program Management roles finally ending in general management. In organisations where the role reports into Engineering, the Program Manager might not be taking care of any engineering activities such as functional specifications, estimation, design, coding, reviews, testing etc. Thus a career path into senior management is anything from ambiguous to absent.
Thus the Program Manager is unsure of avenue for career growth i.e. choosing between being delivering the best values as a Program Manager or doing what their manager from Engineering is doing. The situation seems to be only slightly better in companies which did not have Program Manager reporting into Engineering. In these cases the Program Manager working at the India centre was still expected direct development activities such as designing and coding rather than provide an equal focus on understanding other functions required in product development.
V. Gaining a realistic understanding of product customers when located in a geography distant from them
Access to the end consumers who pay for your products might be missing and so evaluating features they would like and issues/bugs they face with existing versions of your product might not be feasible directly.
The technology against which you develop might not be available in the geographical location where you work. Thus live testing is sometimes not possible.
VI. Resistance to process-orientation in product development companies
The processes are loosely defined and open to wide interpretation. To manage teams which are not bound by a common process, when spread over geographies and still be able to deliver as if there was a full process model is the challenge in product companies. And it is the prime responsibility of the Program Manager to ensure this with minimum of hiccups interspersed with timely and priority driven escalations to senior management.
Indian engineering teams are more tuned to greater process orientation having largely come from a services background but implementing processes with a buy-in from overseas counterparts is a major challenge.
VII. Managing expectation when stakeholders span multiple time zones and cultures
Working between various time zones including US time zones, Europe, Asia Pacific, Japan and India, the Program Manager has to work at integrating projects with multiple teams. Unlike project companies, the customers do not change over a long period of time and so this challenge does not get resolved even in the long term.
Generally teams in US are resistant to working any hours outside of 8 AM - 5:30 AM local time. The meetings on product decisions are also often held during the daytime in that time zone. Since the Program Manager is the central pivot for coordinating product development, it requires stretching working hours for teams in various locations.
The limited face-to-face interaction gives the Program Manager relatively lesser leeway in negotiating on product decisions with cross-campus teams.
Program Management is a customer-driven role and when nurtured can be turned into a real asset for senior management. The challenges presented point more to expectations mismatch and it becomes the joint onus of the Program Manager and the senior management to help bridge it to provide the maximum organisational benefits.
The author would like to express his sincere appreciation of the people at the Project Management Institute (PMI®) who have given him the opportunity to present at the PMI Global Congress 2006 – Asia-Pacific. He would like to thank all the respondents who found time from their busy schedules to gain legal clearance from their organisations and to give their inputs under offer of secrecy. He would also like to thank his organisation, Adobe Systems Inc. which allowed him to pursue this study. Finally the author would like to thank the Managing Director, his manager, the human resources manager and his ex-colleagues who helped him open the doors to the respondents.
Allen, S. (2005) Retrieved from http://en.thinkexist.com/quotation/a-project-is-complete-when-it-starts-working-for/348431.html
Project Management Institute (2004) A Guide to the Project Management Body of Knowledge Third Edition(PMBOK® Guide) Newtown Square, PA, USA: Project Management Institute
Bennett, P. D., (1998) Marketing International Student Edition. McGraw Hill
Subramanyam, A, Sinha A. PMP (2005), Best Practises in Program Management, Journal of Project Management Congress 2005, PMI North India Chapter
© 2005, Abhay Sarup PMP, Adobe Systems Inc
Originally published as a part of 2006 PMI Global Congress Proceedings – Bangkok, Thailand