Adapting project management to a non-project organization
The Business Problem
SiTech (a fictional name, but a real situation) is a global leader in the brutally competitive semiconductor manufacturing market. Although SiTech invested heavily in factory improvement projects to stay competitive, many of these projects were not successful. They missed the schedule and were off budget, did not deliver what was originally intended, and delivered too many last-minute surprises to the senior management team.
SiTech's U.S. directors realized that they would have to improve SiTech's project success rate to thrive in an increasingly competitive landscape. Therefore, they sponsored an initiative to improve project management within the U.S. engineering team. This team provides engineering support for semiconductor factory operations, as well as implementing new projects that will improve yield, reduce costs, enhance quality, and bring new capabilities and technologies online.
Using a consultative process, SiTech analyzed the situation, and then modified project management “best practices” to make them appropriate for an organization with low project management maturity and a culture focused on operations, not projects.
This paper describes the analysis process and subsequent design of custom project and portfolio management techniques. It also summarizes the lessons learned from the implementation and follow-up results on how much project success has improved. This paper is especially applicable for managers and project staff who:
- want to assess and fix systemic project problems that involve an entire organization;
- are dealing with a low project maturity environment; and
- are in a situation where operations take priority over projects.
Overview of Approach
The scope of the SiTech initiative described in this paper covered all factory improvement projects carried out by about 80 engineers and technical staff at the U.S. factory operations. Project failures in this area were very visible to the executive team because they threatened SiTech's future competitiveness and profitability. Since the initiative was so visible and directly affected the work of many people, SiTech used a seven-step process to guide the initiative.
- Validate the problem statement,
- Determine root causes of project shortfalls,
- Define the acceptable solution space,
- Jointly do detailed design of project management system,
- Pilot and refine,
- Rollout, and
- Assess results.
This initiative, like most successful large-scale organizational changes, was driven by a champion at the executive level. The executive champion saw the urgent business need for improving project management and hired me as an external consultant to guide the initiative. I have written this paper from the point of view of someone who must guide a team of people to improve project management substantially, starting from a very low level of project management maturity. In other organizations, the person in the guiding role might be either an internal employee or an external consultant. For convenience, I will use the word consultant to refer to either an internal or an external person in that role.
Seven Steps to a Solution
Step 1. Validate the Problem Statement
SiTech managers and team leaders first stated the problem as “Our engineers need more project management education so their projects are more successful.” This led them to prescribe a solution (training classes) for the problem's symptoms (project failures), without really understanding, the problem's root causes. I call this “solution-itis.” Solution-itis happens frequently, as any project manager who has elicited requirements knows. In SiTech's situation, it posed two big two dangers.
- The prescribed solution may be the wrong one, based on an incomplete understanding of the problems. Without understanding the root causes of why projects failed, there was a very real danger of implementing a solution that did not solve the problem. That is a recipe for client/sponsor dissatisfaction. As James T. Brown (2008) says, “Treating symptoms is dangerous business, because it means the problem hasn't gone away; the root cause will continue to grow and ultimately create more symptoms that need to be cured” (p. 209)
- As quality pioneer W. Edwards Deming pointed out, the majority of quality problems are system problems that individuals cannot solve alone (Walton, 1990). Therefore, just giving individual engineers new skills via training may completely ignore vital system problems.
Thus, before doing anything else, validate that the problem statement is correct. A few hours here can save untold grief later.
In SiTech's case, asking key people why projects had been unsuccessful quickly revealed that there were deeper and systemic problems than merely a lack of project management education. Therefore, the management team agreed to participate in a root cause assessment before continuing further into solution space.
Exhibit 1: Selecting the right people
Step 2. Determine Root Causes
With a good problem statement in hand, proceed to find the root causes of the problem. There are three steps to this.
- Interview the right people,
- Look at project management artifacts, and
- Analyze the raw data.
Interview the Right People
The most fruitful and sometimes the most neglected method of gathering relevant information is simply to talk with a sample of the people who do projects. Most project workers have an inkling of root causes, although they may not be able to articulate them. The consultant can gain much relevant information by asking the right questions.
One-on-one interviews are the richest source of assessment information, even though they lack the formality and structure of survey instruments. I get a lot of useful information from them because they are high-bandwidth, interactive, and flexible. I can steer the conversation on the spot to follow promising leads and tidbits of information.
Prepare carefully for one-on-one interviews:
- Select the right people to interview (Exhibit 1).
- In advance, create three to five open-ended questions that will spark discussion and give insights into what is going on.
- Limit the number of interviews in a day because they are draining for the interviewer.
Use good interviewing techniques during the interview.
- Ask many probing questions, for example, by using the “five whys” technique. In this technique, the interviewer probes successively deeper into the underlying factors behind each answer by asking the question “Why?” five times in various phrasings.
- Listen intently.
- Stay out of solution space and resist jumping to premature conclusions.
- Take good notes of all of the conversations so you can affinitize and analyze the data from them later. I prefer written notes and do not find recordings to be useful.
Look at Artifacts
Use the information from one-on-one interviews to direct an examination of artifacts from past and current projects. The artifacts you select can be nearly any output that A Guide to the Project Management Body of Knowledge (PMBOK Guide®)—Fourth Edition (Project Management Institute [PMI], 2008) mentions, such as a work breakdown structure, a project plan, progress reports, or a risk management plan. Also, look at project management process documents, such as a description or flowchart of the project management process. Artifact reviews are primarily spot checks of interview observations, because the most useful information is in what people do, not what they write down in formal documents.
Interviews and artifact reviews were the primary method of gathering assessment information at SiTech. Surveys, facilitated group discussions, and observations of team meetings may be useful in other situations.
Finally, analyze all of this information about how the organization does projects, and distill it into a short summary of the primary problems and opportunities. I usually have 50 to 100 pages of notes and observations by this point, so distilling the information into a concise summary is challenging. I find that the following approach works well:
- Affinitize the raw observations to create categories. Then arrange all observations into these categories and analyze them for indications of systemic problems.
- Draw an Ishakawa cause and effect diagram to clarify the real root causes driving the problems. Exhibit 2 shows a fragment of the diagram for SiTech.
- Summarize the conclusions into a concise description of the gaps and opportunities.
Exhibit 2: Fragment of SiTech cause and effect diagram
This process for determining root cause uncovered six major problem areas and over 20 minor problem areas at SiTech. The six major problem areas were:
- Ad hoc project planning,
- Infrequent and subjective project monitoring and roadblock removal,
- Management didn't prioritize work and say no to some projects,
- Difficulty managing urgent interrupts from ongoing factory operations,
- Unclear roles, responsibility, and accountability regarding projects, and
- A culture of firefighting.
Step 3. Define the Solution Space
The root cause analysis clearly showed that SiTech had low project management maturity. SiTech had not yet achieved level 1 on Kerzner's maturity scale (common language). Exhibit 3 shows the characteristics of Kerzner's five maturity levels (Kerzner, 2001, p. 44).
- There was not a common language or protocols regarding project management, although a few individuals knew about project management principles from past work or outside education.
- Individual project owners were on their own to figure out how to define, plan, and execute their projects, so most projects were managed in an ad hoc way with no commonality or re-use.
- At the organizational level, the only processes and forums related to projects were focused on corporate approval, reporting, and financial management.
Exhibit 3: Kerzner's project management maturity levels
Maturity level 2E is a reasonable long-term target for SiTech.
Given this low maturity level, SiTech managers selected four ground rules to guide the design of the project management solution.
1. Consider the whole system: At maturity level 1, nearly everything is ad hoc. There is no common language and no systematic way of doing projects. Therefore, any solutions must address the need for a whole system, even if it is very simple.
2. Simplicity is king: When the target organization is at a low level of maturity, the initial solutions must emphasize simplicity. In this environment, changing the culture and people's behavior is a bigger concern than the technical purity of the project management techniques that will be introduced.
3. Antibodies will attack: Making business process changes in a low maturity environment will provoke resistance (in medical terms, the antibodies will come out to attack the perceived invaders.) The initiative will fail without buy-in and ownership, no matter how technically elegant the solution is.
4. End users must feel long-term “ownership” of any solutions. It must be their system, not a prefabricated methodology that an outsider brought in. For this reason, key influencers from the SiTech user community, even opponents, had significant input and involvement in the entire process. For example, SiTech created a core team to oversee system design and implementation. The core team was composed of people who often led or participated in projects.
Step 4. Jointly Design the Project Management System
Next, the core steering team prioritized which of the project management problems to focus on first, being careful not to try to do too much at once. Then the team created an implementation roadmap that showed the order in which solutions to each problem would be implemented. The road map, shown in Exhibit 4, balances gaining quick, high-visibility wins with making long-term foundational improvements. In keeping with the simplicity ground rule, it emphasizes a vital few project management areas: project definition, planning, tracking, and escalation.
Following agreement on the roadmap, the core team co-designed the elements of SiTech's new project management system. The co-design concept was very important to satisfy the ground rule about long-term ownership. In this case, co-design means that the detailed design of project management techniques and tools was done as a partnership between the consultant and the users. The role of the consultant was to spark ideas by bringing knowledge of best practices, a toolbox of project management techniques, and the ability to teach and guide. The users brought deep understanding of the business and the unique culture of the group.
Exhibit 4: SiTech's implementation road map
The resulting SiTech project management system has six major components.
- A four-phase project management life cycle provides a simple and memorable framework for everything else to fit into. The four phases are define, plan, execute, and close.
- Permeable gates with control checklists gate the start of each phase. The checklists specify a simple set of conditions that must be met to exit from the preceding phase. Permeable means that the project manager and project sponsor can agree to start the next phase before the preceding phase is complete. They do this by documenting exceptions to the gate checklist, along with what actions they will take to resolve the exceptions in a timely manner. Permeable gates increase flexibility and allow SiTech project personnel to select a level of concurrency appropriate to their wide variety of project types and sizes.
- The system clearly defines key roles on projects, especially the roles of project manager and project sponsor. Prior to the initiative, these concepts existed at SiTech only in fuzzy ways.
- An overall project management process, keyed to the four phases, specifies both required and optional project management activities. It is based on simplifications of selected processes from the PMBOK Guide®—Fourth Edition. In keeping with the simplicity ground rule, the SiTech project management process emphasizes just one or two major project management activities in each phase. The primary documentation is a user-friendly flowchart poster and a “toolkit,” described below. Exhibit 5 shows the phases and the primary project management activities associated with each one.
- A web-based toolkit provides instructions, templates, and completed real-world SiTech examples for each of the required and optional project management activities. Everything is written in simple, non-technical language that avoids or explains technical terms. This helps part-time, “accidental” project managers. Exhibit 8 at the end of this paper gives a complete list of the toolbox contents.
- A very simple project governance system establishes forums and protocols for progress reporting, project reviews, gate approvals, and issue escalation, while basic project selection techniques help management prioritize projects and analyze resource capacity at a high level.
Exhibit 5: SiTech project management phases and primary activities
Exhibit 6: Contents of SiTech's two-page charter
Steps 5 and 6. Pilot and Roll Out
SiTech identified seven projects to use as pilots for the new project management system. Some of these projects were new, while others were already in progress. The core team managed each of these projects using the new project management system, tuning the new processes and toolkit as they received feedback from the pilots.
SiTech did a wider rollout to encompass more projects and people once the pilots were completed. The rollout used several methods.
- An instructor delivered focused training through two-day workshops. SiTech trained 74 engineering personnel. People from other departments as diverse as human resources and finance liked what they saw and requested their own additional training. This training had two purposes.
- General education about project management brought everyone to a minimum level of common language and an understanding of fundamental techniques.
- Specific training taught how to use the SiTech processes and toolkit.
- A project management expert coached project leaders, project team members, and managers on real projects.
- The toolkit was posted on SiTech's intranet, allowing “self-service” usage.
- Executive sponsors stepped up their level of support by raising expectations and accountability for using the new SiTech process and tools.
Step 7. Assess Results
We learned eight major takeaways during implementation.
- Project management will always be secondary. SiTech's silicon factories mix project-based work with support of 24x7 mission-critical operations. Operations always trump projects in this environment. Project management must fit in the white spaces around ongoing operations. Brown says, “When you have a mix of operational and project management responsibilities, you have someone serving two masters. Both sides (operations and project management) often underestimate the role and challenge of the other” (Brown, 2008, p. 89).
- Start by building a common language. People can't work together to improve project management practices until they have a way to talk about it. This includes clearly defining key project roles. At the beginning of this initiative, SiTech did not even have a shared understanding of what a project manager or a project sponsor was.
- Contextualize project management. Base solutions on the best practices of project management, but customize the techniques and language to fit the specific goals of the unique organization. There are no turnkey project management solutions. Since SiTech was an organization with low project management maturity and a primary focus on operations, this meant favoring simple, flexible, and low-overhead techniques above technical correctness.
- Pick your battles carefully. Concentrate efforts on a few key areas that will have big payback. For example, the PMBOK Guide®—Fourth Edition describes many useful techniques, but newcomers can only absorb a fraction of them. It is much better to have people deeply understand a few techniques than it is to give them surface knowledge of many. Therefore, SiTech focused on a small number of project management techniques that would yield the highest benefit to the business.
- Everything is about organizational change. Initiatives like SiTech's are only secondarily about project management. The consultant and sponsor must think like change management champions, and use excellent change management techniques. John Kotter's work is a good place to start. Here are some change tips that were important to us.
- Make sure the solution improves everyone's job, so it has staying power. Otherwise, it is just another management fad.
- Use participative design and implementation techniques to get widespread buy-in and involvement. Find ways to get users' fingerprints all over the solution so they have a sense of ownership.
- Design for quick wins. Get at least some immediate and highly visible victories so the organization does not lose interest.
- Organizational change takes more time, effort, and buy-in than you expect.
- The system is more important than its parts. The designers of the project management process must take a systems view, not just create “point” tools and techniques.
- Technology comes last. Spend the majority of the design time deciding how the people, process, and organizational aspects of doing projects will work. Software and technology play a supporting role and come later. Bringing specific software in too early threatens to shift focus to the software's capabilities, rather than on how to solve the users' problems.
- Strong and long-lasting executive sponsorship is required. You simply cannot succeed without it. SiTech's executive sponsors were persistent, led by example, and employed both gentle coaching and firm accountability.
Assessment of Results
The initiative took about 15 months from the beginning of step one (validation of the problem) to the completion of step six (rollout). About a year after rollout was complete, SiTech's executive sponsor assessed progress and reported the following results:
- Knowledge of project management techniques is widespread and best practices are being used.
- More projects are successful. Over a two-year period, delayed projects were reduced by about 45% and on-time completions nearly doubled.
- Project definition has improved dramatically. The majority of projects now have SiTech charters that clearly define the business value of the project and what the expected deliverables are.
- The status of projects is more visible to supervisors and management. Progress reports are available for most projects.
- Communication between projects and with the rest of the business has improved because of simplified progress reports and communication forums.
- Other U.S. groups have gotten involved and interest has grown internationally.
SiTech competes in a fast moving, cost sensitive, global line of business. It will stay competitive only as long as it frequently upgrades the semiconductor technology capabilities it can offer to its customers, while simultaneously improving quality and reducing costs. Successful projects are a business imperative, because they are the engine that SiTech uses to design and implement these vital fab upgrades and processing improvements.
SiTech tackled this challenge by using a seven-step approach to determine the root causes of systemic project failures, design solutions that were appropriate for their operations-oriented environment, and then widely roll out a new project management system.
Two factors especially shaped this initiative. First, SiTech's fab operations run 24x7, so operations will always trump projects. Second, projects were run ad hoc and the organization's project management maturity was at the lowest level of Kerzner's scale. Both of these factors drove the need for simplicity and low overhead.
The focus throughput the project was on collaboratively building a system of simple but effective project management techniques. A key goal was to give a widespread sense of ownership to the ultimate users of the system – the project leaders, team members, and the technical management team.
SiTech packaged the tools, templates, and instructions that support the new project management system as a web-based toolkit that is easy to use. The toolkit supports SiTech's new project management process and enables part-time project managers to do a lot on their own, without a project management expert around. The elements of the completed system address all four of the improvement areas recommended by McConnell (Exhibit 7). (McConnell, 1996)
The initiative was successful, with on time project completions nearly doubling over a two-year period. We learned that even proven project management techniques must be contextualized, sometimes almost beyond the point of recognition, to fit the specific environment where they are used. A systems perspective and participative design techniques are essential for building long-term adoption.
Exhibit 7: How SiTech's solution corresponds to McConnell's focus areas
Exhibit 8: Contents of SiTech's project management toolkit
Brown, J. T. (2008). The handbook of program management. New York: McGraw-Hill.
Kerzner, H. (2001). Strategic planning for project management using a project management maturity model. New York: John Wiley & Sons, Inc.
McConnell, S. (1996). Rapid development: Taming wild software schedules. Redmond, WA: Microsoft Press.
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® guide) (4th ed.). Newtown Square, PA: Project Management Institute.
Walton, M. (1990). Deming management at work. New York: G. P. Putnam's Sons.
© 2009, Jeff Oltmann
Originally published as a part of 2009 PMI Global Congress Proceedings – Orlando, Florida, USA
Presents the latest thinking regarding good and accepted practices in the area of scheduling for a project.