Implementation of a project office in a VLSI design center

Introduction

Motorola Semiconductor Israel (MSIL) is the largest design center of the Semiconductor Products Sector of Motorola. MSIL is engaged in the design and development of a variety of VLSI (very large-scale integration) products, including microprocessors, digital signal processors and micro-controllers as well as software and hardware systems. MSIL employs several hundreds employees—most of them electrical and software engineers. Designing a VLSI product is most likely one of the most complex intellectual challenges; A typical MSIL design project combines simultaneous work by dozens of engineers, lasts more than a year and comprises of more than a thousand tasks. Roughly, five such projects are managed concurrently in MSIL, creating a real management challenge.

To face that challenge, a Project Management Office (PMO) was formed in MSIL in late 1998. The launch of the PMO into MSIL, dynamic environment, unfamiliar with structured project management processes and procedures, was problematic. A gradual but persistent implementation enabled it to overcome the difficulties and led to successful implementation in a relatively short period. Three major components, which were involved in the establishment of the PMO, will be described in this paper: introducing the Project Control Analyst (PCA) role, definition and institutionalization of project management processes, and implementation of an integrated software solution.

Introducing the Project Control Analyst (PCA)

MSIL organization structure includes several design departments, distinguished by their industry market. Each design department develops one or more products. Additional functional departments (e.g., Computer Aided Design—CAD) support the design activity. The design department manager designates a technical project manager for each new project (technical project managers will hereafter be cited within the text as project managers). Very complex and large-scale project may require the department manager himself acting as a project manager. Several team leaders, whose number is determined by the project complexity and the number of engineers involved in it, manage the design engineers and report to the project manager.

The PMO has been evolved as a team in the Time to Money department—a functional department aimed at reducing MSIL's development cycle time. Since project management concept was practically new for MSIL, it was unrealistic to convince the management to sponsor a whole new office to facilitate the project management initiative. Therefore, the best way to urge MSIL's management to embrace project management was the “proof of concept” approach—start with one project, show results and move on to the next one. The idea was to introduce dedicated individuals to facilitate project management in MSIL's departments—a task that had not been previously performed with success, or even at all, by the project managers. Consequently, the PMO was initiated with two part-time PCA's supporting two design projects, and has gradually extended, after demonstrating true benefits, to its current size. The PMO currently includes six PCA's who support all MSIL's projects.

The Pioneering PCA

The initial PCA role included in essence the following features: translate the engineers’ thoughts into visible schedules, track and update those schedules regularly, and become professional with the available project management tools. The PCA role required the following characteristics: strong minded person to enforce new project management practices; good analytical grip and fast learning capability to comprehend the VLSI design processes, independence and good communication skills. Industrial Engineering students appeared to be most appropriate candidates for the job. Candidates having the required skills, combined with basic project management knowledge, could practically demonstrate impressive results in relatively short time.

The first recruited PCA's began to build and maintain schedules for two design projects that have just started. After a short training period they started meeting the project managers and team leaders to create schedules that reflected the real work handled by the engineers. Within two months two detailed project schedules were built. Then, the PCA's could start with a follow-up process, in which they met with the team leaders to update the progress of activities and revise the plans if needed.

Design Environment—The PCA Challenge

The new PCA's lacked a major skill, which was essential for effective project planning in the design environment—an overall comprehension of the design-flow. The design-flow is a multistage interdisciplinary process, which requires both electrical engineering knowledge and familiarity with design tools to fully understand it. Project managers held most of the design-flow knowledge, but their knowledge was generally related to design stages in which they had been actively involved in previous projects. Moreover, the project managers often lacked a process-oriented insight and considered their work as a creative work, which could not be described or planned structurally. The PCA's, on the other hand, had the process-oriented perspective stemmed in their industrial engineering background, but only fundamental knowledge in electrical engineering. Thus, the PCA's had to learn all design disciplines to enable a logic definition of the design-flow. An intensive formal and informal training was required to bridge that gap. Hence, the PCA's started to gain knowledge informally undergoing the initial planning sessions with the project managers and team leaders. The cumulative knowledge has gradually enabled them to capture the overall perspective of the design-flow and identify missing links.

Being “green” the PCA's experienced another challenge. It was objectively tough for the young and inexperienced PCA's to confront senior managers and lead an organizational culture change, because of both technical knowledge gap and seniority difference.

Nevertheless, within less than a year MSIL management recognized the major contribution of the new PCA's and agreed that each design department would sponsor a full-time PCA to support its projects. Consequently, three experienced full-time industrial engineers were hired, one of them to manage the PMO. Furthermore, the part-time students who have just graduated were recruited as full time PCA's. This boosted the maturation of the PMO, which could now extend its support to cover all MSIL design projects. The more experienced PCA's have started to act as key players in the project teams. With an overall understanding of the design-flow and process oriented perspective they have been actively involved in decision-making (e.g., activity prioritization, shifting resources between activities). Leveraging in addition their good communication skills, they have become real helpers to the project managers. Parallel to that progress the PMO has led the definition and implementation of the project management methodology as described below.

Project Management Methodology Development

The development and implementation of project management process and procedures have been formed gradually coupled with the maturation of the PCA role. To describe the implementation of the project management methodology we will first discuss the planning phase, in which a detailed plan is defined, and later explain the tracking phase, which is an ongoing process corresponding to the execution phase of the project.

Initial Planning Process

The full benefit of project management could not be demonstrated in the beginning of the PMO due to the PCA's deficiency of design-flow knowledge. Therefore, we started with a follow-up project control process, in which plans were primarily used to define delivery date commitments without definition of individual work plans for all employees. Using project management software the PCA and the project managers defined the WBS and the activity network, assigned resources to activities and estimated the activity durations. Although this planning process was not perfect, the recognition of project control in MSIL started to grow advocates. Project managers, who considered their dynamic environment impossible to describe and track in structured manner, have slowly changed their attitude and started to enjoy the fruits of planning—the ability to commit to real delivery dates, based on real analysis rather than “gut feeling.” The planning process has gradually gained advocacy from managers and it made the PMO institutionalization easier. The plans significantly improved the technical managers’ proactive attitude to resolve upcoming risks and issues. Nevertheless the initial planning process suffered two major drawbacks:

• There was no unified terminology in the plan often resulting in confusion regarding inter-team deliverables.

• The definition of the design process was done mostly top-down, i.e., the WBS definition (links, durations, etc.) reflected the project manager's estimation without comments or acceptance of the team leaders and the engineers involved in the project (bottom-up feedback). This created a conflict between the project managers and the team leaders. The latter felt frustrated by the workflow that was dictated to them rather than consulted with them. In addition, engineers did not really feel committed to due dates, that they were not involved in their determination.

Improving Our Planning Process

With our growing experience and the maturing MSIL's organizational culture, we have introduced an enhanced planning process in the next large-scale project. This process is currently being standardized in other projects. The current process is described below (see Exhibit 1).

After the core team of the project is established and the project scope is defined we start with a series of meetings with the project manager and the team leaders. During these meetings we define detailed design-flow for each high-level activity. We identified two major categories to classify the design high-level activities: block-level activities (blocks are subunits of the chip, separately designed and integrated later), and chip-level activities (activities that are performed globally, e.g., integration, architecture definition). This categorization enables us to define generic flow template to be used repeatedly at the block level. We put special emphasis on crisp definition of the activities. In order to do that we use two fields in the Gantt charts besides the activity name: (a) Detailed description—free text detailing what the activity includes; (b) Purpose—what the activity outputs will be used for. The output of these meetings is a generic design-flow template, which is essentially a standard activity network.

The team leaders, who are responsible of one or more blocks, use the template to define their teams’ work plans. Consulting their teams, team leaders fill out the required resource effort for each activity and assign specific resource to the near future activities. The different work plans will later be integrated into one project activity network.

Exhibit 1.The Planning and Tracking Process

The Planning and Tracking Process

A plan review process follows—The project manager and the PCA meet each team leader separately and review their plans. The review includes validation of the effort estimates and resolution of resources conflicts. The most important benefit of this review is to reveal ignored design issues and to light up coordination problems. The review enables us to solve problems proactively and thus save a lot of rework. After each design review we hold a short design presentation. In each such presentation the team leader explains to his team the overall design-flow and presents their expected near future activities (around two months ahead). After receiving the team's comments and making the required changes, the teams are asked to commit to their first delivery date. This procedure actually reflects micromanagement concept, where each individual in the project is expected to define his tasks and commit to them. Later, the PCA integrates the team plans into one project plan. Only at this point we can commit for the project deliveries due dates.

The Tracking Process

The tracking process started as a follow-up process in which the PCA met the team leaders on a weekly basis to update the plan. As our project management methodology has evolved the tracking process has been developed into two feedback-loop procedures. The external loop occurs monthly. It is actually a reiteration of the last planning stages. It includes for each block: specific resource allocation for the next two months, design review and presentation. The internal feedback loop occurs weekly and is based on the engineers’ individual updates. Each engineer updates his weekly progress through timesheet and thus affects the overall status of the plan and progress reports are generated to show the weekly progress. In order to launch the project fast it is vital to start this update procedure as soon as the engineers start to work on the project, although the integrated project plan is usually not finalized at this point. The weekly update procedure, which actually directs the engineers’ daily work, is feasible thanks to the project management software we have implemented as described below.

Project Management Tool Implementation

Project management software is not a straightforward tool. Considerable amount of time and effort are generally required to learn the tools and operate them effectively. Even then, when implementing these tools extensively across organization, there is good chance for technical and nontechnical issues to arise. An organization like MSIL that seeks to implement an integrative project management solution must have a solid infrastructure to operate such system and provide for training, regular tool support and troubleshooting. To do that, a strong tool expertise and knowledge base had to be created in MSIL, and that was naturally one of the PMO's roles.

Tool Expertise Within the PMO

Our approach was to train thoroughly only several users, namely the PCA's, who would become the tool experts. They would be the only users to actually manipulate the projects’ data. The project managers and team leaders would be lighter users who would require only basic tool knowledge that could be taught by the PCA's. The PCA's underwent self-training, formal training and particularly continuous on the job experience that made them tool experts. This has enabled them to train all required users, create a collection of useful reports, document the tool procedures and maintain a repository of known bugs, issues and helpful tips and tricks. Project managers and team leaders were trained by the PCA's. They acquired basic skills that enabled them to open existing schedules, generate predefined reports and analyze them. They were not expected to be able to create schedules by themselves.

The Data Model

In order to facilitate our project management process we needed project management software that would enable the implementation of a micromanagement concept, where each employee statuses his assigned tasks weekly. This concept enables an accurate real-time status of the project. We have utilized a client-server solution from Advanced Management Solution® that was available at Motorola at that time.

Exhibit 2. The PM Tool Data Model

The PM Tool Data Model

The data model includes two major modules (see Exhibit 2)—Project Management module and Resource Management module. The PM module is used by the PCA and the project manager to derive the project plan, review and analyze the plan status and revise it when needed. All project plans reside on a shared server, allowing all stakeholders to view the current plans. The RM tool is a central repository used to communicate the work assignments from the PM module to the employees, collect the actual hours booked by the employees and populate them back to the PM module. The employees book their actual hours through a simple web-based timecard linked to the RM repository. They are also expected to update the estimated effort to complete their tasks (ETC). These inputs, after being reviewed by the team leaders, are retrieved into the PM module and automatically update the schedule to reflect the changes.

We have implemented this data model in two phases. The first phase included only the PM module. The project status was manually updated by the PCA based on the team leaders’ inputs with the percent complete approach. During this phase, we practiced definition of detailed plans with basic resource assignments. Only the project managers and the team leaders were exposed to the plans and the tool, but we already created the infrastructure for weekly updating cycle.

In the second phase we have implemented the RM module and the web timecards. All engineers were trained to use the time-cards. We have virtually changed our concept from tracking percent complete progress to monitor technical progress based on actual effort spent. Moreover, the forecasted completion dates were based on the real work contributors’ inputs. Effort tracking the shift to two databases. The shift to this micromanagement approach essentially tied all engineers to the project plan. Each employee knew what he was expected to do, and understood that his inputs affected the whole plan.

Another important enhancement that we implemented in the second was real-time reports. Utilizing an ODBC driver supplied to us with the software, we have developed Microsoft Excel® reports that were dynamically linked to the live RM database. This enabled any manager with basic familiarity with Microsoft excel® (which was much more common than managers familiar with the reporting features of the PM tool) to view instantly real-time analyses of the project data without dependency on PCA's expertise. We have created generic reports that could be easily customized to any project manager's preference.

Conclusion

The PMO has been evolved in MSIL over the past two years with the introduction of three important foundations:

• Professional Project Control Analysts who lead the organizational culture change

• Structured project management process and procedures to unable efficient and uniform implementation

• Integrated project management software, which is essential platform to support the process.

MSIL has benefited greatly from the implementation of the Project Control and Analysis methodology. Managers have quickly appreciated visibility into accurate real-time status of projects. The design community, which initially looked upon project management as another bureaucratic corporate initiative, has experienced the rewards of structured planning process. They appreciate the benefits of a disciplined process that results in realistic schedules and reduces rework. The well-defined plans have dramatically improved the coordination between the different organizational functions in MSIL and reduced our design cycle time. The process and tools described in this paper are being adopted by other organizations within Motorola.

Lessons Learned

PMO implementation in a VLSI environment is a tough yet achievable challenge. Major points to be viewed and considered by organizations seeking to successfully establish a PMO in an organizational environment with similar characteristics are:

• Gradual implementation process is a wise approach. Even if support from executive management exists, organizational culture change cannot happen instantly. It takes time to both the process drivers and the organization to absorb the change.

• Senior management expects fast results. It should be understood that realistic schedules are the bottom line of a long and disciplined planning process, which sequentially defines the “WHAT,” “WHO,” and “HOW” of the project. Driving such process requires profound understanding of the design process, leadership characters and cooperation of all parties involved in the project.

• One major obstacle to the PMO establishment is the difficulty to justify it quantitatively. Bear in mind that even one or two project managers that have undergone structured project management process appreciate its necessity and can be leveraged to convince others.

• Coordination is an important outcome to the project management process and therefore it is especially beneficial in complex and large-scale projects.

• We have recognized that an effective planning process is very long and it usually overlaps real project work already being executed. Therefore a “fast start” tracking procedure should be implemented parallel to the planning phase to monitor the project work already in progress and prioritize it promptly.

• Remember that a disciplined project management process does not contradict the creativity of the design work. The creativity is exhibited in the “WHAT’ portion—the scope of the project, while the “HOW” portion is tackled structurally.

• A structured PMO implementation may unveil some organizational problems, which are not directly related to the project management process. These issues should be resolved separately.

• A major factor to be considered when evaluating Project management software should be its maturity. An immature tool exhausts a considerable overhead and might slow down the implementation pace.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.