Introduction
In 2007, management identified the need for our division of Sun Microsystems, Inc. to improve our project management practices. We formed a project delivery organization made up of project managers and technical resources focused on the enhancement of processes for the development and delivery of IT projects. The goal was to take our fledgling project delivery organization and develop it into a fully functional project management office (PMO). This would include the adoption of a project management methodology.
Many of our employees had project management experience and had taken project management courses, including the Managing Successful Projects with PRINCE2™ (PRINCE2) project management methodology (identified as a corporate standard, but lacking a corporate-level implementation). We saw the opportunity to fashion our own methodology based on PRINCE2 that would reflect our organizational culture and specific needs.
We quickly realized that the amount of work, oversight, communications, and training to build PMO processes was in itself a project. This led us to appoint a project manager and resources from the project support office (defined below) to focus on the delivery.
To develop our understanding of PRINCE2 and customize our approach, we decided to use PRINCE2 to develop the required project management processes in our PMO. We would do several jobs at once: develop the processes within the PMO, learn how to apply our PRINCE2 knowledge, build a center of expertise in project management, and customize the processes used for our PMO-run projects.
This paper summarizes our experience at Sun Microsystems, Inc. in implementing our PMO.
Getting Started
The project started as PRINCE2 recommends: establishing the business justification for the project (business case) and presenting it to our senior managers to get buy-in and approval.
We began by creating a project board. PRINCE2 clarifies the role of the “sponsor” by defining oversight and decision-making responsibilities as being carried out by individuals in three separate roles: an executive (who keeps an eye on benefits to the organization), a senior user (representing those who will use the outputs of the project), and a senior supplier (providing the resources to do the work). The persons having these three roles constitute a project board (Siegelaub, 2006). We applied another key element of PRINCE2: having the project board bear accountability for the project. This meant that the project manager would share ownership, instead of carrying the full weight of the project (as is more commonly the case).
For our project, Brian was appointed as the executive, representing his senior management’s interest in achieving the expected benefits. He was already responsible for delivery of project management processes and practices, and was empowered to make decisions. Our senior user was the second manager of the project management team, allowing Brian to focus on benefits, while the senior user would specifically represent the needs of the project manager community. Our third project board member, the senior supplier, was our project support office (PSO) manager, since her team would be doing the work and would eventually own the processes, audits, metrics, training, and maintenance.
Because we require our project managers to create project boards for their projects, this gave us some basic experience defining the roles and identifying suitable people to fill them. This was our first official “walk” with our methodology.
Although we had strong executive support for our efforts, it was critical to develop and document the business case for our work---its justification and expected benefits. We knew it would serve as a guidepost, keeping our focus on the benefits we wanted to deliver. We would use it throughout our project to inform decisions whenever we reached a crossroads.
We talked extensively about what we wanted our PMO to accomplish, and that resulted in this vision:
• That we have drive for repeatability and predictability in all that we do;
• that we build a community of professional project managers;
• that we invest in project management education for both technical project management skills; (PRINCE2, budgeting, planning, scheduling) and “soft skills” (leadership, influencing others, managing conflict, change acceptance); and
• that we be recognized as the leaders in effective project management practices and project delivery.
Our business case called for this project to provide a solid foundation for building, improving, and implementing processes that support IT program and project delivery, in the areas of:
• People---mature our project management capabilities
• Organizational efficiency
• Improve project performance (meeting cost, schedule, scope, quality expectations)
• Improve project management processes (driving repeatability and predictability)
• Organizational alignment---develop and implement consistent, proactive communications
Wherever possible, we established measurable criteria for each of these focus areas.
Our next step was to clarify the specific goals of the project and how we would go about accomplishing them. Using PRINCE2, we developed a project initiation document (or, PID, equivalent to scope statement and project management plan in A Guide to the Project Management Body of Knowledge [PMBOK® Guide]---Third edition) (Project Management Institute [PMI], 2004) . This forced us to think through all these elements and provide assurance that concerned parties would have a clear picture of what were going to do. (This approach---of constantly confirming common understanding among those involved with the project---became a key theme of the project, and of our overall approach to the project management process.)
The project board laid out their vision to the project manager through meetings and a basic project brief (project charter). The project manager developed the PID using the agreed business case, our proposed roadmap (see below), and the project brief, adding additional consideration for staffing needs, issues, risks, and so on. Since stage planning (breaking projects into manageable segments for effective governance, similar to phases) is a key PRINCE2 concept, we wanted to lead by example. Our roadmap was based on a monthly release schedule, which naturally led us to define four quarterly stages. Each stage was planned to include a formal review of the results at the end of the stage, lessons learned, and plans for the subsequent stage. We formally reviewed and signed this foundational document, completing another opportunity to “walk the walk” with PRINCE2.
As a core part of the PID, we developed a roadmap (Exhibit 1) of what we wanted the project to cover. We began by having our project managers, PSO, and management team complete PRINCE2 training together as an intact group. This provided us with a common language and approach, as well as professional credibility through practitioner certification. Our classroom training showed us a number of areas that we wanted to address, but we had to decide which processes and which aspects of the methodology to introduce first. Jay (our PRINCE2 consultant and trainer) provided us with a list of methodology elements that would be relatively easy to implement. These included the use of product descriptions (specifying how deliverables should be built, along with the criteria for quality control of those items), quality checking, risk management, preparing work packages, and using change control. In addition to Jay’s suggestions, many of the project managers who attended PRINCE2 courses had kept lists of ideas from the classes. A third key input was the vision of our organizational director: repeatability, predictability, professionalism. The combination of these inputs was the basis of a process development roadmap. Jay had encouraged us to go first for the “low-hanging fruit”---to do first the things that would be relatively easy to implement and that would quickly demonstrate the value of what we were doing. That mindset helped us begin to set our priorities.
Exhibit 1—PMO Process Roadmap
In building the roadmap, we needed to take into account our knowledge of the organization, what would and wouldn’t work culturally, and where our organization truly needed help. We developed affinitized lists (grouping-related elements and ideas) and prioritized them.
Keeping our roadmap aligned with our plan for quarterly stages, we settled on a monthly cadence, alternating major and minor releases. Our first lesson learned was to edit out lower priority items and to accept a limited scope that we could successfully deliver and for which we could gain acceptance.
This roadmap was the foundation for the project plan---documenting not just what we wanted done, but also when we would review results with the project board, allowing them to assess the ongoing viability of this project.
Building the PMO Structure
In the following section, we discuss the elements implemented as part of this project, our thoughts in developing and delivering those elements, the lessons learned along the way (good and bad), and how we adjusted what we were doing in light of those lessons. We will also indicate how we were following (and learning about) our methodology through these elements.
The first thing we needed to address were the organizational design and policy framework for our PMO, particularly the project sizing and staffing decisions. Before the formation of our project delivery organization, project managers were distributed among individual IT teams. The team managers, who would become the customers of our PMO, preferred the old model, believing it gave them improved throughput and efficiency via direct control over the project managers’ work efforts. However, IT leadership felt that these efficiencies were not being realized and that the project managers were “fighting fires” rather than driving project delivery in a planned manner. We saw inconsistent results across projects and low staff skills development and growth.
Our technical resources were already in a centralized organization, built around areas of specialization (e.g., System Administrator, Data Base Administrator, network). After considering several options for integrating the project managers into this organization, we agreed that putting them into a single team gave us the greatest chance for success. We would build a community of project managers and assemble ad hoc project teams from the appropriately skilled resources throughout our project delivery organization. Our customers were skeptical of this approach, fearing that bureaucracy and a lack of control would impact the project throughput. Significant pressure was placed on our fledgling team to deliver results quickly lest we be seen as a failure before we actually got started.
To help us manage the PMO, we turned to the PRINCE2 PSO model, building a small team that would focus on processes, measures, metrics, audits, and training in project management practices. The PSO would also take on responsibility for managing incoming project requests, prioritizing demand, and advising the PMO on project resource requirements.
To address our customers’ preference for rapid execution over process consistency, we spent time defining different type of projects. In our model, not every request for work is a full-blown “project.” We wanted to apply the right level of oversight and control to each work effort, balancing the desire to “just get it done” against the need to manage the work carefully. This is an important aspect of PRINCE2: tailoring and scaling to meet the needs of different sized projects. We defined three sizes of work effort:
- Lightweight Project: 40 hours or less of effort in one technical skill area. No formal project leadership or oversight needed (“just get it done”).
- Tech managed work: less than one person-month of work, no financial tracking needed. Effort led by a senior technical resource.
- Project: led by a project manager with full expectations on project planning, budget management, communications, and so on.
We initially tried to classify each project “by feel,” using these basic sizing guidelines, but our project teams kept coming back to management for discussion and clarification. This experience led us to develop a simple roles and responsibilities matrix for project managers, tech-leads, and team members. We defined the specific project management deliverables (management products) required of each role and project type---for example, project plans, budgets, task lists, progress reports, and communications. We later took this a step further by adding a “tech-managed work checklist” to complement our project management checklist. This tool helped leaders of our tech managed work to deliver what was expected of them on these lighter-weight projects.
Driving Quality
One of the first deliverables on our roadmap was a release process for the changes that we were introducing, including communications with and training of the project management community. The roadmap was largely developed by the management team and focused on meeting their needs. Bringing the PRINCE2 senior user to the table reminded us to share our focus between the needs of the business (management) and the needs of the project managers (the process users). This meant finding ways to increase change acceptance among the project management community. We approached this in a way that not only improved project manager involvement and acceptance but also improved the quality of our deliverables. (We shouldn’t have been surprised at that “coincidence.”)
To reduce the risk of rolling out ineffective changes, we began asking a subset of project managers to pilot each process that we released. The month before the official release. we would enter into a pilot period in which two or three project managers would volunteer to test the new process, template, or change and provide feedback about its utility and usability. Their feedback was incorporated into the final release. This practice was immediately successful, improving the quality of each deliverable and its acceptance by the project management community.
But much like our project sizing exercise, we soon realized that not all process changes are created equal. Many were too small in scope or happened too infrequently for our pilot process to be followed and still receive useful input. The process was too heavy-weight for many types of changes. This led to the addition of project manager focus-group reviews. For lighter-weight changes or for processes with infrequent use, we would have a team do a “paper pilot” exercise, walking through the proposed change as a group and discussing how it would work. This simple process could be accomplished in a short meeting or even as a discussion via e-mail.
These two methods had an unintended but tremendous side-benefit: they gave our organization built-in champions and subject matter experts for each new process, template, and tool that we rolled out. These “piloteers” would become change agents, helping coach the other project managers through the change.
A key learning from our pilot and release process was that the project managers often misunderstood the usage expectations when a new process was rolled out. Not every change, template, or tool was defined as “mandatory usage,” and even when they were, it was unclear how to address an in-flight project (one that was already in progress when the new process was released). Many project managers would assume that their active projects were exempt from the new requirements; this led to inconsistent results and unhappy customers. Our response was to define clearly during release training if a change was optional, mandatory for all new projects, or mandatory for all new and existing projects. We defined how a change was to be retro-fitted onto an existing project, and we had the project mangers record all exemptions in their project manager checklist so that later there would be no confusion over what was done versus what was required.
Another way in which we drove quality was by aligning expectations with deliverables. During the early days of our project, the process development work was done with heavy guidance and involvement from the project managers and PSO team managers. Although the managers enjoyed this role, it was the wrong answer for long-term success. Our project manager dug into her PRINCE2 manual and brought forth product descriptions (with quality criteria) as a solution to the management meddling. Going into our third monthly release, the project manager produced a draft product description for each deliverable and the management team reviewed them asynchronously (via e-mail), providing changes and additions. Their input was combined into final versions, which were then formally reviewed and approved at a project board meeting. This included our first attempts to define tolerances (limits of authority) for the deliverables, which would allow the project manager to adjust course without direct project board involvement. (Siegelaub, 2007) The project manager and team delivered brilliantly to these descriptions with much less involvement from the managers, and that was better for everyone! It streamlined the development cycle and assured that we were all “on the same page” early on, keeping changes to a minimum---truly a win-win situation for everyone involved. This was an important lesson: PRINCE2 had predefined elements that we could grab and use when we found them useful. We furthered the credibility of our chosen methodology because we could show how the product descriptions helped a project move forward.
Building Credibility
We made great strides in getting project manager acceptance of our deliverables via the pilot and peer review processes, but strong change acceptance requires a multifaceted approach. Our project managers were busy running dozens of active projects while learning their new team and new manager. They had a low tolerance for additional process changes. The management team worked constantly to evangelize the process improvement roadmap, reviewing it frequently at staff meetings and “all-hands.” They discussed openly how the roadmap was developed and prioritized. This helped build awareness and even enthusiasm for where the organization was headed. We took this further by building roadmap progress reviews into the monthly release process. PRINCE2 suggests a formalized communications plan that we had overlooked. Months later, we realized we had an informal plan in place but had missed the opportunity to develop a formal plan and test its usefulness. That is something we now plan to investigate in a future release.
To aid our release process, the process team developed several tools that would be used consistently throughout the project, giving each release a familiar look and feel with which the project managers could quickly identify. The first step was the creation of a monthly release announcement e-mail. This took on a newsletter style with topic headlines and quick-hit one-paragraph articles defining the contents of the monthly release. It served as a preview of the upcoming release training and an easy reference for later use, holding key links and references.
Each release included a mandatory live training session. The session was built around a slide deck covering each change. The sessions were recorded for later playback by those who were unable to attend or who just wanted to review the training at a later date. We also included the roadmap review, showing where we were and where we were going next, always reminding the team of the “big picture.”
We built a recognition program into the training, acknowledging the work of all the piloteers and focus group members, and these kudos were used as input for each project manager’s annual performance review. Doing this drove a high level of satisfaction with the process deliverables, created pride in ownership, and improved volunteerism.
As we gained momentum with the community, we added a project manager feedback loop into each process in pilot and in production. The project team captured these data in an improvement log, which was then used at each end stage review to adapt our roadmap to the team’s needs. We utilized the PRINCE2 lessons learned log as a basis for our improvement efforts, then built our own larger processes around it, which included the project management feedback loop. This is all part of our adaptation of the methodology to fit our needs.
Building credibility with our customers was another key focus area as we rolled out these changes. We learned that such efforts are part execution and part communications and marketing. As new processes were released, we sometimes introduced confusion in the many active projects that we were running. Some projects would be exempt from the new processes, and thus the customers didn’t see the advantage of our improvement efforts. At times our customers felt that despite our work and communications, “nothing had changed” when it came to their projects. This resulted in many personal conversations with the customers to set their expectations and in coaching sessions with the project managers on how apply new processes and tools to their projects midstream.
One of the biggest areas that we had to address was locking down customer requirements and setting baselines on projects that were already active before we introduced our project management processes. The PRINCE2 PID is at the core of project start-up and is the cornerstone for controlling a project’s scope, schedule, and budget throughout its life. We saw that projects starting up using our new methodology were running well, whereas projects that had started previously were quite messy. We came up with an approach for adding the PID’s controls to active projects. We would add or enhance the project board for an active project, making certain that the PRINCE2 roles were properly represented and would then create a “going forward agreement.” The approach required the project manager and Project Board to accept their current situation, regardless of the path that had gotten them there, and to agree on what was left to do to complete the project. The project manager would then document the remaining work effort, project schedule, and budget items and get the project board to sign the agreement. This gives the project the benefits of the PID without having put it in place at project start-up.
Refining and Maintaining Our Process
Several months into the project, we knew that we had to start an ongoing evaluation to ensure what we had built was adding value; we needed an Assurance role.
We used our PSO as a conduit for these evaluations. Our PSO provides many of the functions that PRINCE2 recommends including coordination of standards and providing PRINCE2 expertise and advice. (Office of Government Commerce [OGC], 2005, p.407). In addition, our PSO acts as a control point for customer demand, prioritizing and sizing it so that we apply the right resources to the right projects at the right time, guided by the project business case. We look to the PSO to keep an eye on new business coming our way and problems cropping up across multiple projects, to spot emerging patterns, and to advise us when new solutions are needed. The review input from our project manager request log and the lessons learned from our process development project provide recommendations on adapting our existing roadmap to better meet the needs of our project managers and customers.
A key PRINCE2 concept that we embraced from the first day of our project is that of “management by exception.” Project board members tend to be busy executives with a range of responsibilities, so we wanted to keep demands on their time to a minimum while they fulfilled their key responsibilities to the project: resource commitment, overall direction, and decision making. (OGC, 2005, p.71). Management by exception is built on a foundation of trust. The project board must trust the project manager and project team to do the work without the need for heavy management oversight. At the same time, the project manager and team need to trust the project board to get involved when requested so that problems impacting the project can be solved.
This trust is facilitated by several tools; the PID (including tolerances and a communications plan) coupled with product descriptions and quality expectations assure a project board that their project manager understands the desired end state, and relieves the board from heavy oversight of project activities. With this in mind, we developed a standard format weekly status report to keep the board informed of progress, which they could read on their schedule and at whatever level of detail that they wished.
PRINCE2 defines “tolerances” as “limits of authority” for the project manager (an extension of the classic triple constraints, with quality, benefits, and risk as three added factors) (Siegelaub, 2007). The concept had been explained to us in our courses, and we saw tolerances as powerful planning and problem-recognition tools. Because we had little practical experience using tolerances, we chose to define these tolerances gradually and use them in our project to gain that experience. As part of that process, when things were forecast to go out of tolerance in our project, we used exception reports to alert the board of the situation. Although the exception report is a useful tool, we found improved results when the project manager contacted each board member personally before sending out the exception report. This contact took the form of a short phone call or voice mail alerting the board members of the situation and that they would receive a detailed report through e-mail. This extra step ensured that there were no surprises in the executive ranks. This is now a best practice for all of our projects.
We used a standing but infrequent meeting to keep our project board talking and working together, meeting approximately once a month (at the minimum, at the end of each stage) to review progress and approve plans for the upcoming stage. The project manager sent an agenda and review materials in advance to board members so that they could come prepared and move the meeting along quickly. Our organization-wide best practice is that each project board should define its own reporting and meeting requirements, ensuring that the board and their project manager have the information necessary to feel confident in the project’s proceedings. Our only prescriptive requirements are that each project must (1) have a project board and (2) meet at least twice, once at project start-up (to approve the PID) and once at project closure to agree to shut the project down. All of this is in keeping with PRINCE2 guidance to tailor the methodology to meet our needs.
Having our project manager tracking change requests and feedback from the project managers kept the project team and board from getting distracted by issues and requests for changes, but also kept us from ignoring these inputs over the long haul. End-stage reviews were held to examine the accomplishments of the previous stage, any new change requests, and the plans for the next stage. The project manager prepared a detailed end-stage report that the Board would review in advance, allowing the meeting to focus more on plans going forward than on overly detailed discussions of what had already been done. We used these end-stage reviews to take advantage of lessons learned, adjusting our staffing, next stage plans, and tolerances to make the following stage more successful. Like any project, ours changed over time, with scope added and scope pared away, but it was always done in control with high acceptance from both management and the project manager community. Communication is key to this success, driven by the data from the change request log, lesson learned log, and issue/risk log. Changes were justified with data, not with hearsay. All of this fostered trust between the project board and the project manager, removing worries of “forgetting something” that was pushed out in favor of a new feature or other scope or schedule change.
Although PRINCE2 has a particular focus on quality, our organization does not have the robust quality culture you would find in other parts of the business. We lack the maturity of process and appropriate staffing to have dedicated testing and assurance teams. Each project has to define its own quality methods and measures.
One of the key roles for the PRINCE2 project board is that of project assurance (quality assurance). Each board member is responsible for assuring that the project’s results are “fit for purpose.” This role can be delegated to a team or individual, but the board members are ultimately accountable. In our case, the board members took on this role themselves. We were regularly evaluating the project state against the original business case, looking for opportunities to add, remove, or improve processes. We reviewed the final products for agreement with product descriptions and expectations, assuring that the project was delivering what was needed.
At the midpoint in the project, we had our PSO run a one-time audit of two key processes. This uncovered a high level of noncompliance in one area; the management team found themselves at a crossroads. Should they use the audit results in a punitive way, beating up the project managers to drive compliance, or was there another solution? Our project board firmly believed that audits are tool for measuring a process, not for measuring behavior. We presented the audit finding to the project manager team as a community and asked what part of the process wasn’t working for them. Their feedback pointed out duplicative effort across two different processes and led the project board to change the process rather than mandate compliance with a nonvalue-added step. This action was a huge credibility boost in the eyes of the project managers, and we found them much more accepting of later changes and additional audits. As we entered our second year of the project, we asked the project managers to help define the next year’s roadmap. Along with several new processes and fixes to existing ones, we found that additional auditing for process compliance was high on their list.
Summary of Recommendations and Key Lessons Learned
The PMBOK® Guide advises project management organizations to have a defined project management methodology (PMI, 2004, p. 100, 102, 105).. We found that the PRINCE2 methodology was a good fit for our organization, but (per PRINCE2’s own guidance) we didn’t blindly apply it to our PMO. Instead we field-tested it on ourselves, using it to help build our own internal version of the methodology. We kept the parts that fit our culture, enhancing some and downplaying others, while removing bits that were not a good fit for us.
Eighteen months after its inception, we have built a successful PMO. Our project managers have bought into what we are doing and are engaged in the process, our customers are seeing the benefits of our efforts (and are telling us so), and our senior management is seeing the value of our organization. In our next year, we plan to continue building on this solid foundation by always keeping in mind that right-sized processes are the key to success. We must balance project controls with pace of execution so that we deliver business value in a predictable and repeatable manner. That is our mantra. PRINCE2 was the perfect fit for us because it is founded on that very idea:
PRINCE2 may be used on any type of project in any environment. It contains a complete set of concepts and project management processes that are the minimum requirements for a properly run and managed project. However, the way in which PRINCE2 is applied to each project will vary considerably, and tailoring the method to suit the circumstances of a particular project is critical to its successful use (OCG, 2005, p. 9)
Here is a list of our key lessons learned and recommendations for building a PMO:
- Select a project management methodology for your PMO. PRINCE2 is an excellent choice, with its focus on management by exception, right-sized processes, quality within a project, and a focused business case.
- Use your methodology to build your PMO; field-testing your processes on yourself is a great way to learn what works and what doesn’t.
- Build your project manager community via process development subteams.
- Perform periodic “recap training;” show where you were, where you are, and where you’re going.
- Build in rewards and recognition. This is important work---show the team that you value it!
- Don’t try to force too much change too quickly; be willing to make the tough decisions and priority calls; leave good work behind for another day/month/quarter/year.
- Share your roadmap and rationale early and often---don’t surprise your team with a new process.
- Use project manager input to build your roadmap---this will help you get more buy-in for what you’re doing.
- Never roll out a new process without making clear your expectations for “in-flight” projects.
- Use of focus groups, process pilots, and development subteams drives project manager acceptance and creates built-in process champions/Subject Matter Experts who can coach other project managers and help drive team-wide acceptance.
- Gather customer and project manager feedback in an improvement log. Review at the end of each stage and take advantage of the chance to modify the next stage plan to pick up key requests that will help the organization move forward.
- Do customer road shows; keep them informed and get their buy-in.
- Build in compliance measures with each new process so that you can audit effectiveness of process and of adoption. Be brave enough to use noncompliance findings as a way to change and improve your processes rather than as club for punishing the employees!
