Several years ago, our company acquired another company in our field that had itself previously acquired two additional companies, plus had started an advanced research and development facility on its own. When the euphoria of acquisition wore off, we found ourselves as a collage of at least six identifiably different companies/cultures. As our company had grown very rapidly even before the acquisition, we had no formal systems for product development that anyone would consider “Best Practice” to impose on the new, aggregate company, and we came to find out that the balance of the company was in the same predicament. We had become an international enterprise, with worldwide design centers, manufacturing facilities, and business centers. Unfortunately, few people knew their counterparts at other sites and most had not a clue how to effect even such rudimentary results as starting a production lot at another location.
In 1992, a detailed poll was taken across the company to identify what needed to be fixed to improve our performance. Over 200 different items were called out, and they were grouped by attributes to determine if there were a few root causes. It was found that if we could achieve a best practice project management culture, about half of our issues, companywide, would be resolved. That led to the commission of a small, representative team chartered to drive the culture of the company towards routinely using best practice project management practices. The sponsor of the team was the company vice president of engineering.
Our company, Harris Semiconductor, is one element, or “Sector,” of the Harris Corporation. Harris Semiconductor maintains a product portfolio of over 25,000 part types and brings to market several hundred new products every year. Successful new product development is essential for our growth as a company, and the ability to effectively manage projects was seen as key to effective new product development.
Our team immediately approached the Quality and New Products Group (QNP) at “Corporate” and asked for help in changing (developing!) project management culture. They enthusiastically volunteered, joined our team, and all that follows in this article is the result of the collaboration between the sector and corporate members.
Out of the Gate
The members of the team from our sector brought to the team broad knowledge of the business and the organization, procedures, “personality,” and idiosyncrasies of the sector. The QNP team members brought to the team extensive experience in project management best practices, as applied particularly to systems and software development in many other portions of the company. Together we crafted what the approach would be for instilling best practices locally. We concluded that the answer was not a formal, extensive course, nor was it simplistic brochures, textbook exposition, management training for trickle-down effect, or a series of enlightening articles published in our company newspaper. Rather, we concluded that the most effective technique would be to work directly with teams themselves, coaching and otherwise adding best practices along the way. As we did not have infinite resources to deploy in the endeavor, we divided our approach into several phases. We concluded that the two first and most important areas of concern were the environment for projects and project start-up. If either of these were inadequate, then best practices for the execution, monitoring and closure of projects would at best become best practices in firefighting or salvage. Our approach, then, took on the following form:
Figure 1. Structure of a Project Start-Up
Phase I:
- Work the project environment.
- Install project start-up best practices.
Phase II:
- Install project execution best practices.
- Develop multiproject management concepts.
Phase III:
- Install multiproject management best practices.
- Establish project management financial best practices.
The financial portions of the best practices were held for Phase III because a good information system for linking the financial and schedule performance of projects is only now being planned and will be installed at a later date, independent of this activity. The mechanism used to work the project's environment and to install individual project start-up best practices came to be known as “Project:Go!”
Introducing … Project:Go!
The Project:Go! experience begins when a decision is made to sponsor a project activity to achieve some goal for the company. It could be a product or technology development, a system improvement project, the writing of a proposal, the erection of a new building or factory, the start-up of a large government contract, the development of a standard practice, or any other project. Project:Go! has been applied to them all. A facilitator is assigned and begins by working with the project leader and the project sponsor (typically a director, vice president, or higher in the company). The facilitator explains the process of start-up (Figure 1) and the nature of the best practice project management environment. When the team is identified and assembled, the facilitator meets with the team and its leader, facilitating the team through the start-up process.
Starting the Start-Up
The major “event” of Project:Go! is the project start-up workshop. For the workshop, the team sequesters itself for as long as it takes, typically three to five days, to get its project defined, planned and started-up. The Project:Go! agenda:
- Overview of the start-up process
- Define project scope statement
- Define project strategies
- Define roles and responsibilities
- Develop a WBS (deliverables)
- Complete the WBS (tasks for each deliverable)
- Network tasks (identify task dependencies)
- Team norms
- Identify key risks.
The first significant activity in the start-up is the development of a scope statement for the project. A strawman scope statement is generally developed with the project leader and the sponsor before the workshop. This makes finalization of the scope statement occur much more efficiently.
A scope statement is a simple, concise description of the expected project results. The features of a scope statement are:
- It is from two to five sentences in length.
- It incorporates key factors to measure success.
- It is not a specification.
- It includes specific dates, identified target markets, and specifies technical/marketing constraints.
Once written and agreed to by the team, the scope statement is reviewed with the team's sponsor, functional management, and possibly with customers.
Scope statement discussions usually take between one and one-and-a-half hours. Even when you start with a good “draft” scope statement it will take no less than one hour.
Our record for “thoroughness” is held by a team that needed two days of discussion to develop its scope (imagine the project if the discussion hadn't been held!).
The scope content captures the meaning of the statement “this project is completed successfully when …”. The scope statement always contains at least one day/date, but it is understood that any dates in the scope are neither binding nor committed until a complete scheduling activity has been accomplished. Once the scope statement has been completed the project sponsor arrives, reviews the scope with the team, and either agrees that the scope will deliver exactly what the sponsor wants or works with the team in real time to bring the scope statement to that state.
The scope statement is ideally augmented with additional text that we call the Statement of Work. The SOW defines further the project deliverables, objectives and constraints. Unlike the two to five-sentence scope statement, the SOW may be two to five pages, within “arm's reach,” and within the reading tolerance of anyone on the project. The SOW is a narrative description of the work to be accomplished. It includes the objectives of the project, a brief description of the work, the funding constraint, if one exists, the specifications, and a milestone schedule.
Usually the SOW is not generated or even reviewed in detail during a Project:Go! For those Project:Go! for which a project manager has brought a SOW for discussion, one-half to one hour is allocated.
The next activity is to review the strategic approach to achieving the scope with the team. The team brainstorms or otherwise generates a list of all the functional areas or skill sets that will participate in the project. The project is partitioned into a few large sub-projects (ideally, corresponding to the major chronological deliverables of the project) and the team discusses its way through the conduct of these broad sub-projects, discussing what the principal contributions are expected to be from each of the defined functional or skill set areas. This activity serves as a “sanity check” that all team members have the same general understanding of the tasks at hand, and it also tends to surface some significant issues or broad “holes” in the team structure or project concepts.
Figure 2. WBS Tree Structure
Throughout the workshop, whenever any statement is heard that is interpretable as being a Risk, an Assumption, an Issue, or a Definition, it is captured on a flip chart as part of the “RAID” list. The flip chart pages are posted on the wall for review and disposition later in the workshop. The RAID list has been an extremely useful tool in that it captures issues and risks that must not be neglected. It tunes the team members to be sensitive to these entities and how to deal with them, and it helps keep the workshop focused and on track by logging these thoughts for later addressing, obviating the natural tendencies of most teams to want to deal with every surfaced issue in real time.
A discussion of team member roles is next. Each team member fills out a flip chart page according to a template to define his or her role on the team. They answer the questions “Why am I here? What do I bring to the team? Who do I bring it for? What do I need from other team members? What are my constraints? How much time do I believe I will have available for participation on this team?” The flip charts are posted on the wall and reviewed by all of the team members. The other team members are allowed to mark up the flip charts they read as long as they initial their comments.
WBS ,,What Boring Stuff!
The project deliverables are next generated, based entirely on the scope statement. They are written on pieces of paper and posted on the wall, initiating the creation of a wall covered by a work breakdown structure. If there is any confusion about any of the deliverables in the deliverables hierarchy, scope statements for the particular deliverables are written and posted along with the deliverable. Ownership, in the “honchoing to completeness” sense, for every deliverable is determined and the associated tasks for each deliverable of the work breakdown structure is documented using special dedicated tags, color-coded for the individuals or functional areas on the team, and posted on the wall.
While generating the WBS, the scope and statement of work guide the team. Deliverables are refined until the team can understand the magnitude of the tasks associated with each. As shown in Figure 2, tasks can be used to describe some deliverables after the first level of “breakdown.” Others may require additional levels of detail. The WBS provides an organized presentation of the work items consisting of deliverables and the tasks associated with a deliverable. Deliverables usually consist of products and services. Tasks are also known as milestones, work packages, activities, or steps, depending on the organization and size of the project being planned.
Figure 3. Project Go! Task Tag Form
Figure 4. Time Line Chart
A team reviews a draft Gantt chart constructed from the duration and networking information on the task tags. The tags are in different colors, corresponding to the skill sets of the team members performing the tasks.
The level of detail should be driven by identified risks and communication needs—not by knowledge. Most technical professionals will provide too much detail for deliverables that are well understood and have little risk, and provide none for high-risk areas for which they have little knowledge. This is the opposite of what is needed.
The color-coded task tags (Figure 3) contain important information about the individual tasks that must be accomplished in order to complete the deliverables of the project. The task description, owner, resources, duration, and the effort are filled out by the individuals or functional areas that are responsible for them. The description should be concise, but contain enough information so that everyone within the project group under-stands it. The owner can be either an individual's name or that functional group that will actually do the work, and the resource space should contain any additional people that are required. The amount of time needed to accomplish the task goes into the effort space, while the actual time that it would take considering other responsibilities of that resource goes under duration. Any capital investment needed for specific tasks can also be placed on the tags. Also, if the estimated start or stop dates are known, they can be filled in, with the understanding that the actual dates are figured out later by the computer. As the team is filling these tags out, if they think of a task another group has to do they can get that other group's color and fill the tag out for them. The team members should be talking and discussing with each other as they fill out the tags. As the tags are completed, they are placed on the wall. They aren't placed in chronological order, but under their respective deliverables. The team members keep in mind that if all the task tags under a deliverable are done, then that deliverable is completed.
The team and sponsor have now agreed on the specific criteria for project success (the scope statement). The team has a good idea of how it will get there (the strategic approach). The roles of the team members are known, as are the specific entities (deliverables) that must be achieved to accomplish the scope. Finally, who is going to honcho each deliverable into existence and who does what tasks to make that happen is identified. The project is very well defined (if we do these things, we will generate these deliverables, which in turn define the scope, which is exactly what we and the sponsor want to accomplish).
Finishing the Start-Up
Once the work breakdown structure for the project has been generated and posted by all of the team members, a detailed review occurs. The owner of each of the lowest-level deliverables reviews in front of the team all of the tasks associated with that deliverable. There is a sanity check for completeness, comprehensiveness, appropriate level of effort, duration, and so forth. The tasks are then numbered, and networked, to complete the WBS structure as a basis for computer entry and reporting.
At this point, the team may elect to “build” a rudimentary Gantt chart on an adjacent wall, moving and posting the task tags per the networking information written on them on a time line chart (Figure 4), or the team may elect to enter the work breakdown structure into software and work with it in that form going forward.
The sponsor rejoins the team and reviews the wall Gantt chart (or the computer-generated reports if that option was taken). The sufficiency of the planned tasks to achieve the deliverable against the scope may be discussed, and any final negotiation on the scope or the dates called out in the scope should happen at this time. Team norms are next developed by the team, covering all aspects of team communication, reports, meeting style, agreements, how it will make decisions, how it will resolve disputes, how it will document and maintain its output, how it will measure success along the way, and many other topics.
Finally, the RAID list is reviewed. Each entry is classified as a Risk, Assumption, Issue or Definition. Definitions are collected to begin a glossary for the team. Assumptions are tested to see if the team really believes them. Those passing the test are logged to begin an assumption list for the team and the project.
Issues are identified as such and the team decides who owns getting each issue resolved. The owner may make issue resolution a task, adding it to the WBS, or may elect to take resolution of the issue as an action item, and the team action item list is born. The owner specifies either the date by which the issue will be resolved or the date by which he or she will know when the issue will be resolved. Finally, project risks are collected, and the team decides whether it would like to work on risk management in real time or revisit the risks later.
If real-time risk management is selected, the facilitator can provide the team with some risk management best practices and the work proceeds. For instance, the team can select its top five risks, then, for each one, brainstorm “how do we avoid this” and “what do we do if it happens.” If “what we do if it happens” is Fail, then the team revisits its “how do we avoid this” list for a few minutes, picks the best choices and puts them into the schedule as tasks. This can be done quickly in real time and, if not eliminating the risk, at least elevates the schedule status for future analysis and response.
Keep Go!ing and Go!ing …
After the workshop, task tag data is transferred to a scheduling tool, then reviewed and modified by the team. Risks, constraints, assumptions, strategies, and roles are also documented. These materials become the baseline plan from which the project will be subsequently managed. If a large project, this may be the foundation for a follow-up planning workshop and associated activities. These follow-ups may include additional team members, key subcontractors/partners, and/or customers.
In the 18 months since Project:Go! was introduced, over 50 teams have used it. It has been extremely well received by team members, project leaders, and sponsors alike, and our facilitators are typically managing a queue of several projects.
What Else Is Go!ing On?
In addition to Project:Go!, an association of project leaders has been formed within the company. As there is no organizational “Project Leader” group in the company, we formed “Project Leaders Anonymous” (PLA). This group meets about once every three weeks. In each meeting there is a featured guest, typically from elsewhere in the corporation, to bring new information, knowledge or skills to our project leaders. There is also a time for sharing internal triumphs, issues, or systematic opportunities for discussion or brainstorming. Finally, PLA occasionally spawns ad hoc teams to work on an issue or opportunity of common interest to the project leaders in our company.
The Next Level
As the company makes the transition into the second phase of achieving a best practice project management culture, a source book is being drafted over the name of PLA to serve as a desktop reference for project leaders and team members. The source book is being set up to be user friendly, comprising a short set of guidelines in conjunction with a brief checklist for each of about two dozen topics relating to the startup, execution, monitoring, and closure of projects. A general awareness course of about an hour in length is being prepared and will be presented to all those in the company who participate in projects as part of their core curriculum in the coming year. In addition, the groundwork is being laid for a follow-on to Project:Go! that will focus on project execution and closure. Finally, we have begun conceptualizing the management of multiple or aggregate projects and have concluded that benchmarking is in order for developing a sound definition of our multiproject management system.
Go! Catches On
As Project:Go! focused on project startup, and we freely admit that we still have best practices to learn in the area of execution to schedule, most of our information on results to date are anecdotal in nature. Sponsors of several of the projects we have facilitated have mentioned to us that they “… never could have pulled-off the project without Project:Go!.” When we first introduced Project: Go!, our request for at least three days time usually resulted in shocked disbelief. “Can't we do this in a morning?” was the normal response. At this writing, word of the usefulness of Project:Go! has gotten around and our request for three days is often met with an enthusiastic “OK, but why don't we plan for five!” We also find that as the early projects are completing, the project leader or sponsor is requesting Project:Go! for subsequent projects as well. We also notice that several of the features of Project:Go!, such as the RAID list concept and WBS techniques, are being used by groups for meetings and other planning sessions.
What We've Learned
We found that every Project:Go! experience was different. Our facilitators have become very flexible in mapping the Project:Go! experience onto the particular needs of a given team and project. We also found that the “role definition” portion of the start-up has become an increasingly significant part of the procedure for the team and its members. Teams are also becoming increasingly interested in the norms, that is, how they will be functioning as a team. In both of these areas we are making perhaps triple the time investment as we did in the beginning. For our particular company, team members seem least familiar with the concept and practice of WBS generation, and that has been the principle area of “teaching” during the start-up process. We have also learned that for many projects, particularly broad projects involving the bringing to market of a new product or technology, or the planning, construction and implementation of a new factory site, finding our good project leaders hasn't been easy. Our response to this situation has been the founding of PLA.
Lessons Learned About Facilitating
Workshop Preparation. Project managers that review draft materials with the sponsor and core team members get better results.
Workshop Follow-up. Record and distribute Project:Go! results quickly. Results documented and delivered to team members on the same day is awesome! The next day is great, the next week good, and thereafter deteriorates quickly.
Other lessons learned and a primer for new facilitators can be found in the PMI ‘95 Proceedings paper titled “Concurrent Planning Workshops: The Best Way to Communicate During Project Planning” by Alexander Walton, Harris Corporation.
Metrics
A key metric for the Project:Go! is the facilitator's involvement during the workshop. If he or she is sitting down by the first afternoon, occasionally answering a question—good job. If engaged and “leading” throughout, then the team has not established ownership. The second time a project manager is involved in a Project:Go!, she may tell us to just observe and correct when needed. The third time we may only get involved during the pre- and post-startup steps. The fourth time we're looking for another person to train.
For a six-month to one-year effort, tasks should be one to two weeks in duration. For very large projects, nominal durations of one to two months may be appropriate, especially for the out years. Other typical characteristics for a new product development include:
- Number of tasks: approximately 150 tags
- Number of tasks per deliverable: 3 to 15
- Levels of WBS: two to three
- Schedule Bars: support the nominal task duration.
The first phase of our endeavor to install a best practice project management culture is completing and the second phase is just now beginning. We believe we are headed down the right track as a company and are well on our way towards having a best practice culture. ■
Ken Ports, Ph.D., is a member of the senior technical staff at Harris Semiconductor. His responsibilities include managing the company's systems for project management and for bringing products to market. He has facilitated over 30 teams through Project:Go!
Maggi Dutczak, a student at the University of Florida, Gainesville, Fla., anticipates receiving her bachelor's in electrical engineering in 1997. She is an intern at Harris Semiconductor, focusing on project management systems and software.
Alex Walton is a systems engineer and program manager now working in the Digital Telephone Systems Division of Harris. He is an internal consultant to all Harris divisions, and teaches program management at the university level.
