Introduction
Many of us have had the experience of being assigned to lead an important program, one critical to the future success of our business. As you begin to look around for the resources and tools needed to complete the project, however, the excitement of being assigned such a program subsides. You find that no procedures exist for the program you've been assigned, and there are no benchmarks, models, or lessons learned to work from. Most of your project team members are also committed to other areas of the organization, and you have no real clue how much time they dedicate to the program. Of course, you're expected to accomplish your task in an aggressive time frame because, after all, this is critical to the success of the business.
Sound familiar?
It certainly does to the General Motors Service Parts Operations (SPO) division. Like other automotive parts suppliers, SPO launches numerous product line enhancements throughout the model year, and faces the challenge of bringing these products to market in a manner that best utilizes the scarce resources the organization has available. When you add an aggressive growth strategy to this equation, careful control of resource utilization becomes even more essential to successful business execution.
SPO has embarked on an aggressive “all makes—all models” strategy that dramatically expands its presence in the automotive parts aftermarket. This strategy, when implemented, will provide numerous opportunities for SPO to increase market share in the service parts arena. However, SPO faces some challenges in implementing this vision. Its product development tasks are done sequentially, making the development cycle too long for the vision SPO has developed. Another challenge is dramatically expanding the business without adding any headcount to the pool of talent that is currently maintaining SPO‘s already substantial aftermarket business. The challenge for SPO becomes how to execute this new strategy, and how to focus SPO‘s valuable resources to best take advantage of the new opportunities created from this strategy.
Fortunately, program managers can look to program management principles and tools to attack these challenges. The principles of program management are grounded in sound business practices, and this is demonstrated when methodologies prescribed by PMI‘s A Guide to the Project Management Body of Knowledge (PMBOK® Guide) are applied to solve a business problem. SPO elected to take just such an approach in defining a model for expanding its business base. With the assistance of the pci group, SPO developed a strategy that was realized through the formation of an Initiative Implementation Team that established a Program Management Office (PMO). The PMO facilitated the implementation of processes, procedures, organizational changes, and training designed to provide product launches with discipline and structure, resulting in effective resource management throughout the organization.
Background
To understand the assessment approach taken by the Implementation Team, it helps to visualize SPO as a production facility, and the PMO as the planning group within that facility. In a production environment, the core challenge faced by the planners is how to maximize production throughput through a facility with a finite capacity. Before the planners can maximize that capacity, however, they must understand the flow of work through the workstations. They must also understand the demand on those workstations, with workstations being analogous to functional departments in this example. They must also understand the priorities of the business, and sequence work through the facility based on that priority. Only in this way can throughput be maximized through the SPO Procurement “Factory.”
With the factory model in mind, the PMO assessed the product development process. The assessment resulted in three high-level findings that impacted the eventual solution:
1. No visibility into resource requirements limits ability to define the process. Since human resources are the capacity constraint on the development process, defining this precisely became essential for accurate modeling. This was the single-most critical finding because it impacts two different parts of the process model. The PMO had to quantify the resource standards for the process templates, so resources could be aggregated across all active project schedules to determine the total resource burden on the SPO Factory. In addition, the accurate capture of resource requirements allows the PMO to aggregate long-range planning schedules to forecast the headcount necessary to execute programs in the future.
2. No method of prioritizing product launch programs. Although SPO product launches vary greatly in their financial impact on the organization, there was no system in place to establish any launch priorities. The best way to control the development process is to control when programs are released into the SPO Factory. Without this priority, the programs get released to the Factory without any coordination or forward planning. The result is similar to a Factory without controls, where work queues up behind workstations, and the queues gradually becoming longer as the programs work their way through the Factory.
Since there are no prioritization rules, workstation operators are forced to decide which programs are more important. Since these operators are driven more by timelines than by priority, they do what most sane people would do—they complete the work in the order it arrived in their inbox. This solves the problem of getting the program off their desk, but doesn't address the corporate objective of applying scarce resources to only the most profitable programs. Instead, the lack of prioritization ensures that all programs move through the process at roughly the same rate and in the same sequence, ensuring launches are completed haphazardly, and the programs with the greatest financial impact on the organization are not necessarily the ones completed first.
3. There was little understanding within SPO of the product development process. The ability to effectively forecast the behavior of any process is a direct result of the consistency and repeatability of that process. The Implementation Team found that the product development process was poorly defined and poorly understood. In addition, the organizational culture was such that launch team members only participated in one launch team before moving on to another position within SPO. As a result, SPO product launches did not follow a common sequence of steps, jumping around from task to task as the launch team discovered the requirements. Without a consistent, well-understood process, and the organizational discipline necessary to follow the process, it was difficult for SPO to accurately forecast the resources required to complete its product launches.
As a result of these findings, the Implementation Team proposed several program management objectives to SPO:
• Implement project management processes that result in improved product launches and SPO process knowledge
• Design, construct, and implement planning templates for scheduling and tracking that provide comprehensive program-level/enterprise-level status awareness and facilitate long-term planning capability
• Integrate project management tools (including software applications) that provide centralized project management data collection, standardized status reporting, and improved resource allocation capabilities
• Create a review committee that resolves program conflicts through cross-functional communication.
These findings and proposed objectives were presented to the SPO leadership, and approval was given to design a solution. As with any solution design, one of the key challenges faced is determining the appropriate scope of activities. In this particular case, this process was complicated by SPO‘s relative lack of understanding of its product development process, and also by its wish to receive information useful in its process management as soon as it became available.
Scope Definition
To address these concerns, the PMO conducted “proof of concept” on a product launch that was just beginning. The product manager had previously projected a launch date of June 2000, based only on his prior experience. The PMO was asked to use project management techniques to determine whether the program would be completed by June 2000, and to estimate the resources required to complete the launch.
To define these issues, the PMO met with the launch team to identify the steps taken in each product launch, the dependencies between tasks, and the average duration of each step. Once the project template was defined in project management software, the PMO again approached the project team to define the departments and job descriptions involved in product launches, then assigning the requirements by job description by task.
Based on the project template provided by the product team, the PMO determined that the product launch would be substantially later than previously forecasted. The PMO also learned that a few Marketing employees would be tasked beyond their capability at critical points of the development process. While SPO realized this was only “roughly right” and was no substitute for systematic data collection and analysis, it illustrated the value of the project management techniques, and also emphasized the need for disciplined program management principles to help solve SPO‘s business objectives.
Having effectively demonstrated the analytical background of the program management solution, the next step for the implementation team was to decide the scope of the solution. Looking at scope from a project-level perspective, one of the challenges to the implementation team was in defining the appropriate beginning and ending milestone. The product development process has a number of activities that are not controlled by the product team. It was decided that the start milestone tracked for the development process would be the product team kickoff meeting, and the end milestone when the product (or group of products) was available for order.
SPO also had to decide how much of their business to bring underneath the PMO umbrella. Within SPO, there were two major revenue generators. The Aftermarket group provides repair parts to the market, while the Accessories group develops products that are added to newly purchased vehicles at the dealership. Aftermarket launches tended to be higher-revenue generators on a per-program basis, simply because there were multiple parts included in a single launch. In some cases, these part groups numbered in the thousands. Therefore, SPO immediately saw the value of tracking launches of numerous parts simultaneously under a single project schedule. On the other hand, Accessories launches tended to be of much longer duration than Aftermarket launches, and were tracked as a single product per project schedule. The Accessories group was becoming overwhelmed by the administrative requirements of tracking several hundred schedules simultaneously, and could benefit from the project management discipline that project schedules would provide. Ultimately, the implementation team decided to implement the Aftermarket group first, based on the revenue potential of the product lines. The PMO included the Accessories programs after much of the Aftermarket group programs were captured.
Process Development and Design
To address the findings of the discovery phase, and to achieve the objectives outlined above, several changes to SPO‘s business processes had to be made:
1. Define product development process through use of project schedules—The first order of business was to gain control over the product development process. This was accomplished by refining the process steps documented in the proof of concept exercise described above. A number of different product teams were surveyed to ensure that the development process could be accurately represented using a single project template. Those surveys also served to more accurately define the task durations, dependencies, and resource commitments.
2. Develop resource profile definition—SPO leadership felt that understanding its human resource commitment to product launches was a critical piece of information component. Assuming each of the project schedules accurately reflected the resources needed for completion, the next step was to summarize the total impact of all planned projects on the organization's resources. This paid dividends to SPO leadership in two ways. On the tactical level, this information gave SPO the ability to assign resources to only the most important projects. On a more strategic level, SPO could use the resource data to analyze its head-count needs for future years, based on its long-range planning schedules.
3. Develop prioritization methodology—Given the limited resources available for completing product launches, it was critical to commit those resources to those projects deemed critical by SPO. The PMO identified criteria to rank order the product launches, then present that ranking to SPO for approval.
4. Implement executive-level decision-making authority—All the improvements described above will not be fully implemented unless executive management does not get behind the PMO. To ensure this, the SPO Procurement Planning Board (PPB) was established. Consisting of the SPO General Manager's direct operational reports, the PPB was chartered to provide cross-functional guidance to the PMO and the product teams, to resolve functional tradeoffs, and to establish priorities across all product teams and launches.
Proof of Concept/Value Delivery
SPO approved the PMO process design, and added one stipulation to the implementation design that provided a great challenge for the PMO—provide useful planning data while the implementation is taking place. This request added one more layer of complexity to the planning process, and is a scenario encountered more frequently. Organizations are less likely to wait patiently for several months for a meticulous process design, delivered fully functional. The more likely scenario is that organizations are willing to trade a complete solution implementation for a time-phased deliverables that provide immediate payback. In this case, the payback for SPO came in the form of resource information and project plans focused on product launch prioritization decisions.
Typically, the team address this by scheduling interim deliverables, based on the needs of the PMO, and this was no exception. Some tasks required to establish the PMO were reshuffled in order to ensure process outputs were available at critical points in the implementation plan. The team also had to formally consider expectation management as part of their scope. It was known that, once the first outputs were released from the PMO, the demand for the information would be intense. The team had to make sure that outputs were supported by a robust process upon their release to SPO. Additionally, a rollout plan was established so the process stakeholders were assured that other stakeholder requirements would indeed be forthcoming, within the scope of the project.
In fact, scope maintenance became a major challenge for the implementation team. SPO stakeholders pushed the PMO for more detailed information to support its piece of the total product development process. These requests often strayed far from the PMO‘s charter. Generally speaking, the PMO‘s defined role was as scorekeeper for the PPB, providing information and analysis that chiefly benefits the strategic level of the organization. However, as the PMO analysis and products hit the street, requests for additional information came from all corners of the organization. On occasion, the team even had to remind SPO leadership of the PMO charter, when it came to their requests for additional information.
The implementation team crafted a project plan that considered the dual priorities of process design and output delivery, and staggered the deployment by addressing smaller groups of projects. It was decided to subdivide all SPO product launches into groups, and attack them in priority order. The SPO leadership decided that active domestic aftermarket projects were the highest priority product launch group. For this first group of projects, the PMO implemented only a few core processes, with the objective as always being to provide the PPB with essential business information. In this case, this meant prototyping the schedule/template development and status collection processes to generate the resource profile for the domestic aftermarket program. The process guidelines and report parameters were defined by the implementation team, then exercised by developing the aftermarket template, generating aftermarket schedules based on the template, then calculating the resources required to complete all of the projects. The process and products were reviewed with the SPO stakeholders, and validated through their input. The implementation team finalized the process and report design, based on the input of the stakeholders.
This staggered approach was followed throughout the implementation cycle. The next group of projects used the processes validated previously, and added the status reporting requirement. The integration between projects, reports, and process development allowed the PMO to take an iterative approach, adopting the Shewhart “Plan-Do-Check-Act” standard for process development. This allowed the PMO to validate and fully implement some processes, while still developing others.
Post Implementation
The impact on SPO has been significant and measurable. For the first time, product launch progress is tracked against objective criteria, with progress reported to SPO on a routine basis. With this information, the PPB is able to reallocate resources as required. SPO has also used the resource information to prioritize aftermarket programs and accessories programs. These efforts have allowed SPO to better focus its resources on only the most critical launches, directly impacting its bottom line as a result.