Improving project management processes
lessons learned along a bumpy road to success
Organizational Landscape, Goals, and Challenges
The Intel information technology (IT) department, like many other organizations, was seeing issues with completing software projects on time and satisfying customers. Intel is a large company operating worldwide with more than 5,000 employees. We manage projects that contain everything from hardware, to software to systems integration. Our products are used by professionals in human resources, legal, finance, and external customers in addition to Intel employees.
Process Frameworks for Consideration
We have adopted A Guide to the Project Management Body of Knowledge (PMBOK® Guide - Third Edition) as the foundation for project management, and we actively encourage our project managers to obtain their PMP® credentials. We also use the Software Engineering Institute’s Capability Maturity Model Integrated (CMMI®) internally as a measure of our process maturity. Using CMMI® and the PMBOK® Guide as a basis to tackle our schedule issues, management challenged us with the goal of being at CMMI® Capability Level 3 in 18 months. While we acknowledged that this goal was overly ambitious, we still tried to accomplish the objective.
Initial Approach to Project Process Creation
Process Development by Committee
With this directive from senior management, our first approach was to develop software project processes with a small team of organization representatives. The processes were developed through virtual sessions with approximately 20–25 people on a phone bridge. A few strong personalities drove the sessions, and the processes became a container for any and all project approaches mandated by the organization. The result was processes that were large, verbose, and difficult for the typical project manager to understand. IT mandated the use of the processes for all software projects.
The initial feedback from the project managers who had to use and comply with these processes bordered on revolt. Overwhelming feedback indicated that the processes were not a reflection of how project work needed to be done in our environment, but more of a one-size-fits-all approach that was overly bureaucratic and not applicable to many of the organizations project types. The root cause was the original approach to developing the processes. A new approach was needed and it had to be done quickly or the process improvement program would be cancelled.
Process Simplification: API – Accelerated Process Improvement
Customer Feedback and a Collaborative Approach to Process Development
Based on customer feedback, audit results, and process coach input, we created a Pareto and identified a number of the work processes that were most complex and difficult to use. The organization gathered 35 representatives including key customers, engineers, process coaches, and auditors for an intense 3.5 days of face-to-face meeting.
A key component of the successful collaboration was sequestering the team at an off-site facility to maximize focus and support a collaborative environment. This agenda for this event was driven by the customers rather than the process engineers. The customers drove the vast majority of the changes with a primary focus on accomplishing business results rather than textbook model compliance. The team reviewed each work process against the business requirements and the CMMI model to identify portions of the process that could be considered for deletion or simplification.
One of the themes we noticed was that the initial process development team had implemented many of the sub-practices in the CMMI model without linking the sub-practice to a business goal. For example, we required each document to have unique identifier labels both internal to the document and in the file name, a convention that was unnecessarily complex and added little value for our typical 8–12 person project teams. We also had defined and mandated specific elicitation techniques to meet the intent of the sub-practices in the requirements development process area. These techniques were overkill for our small project teams which work closely with their customers and stakeholders. We eliminated the requirement for separate formal commitment for resources by combining this with one of the key milestone decisions.
Exhibit 1 shows the old processes for scope, schedule and resource management. These separate processes totaled 29 pages and 17 process steps. The new process was able to combine scope, schedule and resource management into one process document of five pages long with eight process steps. This was accomplished by simplifying wording, combining or eliminating process steps, and removing instructional text which we thought would substitute for skills expertise from the process documents.
Exhibit 1: Example simplification and reduction
Overall, we achieved a 70% reduction in document length, with one process shrinking to just 17% of its original size. Details of other process and template reductions are shown in Exhibit 2.
Exhibit 2: Old vs. New Document Sizes
When we evaluated the outcome of the effort, one of our project managers said, “The API face to face session was great for analyzing the weak spots (in the documentation and in the processes), as well as acknowledging the flaws of the previous release. The teams addressed the issues with great teamwork that allowed for development of some creative and tangible action plans.”
In the end, we reduced the workload of our processes and improved documentation so that it would more effectively deliver key information. The result of process simplification was the ability of smaller projects, originally deemed out of scope, to adopt the processes. Our number of eligible projects went from 36% to 50%. Our process coaches could now support an average of 18 projects per coach, up from 14 projects per coach before the simplification. In addition, the training courses were streamlined to half of their original duration.
Processes for a Broader Range of Projects
Reuse of Existing Methods for All Projects
In the first quarter of 2007, IT management determined that it was time to extend formal processes to every project in IT—software and non-software. A subset of the process team worked to reuse the existing methods from software for projects that included hardware, proof of concept, etc. The result was a set of simpler processes that could be interpreted in different technical domains. However, some of the original software terminology was left in the processes causing some confusion during the adoption period. Projects of less than eight weeks duration from charter to delivery were exempt from using the formal processes.
Small Projects Processes
As our adoption rates for small, medium, and large projects come close to 100%, we began to look for ways to help the projects originally deemed too small for our processes. These very small projects, less than eight weeks duration, were not required to follow any formal process, reporting, tracking or quality standards. While some projects had self-imposed standards, many project managers were not clear on the requirements for projects less than eight weeks. Others understood the eight-week rule and deliberately divided the work into eight-week buckets to avoid processes and audits. Management had limited visibility to projects less than eight weeks in duration. And finally, groups within IT were struggling with the very definition of project work. It was unclear what defined a short project versus a maintenance activity.
While our original focus was on projects less than eight weeks in duration, we kept hearing the complaints from project managers whose projects were 8–12 weeks long but had one to three fractional resources performing work. These project managers wanted an even more lightweight process. They argued that they spent most of their time filling out forms or compliance checklists rather than focusing on the small task at hand. We also had project managers run their projects as they normally do then go back after the fact and fill in process paperwork. Learning from past experience, we involved customers to determine what the small projects actually needed before building and deploying a process to the entire organization. We set out to provide guidance to all small projects with the appropriate level of process.
Proof of Concept (PoC)
The approach was to first determine the scope of the effort through a proof of concept in one IT group. We then analyzed the data to determine if an IT-wide deployment was warranted or if we needed additional pilots. Finally, we planned to take a thorough look at our entire process library to implement a more robust project characterization approach that right-sizes the processes and tools used by our project teams.
Our projects’ process deliverables are defined at two main levels. The first level is what a project needed to review at a milestone decision meeting with management (e.g., requirements, design, and schedule). The second level is deliverables that would typically be produced through typical project work (e.g., various supporting plans, internal compliance scorecards, review and approval records, and change records).
What we found is that by spelling out all these deliverables, small project teams of one to three people were overcome by the process volume. The goal for these projects should be more focused on producing the product deliverables and less on process deliverables. The approach to the PoC was to determine the major process deliverables that a project should produce and require only those deliverables. To speed up the PoC, we started with the first-level deliverables, what is required at the milestone decision meetings. We decided to leave the second-level process deliverables up to the discretion of the project manager.
The other major challenge we wanted to work through in the PoC was defining what constitutes a small, medium or large project. We heard from PM’s who had projects that lasted longer than 8 weeks, but overall effort was minimal (just 1-3 people on a project). We decided to lighten up the requirement for full process adoption for certain project greater than 8 weeks long. A more pragmatic approach was to look at several characteristics, such as team size, overall effort, and project risk. This approach in the PoC provided immediate relief to several small effort projects. The effect of this PoC is a groundswell of anticipation to apply the PoC learnings to our larger projects.
We used what we learned during the PoC, along with additional information from focus groups which included teams outside of the organization that performed the PoC, to develop a small project process which was released at the end of the first quarter of 2008. This new process consists of a Microsoft® Excel template for the project management plan and contains a checklist of required deliverables and a guideline document which helps sponsoring managers and project managers select a decision model. It also includes a tool for managing the project’s schedule from the allowable options. Currently, this “smaller” version of the project management process is available to all projects of less than eight weeks in duration.
Sample Metrics (PCR & TPT)
When we released the processes to all project teams, software, and non-software, we also began collecting and reviewing some measures that would help us identify problems going forward. The two metrics that senior management monitors are performance to committed release (PCR) and throughput time (TPT).
PCR measures the difference between the date the project team commits to release the product and the date that the product actually gets released. The gap between the two dates is allowed to be up to two weeks. Projects that deliver more than two weeks later than planned are subjected to scrutiny so that management can understand what happened and prevent it on other projects.
TPT measures the length of time it takes each project to go from project charter to product delivery. Each of the project phases within this time period is also measured and this data is reviewed to determine how time is allocated along the life cycle. We have an organizational goal for 90% of the projects to deliver within six months. We study the time spent in each phase so that we can develop strategies to influence our ability to meet the TPT goal.
Summary: Key Learnings
In the end we learned the following:
- We need to get our customers and stakeholders involved in every step of the development process. This ensures quicker acceptance by project teams and uncovers usability problems earlier in the process.
- It is essential to have a business focus rather than a model focus. It is easy to lose sight of business objectives when trying to comply with the framework requirements of CMMI® and PMBOK® Guide.
- We should start by building processes as small as possible and add to them only as needed. We learned that by building large processes first, the true costs extends beyond the development and requires significant effort to support and maintain the processes.
- Time is the most precious commodity in process improvement. Getting a quick win that the organization would accept is more important than perfection. We were willing to accept less than perfect results in order to address pressing issues quickly. We definitely took the risk of fewer adherences to the model in order to streamline the business process.
In the end, it’s all about being both efficient and effective.
This presentation is for informational purposes only. INTEL MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
Intel, the Intel logo, Intel. leap ahead. and Intel. Leap ahead. logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
*Other names and brands may be claimed as the property of others.
Copyright © 2007 Intel Corporation. All rights reserved.
© 2008, Robyn Plouse and Mark Brodnik
Originally published as a part of the 2008 PMI Global Congress Proceedings – Denver Colorado, USA