Project Management Office

Description
(1) Read the case study (AtekPC Project Management Office) carefully, and probably more than one time.
Develop a good understanding of the context and the issue(s) confronting AtekPC as they attempt to establish
a Project Management Office (PMO).
(2) Prepare a written response which clearly includes (a) an overview/summary of the case and (b) a
recommended course of action or solution that addresses the issues faced by AtekPC. A good response will
integrate course content that has been presented up to this point in the term and will also be supported by
diagrams, charts, and any other method of illustrating sound project management practices and/or a solution
to the case

The AtekPC Project Management Office
A rain had started in the early evening of March 3, 2007, and the streets of Metropolis were cold
and grey where the AtekPC headquarters were located. As John Strider, CIO for AtekPC, packed up
his briefcase at the end of the day, his thoughts returned to the new Project Management Office
(PMO) that he had approved several months ago. During his tenure of over twenty years at AtekPC,
Strider had never witnessed the kinds of pressures that were now facing the personal computer (PC)
industry. Strider recognized that the industry was in transition and that his Information Technology
(IT) organization would be involved in some critically important projects in the days ahead, as
AtekPC sought to take a leadership role in these changes. It was that thought which brought to mind
the PMO initiative. If it were implemented right, this PMO could be a big help to AtekPC, but Strider
had concerns about what might happen if they tried to push too hard with this idea. Instead of a help,
it could become another item on his growing list of problems. There were so many questions on his
mind:
How much PM is enough PM? How much PMO support is enough PMO support? When
do you get to the point that the PMO structure and process is enabling productivity and
contributes to a more successful outcome with fewer mistakes and a higher quality result—
whatever you define success to be at the beginning? And when does PM involvement become
administration for its own purposes? When do you cross the line?
Strider thought that he understood what this PMO could do for AtekPC, but the initiative was still
in its infancy. It needed time to prove itself. On the one hand, his management team had hired some
experienced people with real talent to spearhead the PMO program. On the other, they were new to
the PC business and to AtekPC. They didn’t understand how powerful the culture was here, he
thought. As Strider expressed it, the PMO had to become a part of the AtekPC culture, and that
required small changes over a long period of time. If the PMO found itself fighting against the
culture, it would definitely fail. As CIO he was keenly aware of the many initiatives and
responsibilities that he had to cover with his limited resources, and he knew the PMO was only one
of these. He couldn’t let things drop just to build up this new PMO. It all had to be done together.
Strider knew that his people who were working on the PMO were frustrated that they could not
move faster. He, too, was tempted by the thought of rapidly loading up the PMO with more
resources and knocking out projects. But in his opinion, that would be a bold and short-lived
initiative—too much, too soon, too fast.
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
308-049 The AtekPC Project Management Office
2
Strider closed his briefcase and headed for the elevator. His IT senior management team had been
with him many years. He felt confident that he could lead them on the right path without dampening
their enthusiasm for this new PMO. But would that be enough? To Strider the payoff was about
alignment—aligning strategic business directions with IT resources, and that was the essence of the
PMO. There was little margin for mistakes at AtekPC in these changing times.
Industry Background
The PC industry was experiencing tremendous cost pressure and was undergoing a period of
consolidation. As profit margins fell, PC makers were launching cost reduction strategies aimed at
further improving the efficiency of their supply chains, while lowering the cost of distribution.
According to a recent newspaper article:
The latest financial results for PC makers show a slow down in both sales and profitability.
Both corporations and consumers are holding on to their PCs for a longer period of time to
avoid the cost and hassles associated with upgrading their equipment. As a result, purchases
are being deferred and PC makers are looking at new markets for growth opportunities. The
industry appears to be undergoing a wave of consolidation as cost control and scale become
more important than ever before.1
In 2007, a major news magazine ran a cover article entitled “Whither the PC?” The threats
reported in their analysis were worldwide and stemmed from a variety of factors including the
growing popularity of mobile phones, PDAs and web-based application software.
For most people, email is the most important application that they use. For a long period of
time, sending and receiving email necessitated having a full-fledged PC. Nowadays, though,
businesspeople and consumers want to reap the benefit of being able to access email from
anywhere 24/7 without the inconvenience of carrying a notebook computer around with them.
Mobile phones and PDAs now provide this functionality, causing many people to question the
need for carrying a full-fledged computer. In the boom days of the PC, the market was
boundless, but growth has slowed considerably. Moreover, with the growing popularity of
web-based applications, both businesses and consumers are purchasing less expensive
machines that can access and run web-based applications and do not require massive amounts
of local processing power or storage. Having ignored reality for years, PC makers are at last
doing something. In order to cut costs, they are already streamlining their operations through
the use of information technology and looking at new products and new markets to maintain
revenue growth and boost profitability.2
AtekPC
Founded in 1984, AtekPC had grown to become a mid-sized U.S. PC maker with 2006 sales of $1.9
billion. AtekPC employed 2100 full-time workers and an additional 200 part-time workers. In spite of
its history of rapid growth in the 1990s, AtekPC found itself struggling alongside the world’s other
PC makers as they grappled with the transition from a growth industry to that of a maturing
industry. Strider explained:

1 Smith, David, “PC Makers face increased price competition and industry consolidation”, Metropolitan News Journal, February
17, 2007, p. B7.
2 “Whither the PC?”, Global News, March 20, 2007, p. 9.
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
The AtekPC Project Management Office 308-049
3
The PC industry has changed and will continue to change at an accelerating pace. At one
point, the PC industry enjoyed tremendous growth rates and good profit margins. As a result,
we tended not to be as careful as we should have been about controlling costs and dealing with
competitive threats. Now, of course, the picture has changed and we are facing increasing
competition from Asian PC makers that have transitioned from contract manufacturing to
marketing their own branded PCs.
The PC industry is going through some consolidation as larger players acquire smaller
players in order to achieve greater scale. So, that is the back-drop of our industry today. We
have a stronger need than ever before to be aggressive and to move quickly so that we can
reduce costs and tap new markets. We need to become a much more agile company so that our
capabilities are more consistent with our name implies. In the future, we are also going to have
to be much more savvy in terms of our use of IT or we will risk either becoming unprofitable
or becoming the target of a hostile takeover.
By the fall of 2006, AtekPC had already begun several initiatives aimed at positioning the
organization for the future. One of these was the establishment of a Strategic Planning Office whose
responsibilities were to propose business changes. Under the auspices of the Strategic Planning
Office, the initial PMO effort which was focused on IT projects would one day become an enterprise
PMO. AtekPC recognized that they would have to be able to manage projects more efficiently and
effectively in order for the proposals of the Planning Office to succeed. By March 2007, both the
Strategic Planning Office and the initial PMO had only been in operation for a few months.
According to Strider, AtekPC was under increasing price competition and management was under a
lot of pressure to make sure every action had a visible payback.
Information Technology at AtekPC
Over the years AtekPC had developed an extensive portfolio of applications. These applications
were principally focused at the operational level for business functions typical of a PC maker, such as
accounting, sourcing, manufacturing, sales, and distribution. Architectural integration of these
application systems was only moderately achieved, so that by 2007, functional areas were often
provided discrete information services with little cross-functional integration. Information systems
projects were typically operational or maintenance efforts undertaken at the request of a particular
functional area. They were generally small to medium-sized projects in terms of both size and
duration, and they were managed informally without standardized practices. As the Director of
Application Development, Richard Steinberg explained:
Historically, we had always just done our own thing. We had a lot of operational projects
going on and a lot of enhancements going on, but we had very few enterprise applications
going on. . . . Over the years, there were certain people throughout the company that
recognized that the quality of the work that we did on projects could be improved. As we
began to take a look at what we needed to do in the future, we realized that we had to really
hone our skills to be able to move more aggressively and sure-footedly through projects and to
be able to handle multiple projects at one time. So I put together a plan for a PMO, essentially a
project management methodology for all my areas.
The changing environment that AtekPC faced created a number of challenges which they were
planning to address with projects of a large, complex scale. The new PMO was being introduced in
order to provide standardization in managing these projects and to gain improvements in the
planning and performance of the initiatives. Although AtekPC had undertaken a few large projects in
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
308-049 The AtekPC Project Management Office
4
the past that had employed some formal practices, these projects had not resulted in lasting
formalization of practices. Steinberg explained:
You can go back over the years, to Y2K, to the conversion of our order management system;
on those major projects they used a project management approach. They didn’t realize it. They
got everyone together; they talked about what it’s going to take to get this done, and they got it
done. Everyone handed out awards and said, “That was done well. So now that we’re through
with that, we’ve got to get back to doing projects normally.” They didn’t realize that that is the
way to do it. All of a sudden when those major things go away, when that disappears, then
you go back to trying to do things out of your back pocket again.
In 2007, IT projects were typically managed by adding PM responsibilities to one of the
development staff who were assigned to specific functional areas. For example, the Lead Analyst
assigned to Manufacturing would also play the role of project manager. Lead Analysts supervised
workgroups of analysts and programmers of varying skill levels, and they were responsible for
satisfying the requests of the functional areas as well as the performance of their workgroups. Using
an informal project initiation process, users requested IT services through the Lead Analyst who then
managed the project with the support of the resources within their workgroup. The manager, in this
case the Manufacturing Systems Manager, resolved any issues and conflicts, if needed; otherwise, the
request was received, executed, and delivered through the Lead Analyst. Project methods,
documentation, practices, and tools were individualized by the Lead Analyst with little or no
consistency across IT groups or business areas.
AtekPC had realized many benefits from this informal approach to projects. Lead Analysts often
had long tenures in their areas and developed a deep knowledge of the business activities, needs, and
people. As a result of their informal approach, they provided rapid response to user requests and
were able to balance emergent critical needs within their workgroups with few conflicts. Because of
this record of responsive delivery, considerable trust was developed between the functional area and
their Lead Analyst. The trust-based relationship was highly personalized to the individual employee,
and loyalties arose from both sides. The openness of these relationships enabled the Lead Analyst to
gather and assess quickly the requirements and to reach consensus on a schedule and delivery date.
Linda Star, a Lead Analyst for Manufacturing, described her work in this role:
In my world I have a variety of users that I talk to. They would say, ‘I need this.’ Some
would say, ‘I really need this. Can I get this? This is an emergency, and I have to have it.’ I
would come back, and I would look at what my people are working on and say ‘I need you to
switch gears. I need you to give me two hours, two days, or whatever it takes. We need to get
this little piece done.’ … I do a schedule based on what everybody in my group is doing and
what I know after talking with them.
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
The AtekPC Project Management Office 308-049
5
This informal approach to project management had traditionally been the norm at AtekPC.
Historically, the prevailing view was that IT was peripheral to the core business activities at AtekPC.
As a result, IT had been seen as an order-taker, expected to provide service on demand. During the
past decade, projects had become increasingly focused on operations and maintenance in an overriding effort to improve efficiencies within the business functions. The development of crossfunctional integration systems and the use of internet technologies were only two of many emerging
needs as AtekPC struggled with radical changes in its industry and marketplace. The required new
projects were larger, more complex and they involved multiple functional areas and multiple
technological areas unlike the tightly focused projects that were performed in the past by a single
workgroup. The demands of these new initiatives and projects were expected to overtax the current
informal project management methods. The AtekPC PMO was being implemented to provide more
consistent and better practices for both business and IT projects. However, implementing a PMO at
AtekPC was itself a challenge which required skillful management to be successful. A difficult
balance had to be maintained both between maintenance and new development as well as between
resources that went into development activities versus resources that went into project management
activities under the new PMO. Strider described the challenge:
We don’t have it all figured out. That’s better than thinking you do when you don’t. In the
IT department we have to be better able to manage the conflicts between new business critical
initiatives and operations with incremental changes to existing systems. We cannot sacrifice
one for the other. The history is that we’ve only done operational maintenance, and now we’ve
got to have a culture of doing both.
PMO Mission
The mission of the AtekPC PMO had been gradually evolving since its inception in late 2006. As
of spring 2007, there was not a complete consensus regarding its purpose, its responsibilities, and its
authority. While formal documentation and plans for the PMO did not exist, the immediate goal was
to establish the office and to prove its value. The general consensus was that the purpose of the PMO
was to realize the benefits derived from consistent project practices. Although not clearly specified or
measurable at this time, these benefits were expressed in a variety of terms ranging from IT
improvements in project performance, efficiency, and resource utilization to enterprise
improvements in cost management and corporate capability to launch products. Steinberg explained
from the enterprise perspective:
If I think about the PC industry and its challenges, I think about two things that could be
driving for a PMO. One might be cost reduction. We cannot afford to be careless. Frankly, we
have to be a lot more cautious about how we use our resources. Another motivation to get
better on projects would be that we have to get more creative, adaptive, and agile in launching
new products. And in order to launch new products, what would you say is driving those
initiatives but project management?
The responsibilities of the PMO were not so clear, however. At present the responsibilities of the
PMO were limited to IT projects, although there was ongoing discussion about expanding its scope to
an enterprise level PMO that would include business projects in the future. The specific duties of a
PMO were typically divided into two categories: project-focused and enterprise-oriented. Projectfocused responsibilities such as consulting, mentoring, and training were services that enabled the
success of individual projects. On the other hand, enterprise responsibilities addressed services that
might improve all projects such as portfolio management, PM standards, methods, and tools, and
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
308-049 The AtekPC Project Management Office
6
project performance archives. Clarification of the responsibilities of the PMO was continuously
evolving as AtekPC attempted to gain support and to reach agreement on its mission and charter:
At AtekPC, project-focused responsibilities were the primary means used to prove the merits of
their PMO. The plan was to create acceptance by consulting and mentoring on individual projects.
Mark Nelson, the new PMO Manager, talked about this effort:
What I’ve been doing since October 2006 has been providing mentoring and support for
project management with key projects that have been identified by the IT executives. For the
immediate future, until we get rolling, the plan is to have me work with a person from a
project planning standpoint—regular meetings with the teams, status reporting, maintenance
issues, and managing risks.
To that end, the PMO continued to build support from the functional areas and IT personnel
involved in these projects. One of the major limitations was the shortage of PMO expert resources
available to support these projects. In addition to Nelson, there were three other project managers
assigned to the PMO and these were contract employees. Using PMO staff to directly manage
projects was done infrequently; however, Nelson had assigned one of his project managers to a
critical project involving the launch of a new notebook computer.
Enterprise-oriented responsibilities for the new PMO were slow to develop at AtekPC. The new
PMO had been developing some standard project processes and procedures. Steven Gardner,
Manufacturing Systems Manager, commented on a project chartering process that the PMO had
introduced:
Nelson helped us develop what we call an “idea form” where we try to eliminate a lot of
random calls that are coming to us. We are trying to better prioritize what we work on, and
using this ‘idea form’ leads us toward building a business understanding of whatever the idea
is that comes along. This forces some thinking up front on our side but also on the requester’s
side. It helps them think through about usage and all. Why are we going to get savings here?
What’s the reason for doing this? Is it worth doing this project at the expense of another one?
Now, how do I prioritize it? So, it is helping us get our arms around the things that we’re
working on.
The enterprise-focused services developed by Nelson’s PMO team were being well received.
While progress in this area was constrained by the limited PMO resources, there was a clear
agreement even at the CIO level that the PMO was responsible for establishing, publishing, and
disseminating project practices, standards, and tools. On the other hand, portfolio management (the
change from managing one-off projects to the establishment of techniques for managing continuous
streams of projects) and archiving responsibilities (the establishment of archival records of projects
for knowledge sharing) were not being addressed. Nelson hoped to be able to include those duties in
the mission as the PMO developed, but without additional resources it was not achievable in the
short-term. He also realized that additional resources could only come by taking them from other
critical responsibilities, and this might compromise their ability to maintain operational effectiveness.
It was a challenging balance.
The final area of concern with respect to the mission of the PMO was the issue of authority. Strider
recognized that enforcement of these new project practices required formal authority, and he was
prepared to provide that only when the PMO had proven itself to the business and IT. For the early
development efforts, Nelson was working under the benefit of an implied authority that came from a
general awareness of changing management directions. However, the PMO also had the support of
the senior vice-president. Larry Field, Director of the Project Management Support Group, was a key
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
The AtekPC Project Management Office 308-049
7
member of the PMO initiative from its beginning and he explained: “For us to be effective, we have to
have support from the top. And we have that support from the senior vice-president through John
Strider and on down. That is the first and most critical thing to make this work.”
However, because not all of the senior executives were equally enthused about the PMO concept,
authority was primarily being developed bottom-up through the value of the PMO services. Even
this was limited to those functional areas and IT areas actively engaging the PMO. There was no
current plan to enforce usage at the enterprise level. Nelson summed up this approach with these
remarks:
The big thing is the mentoring that is going on and actually managing the projects. We are
being patient right now so that we can get some good concrete examples that we can show
them. We can say ‘look what this is doing for you. This project that would have taken a year
and a half before, we’re doing in three or four months now because we have put these
practices in place.’ And that’s the key because it lets us show our worth. That has to be the
approach for now.
PMO Organization
Two organizational models were under consideration for the PMO. These were referred to as
PMO-heavy and PMO-light, and represented two ends of a spectrum of PMO organizational
approaches. At the one extreme, PMO-heavy was characterized by a full staff of project managers
who assumed responsibility for the management of all IT projects. This model focused on the
acquisition of project management experts, either from internal or external sources, and used these
resources to manage projects under the direction of the PMO. In the extreme version of PMO-heavy,
no project would operate outside the management and direct control of the PMO. At the other end of
the spectrum, PMO-light was characterized by a minimal staff of experts who worked through
internal project managers to perform the responsibilities of the PMO. This model focused on the
development of the skills of internal project managers who were not formally connected with the
PMO. In the extreme version of PMO-light, all projects operated outside of the PMO under existing
organizational controls, and the ownership of projects resided within the functional area and IT
group charged with execution of the project. The issue of where the PMO should be situated along
the spectrum from PMO-heavy to PMO-light was generating a lot of discussion and little agreement.
Strider spoke about this controversy:
Right now, it’s four people full-time. . . . Given the speed with which we as a company want
to move—we as an industry need to move—I think four permanent people is too small. I see
these people assigned to major projects to assist, but the diversity of application is too broad. I
don’t see all of the management moving into this group. There’s kind of a difference of opinion
between me and the PMO at this point about that. We’re going to have to find some middle
ground, . . . I’m fairly convinced it should be light. That doesn’t mean I don’t question it,
because there are a lot of people in this department that are constantly challenging me on that.
Which is fine, I mean, I don’t ever need a bunch of “yes-men” around.
While Nelson was agreeable to working with a small team at the start, he felt that the delays from
this approach might compromise their ability to provide PMO services and to demonstrate its worth
to the functional areas of the business. However, he and the other managers recognized that
resources were not free, and they had to come from someplace which meant reducing the capabilities
of someone else’s work to advance his own. Strider struggled with this challenge and the current four
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
308-049 The AtekPC Project Management Office
8
PMO resources were acquired at the expense of other operational teams. Even as Nelson was
working within these limitations, he was hoping to get more help. As Nelson explained:
If I had no constraints I would like to be able to bring on the team of people consisting of
project analysts, as well as managers, very quickly. Bring in a group of people up front. Most
of them could be new to get started. Then as you go on, you could pull in from the rest of the
organization. They would all be part of the PMO. So we would have varying degrees of
experience ranging from senior PM’s to people who were junior. We could achieve a lot by just
taking this one step.
Steinberg was concerned about the resources required and how the functional areas might
perceive adding more people at this time. He explained: “What is the implication of a sponsor in
Sales trying to initiate a project that gets approval from the PMO? They don’t literally understand
what the PMO is. They think it’s sort of a road block and an obstacle to progress—a bureaucratic
thing.”
Steinberg’s concern about how people might view the PMO was shared by Strider. Although
Strider was convinced that the PMO was the right way to go for AtekPC, he knew that he also had to
ensure that IT kept its balance and got the work done. As Strider explained:
Now, if you add people, where do you add them? The fact that you can add them at all is a
breakthrough. Do you add them in this PMO, or do you add them somewhere else? . . . The
question is how you get to go where you need to go, but not violate the culture so much that
you cause a big red flag. . . . Because the PMO cannot get the project done. They’re not going to
write code; they’re not going to install servers; they’re not going to meet with users who
understand functional requirements; they’re not going to meet with customers.
On the front lines, Star was getting some information through the grapevine about this new PMO,
and she tried to make sense of what she was hearing so that she would be ready to adapt to any new
changes. She was certainly hoping for more help, especially with what she viewed as the
‘administrative things’ on a project. As a Lead Analyst, she had dealt with many of the problems of
project management, and she was keenly aware of the opportunity that the PMO created for her. She
looked forward to learning to be more effective as a project manager, but she wasn’t quite certain
what was really happening. She described her understanding of the PMO:
I thought it would be a great idea because I thought at the time that this was going to be a
group that was going to head up different projects, and they would be the lead project
manager. And then we would be their team. I was assuming that what would happen is that I
would still be the person in charge—the lead—for that project, for my group that was working.
But, I would be, in essence, reporting to this project manager who had the skills and the
knowledge and the training and the tools to help us go forward. This was because my
background in project management is my own self-created processes and tools that I’ve made
myself in order to create and do the analysis and keeping track and all that. So I thought,
they’re coming in with all these tools, and eventually they’ll be teaching us; and eventually we
will be project managers that can stand on our own.
Star’s manager, Gardner had the expectation that the PMO model would be more heavy than
light. He was already convinced of the merits of the PMO from his group’s use of the ‘idea form’ to
capture new project requests. In his understanding, the PMO would provide a project manager
resource pool. He spoke about his view of the organizational model:
They are moving from just helping us with methodology types of things to managing
projects. . . . They are thinking of a pool of project managers. You might have one such project,
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
The AtekPC Project Management Office 308-049
9
and you could borrow that one person for a while. And your project would report to them. I
think it’s the understanding that they have project managers to which you assign the various
projects throughout the department. For instance, we’re using one now for this new launch
project in addition to the projects we have now. She is starting to take over the role of planning
the timeline, scheduling, getting the right folks on board, and making sure everybody’s
informed—the typical project manager type tasks. . . . As far as project management goes, the
project is her responsibility. It’s her job.
In Gardner’s view, he would maintain control of the project, and for its duration the assigned
project manager from the PMO staff would follow his directions. Resources would be assigned in a
matrix structure for the duration of the project. This was what Gardner was doing with the current
PMO project manager who was assigned to one of his projects, and in Gardner’s opinion, this was a
big help because he had too few people and a large stack of projects to get done. Gardner was
expecting the PMO to furnish his group with project managers in a manner similar to a PMO-heavy.
On the other hand, Field recognized that the problem of PMO structure was not only about IT
staffing,
The problem with a PMO-heavy isn’t just bringing on the project managers and analysts.
It’s also the business resources. Today, we have line managers who are working on multiple
projects in addition to their regular jobs, and they can’t take on any more. What really drives a
lot of the projects in any company is the availability of the business resources to work on those
projects. Having the business resources available is already becoming a problem for us. With a
PMO-light we are lined up better with the business side in terms of the number of resources,
and it’s a better balance.
Nelson favored PMO-heavy as the best model for AtekPC, but he recognized that he would not be
able to gain acceptance immediately for this approach. The demand for resources was great
throughout AtekPC, and the PMO would need to prove itself in order to earn the resources he
wanted. He intended to build support for the PMO-heavy model through project successes. As the
PMO gained acceptance, he wanted to implement a PMO-heavy approach, furnishing project
managers to the various groups. As he said:
I don’t think there’s enough education about project management to know the difference
between PMO light and PMO heavy. There have been organizational structures that have been
discussed . . . But because of the overall change that the company is going through, they are
not ready to make any type of decision . . . With these processes and procedures that we’re
developing we’ll establish project planning, tracking, initiation, and closure. All the project
managers will help get the IT house in order.
As AtekPC sought to find the right organizational model, the PMO team worked to deliver the
services that were slowly building their credibility and proving their value to AtekPC. Finding the
right place for the PMO along the spectrum between heavy and light organizational models was an
ongoing tension that would have to be worked out sooner or later. With more resources, Nelson
believed that his team could provide more support faster and move more rapidly ahead with critical
projects and standards. On the other hand, Strider reminded Nelson that the PMO was but one of
many responsibilities within AtekPC’s IT organization. There were other needs for resources with
their own justifications and paybacks. Thus, the issue of PMO heavy versus PMO light was not a
simple or easy decision.
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
308-049 The AtekPC Project Management Office
10
Implementation and Culture
AtekPC was engaged in a difficult challenge by trying to implement standard methods in an
organization that was unaccustomed to consistent, disciplined processes and standardization. IT
management realized that in the future they would depend on standards and consistent processes to
manage their projects and drive them forward. Nonetheless, implementing a PMO in a non-PM
environment was challenging because it went against the grain of the organizational culture. Many
people within AtekPC viewed project management as just administrative overhead—something that
would inevitably get in the way of doing “real work.” Field described the cultural challenge facing
the new PMO:
We are moving from a company that had really no formal project management to a
company that would like to be very formal. We are going to be somewhere in the middle. We
can’t be so rigid about project management. This culture is not going to let us do that. You
have to mix the culture in with the methods and the processes, and now I even hear where the
processes can’t be that rigid. If we go too rigid, it will fail. We have to be a little fluid and
dynamic at times, and that upsets some PMO folks, but we have to do it that way here. To
succeed we have to develop an organization that will be flexible and will be accurate in its
reporting. So that’s my struggle -– having project management fit into a culture that is
changing but is not quite over here yet.
The forces opposing the PMO seemed overwhelming at times to those involved. Strider wondered
how willing the IT organization itself was toward changing their processes and adapting to new
project management practices. This was a key cultural issue in his mind. Many of the staff including
managers had little or no experience with formal project management practices. Very few knew how
to use any of the software tools available such as Microsoft Project. In addition to these knowledge
barriers, the informality of the current practices was seen as highly attractive by many. The functional
areas enjoyed working with IT people who were responsive to their needs and made things happen
quickly. The IT staff also found the informality appealing since there was no cost tracking nor were
any performance records kept on the projects. The functional areas were not accountable for
measuring the benefits resulting from their projects, and the IT project staff was not working within
an assigned project budget. Another source of resistance was the lack of understanding at all levels of
the value of formal project management. Altogether these sources of resistance to a PMO created
formidable cultural barriers to its success that management and the PMO team had to address.
Strider understood many of these cultural barriers and recognized that he would have to find
ways of working through them if the PMO were to survive. In a recent discussion around his office
table, he had summed up the situation: “My opinion is that I have two choices. I can conform to the
culture and survive; or I can fight the culture and fail . . . You can only swim up stream so far and so
long, regardless of how good and smart you are. But, if you fight the culture at every turn, you will
lose.”
For now, the PMO implementation strategy at AtekPC was to work within the culture and to
develop forces that would promote the PMO and overcome cultural resistance. Promotional forces
included the mentoring, coaching, and training that were being provided by the PMO team. The
company was clearly under pressure to change the way it did business, but there was no consensus
among senior management concerning the degree to which the PMO was integral to the change
process. In Strider’s opinion it was too soon to apply formal authority without evidence of value and
without more widespread support for the PMO concept. He believed that more buy-in was needed
from the functional areas first. One of the chief cultural issues in his mind was how quickly the
functional areas (i.e., the customers of IT) would be willing to adapt to a more formal process. They
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
The AtekPC Project Management Office 308-049
11
would have to be willing to prioritize projects and make the tough choices and tradeoffs. In some
cases, in order to move a project forward, they would have to be willing to help justify additional
resources.
Nelson was working to create buy-in from the functional areas by using his team to provide
mentoring and direct project management for key projects. He recognized that this implementation
strategy was slow work and required considerable patience. For him, the struggle was about creating
and delivering proven success. He expressed the challenge as he saw it:
I can’t call it bottom up (his implementation approach) because we got approval at the top
for us to come in. But it’s like it is almost at the top but not quite there . . . It’s viewed as
bureaucratic, or it’s viewed as having the potential of being bureaucratic. And that’s because of
the industry itself and its time frame—get the products out, get the orders in. One of the things
we’ve heard from the top is ‘just don’t let this project management and process management
slow things down. These are all great things, and we want to see them work; but don’t let them
get in my way.’
As Director of Applications Development, Steinberg was one of the early sponsors of the PMO,
and he saw some progress in breaking through these cultural barriers. When Steinberg first came to
AtekPC, he was given the task of implementing a standard software development methodology. That
early methodology effort failed, in his opinion, because the culture was not right for a disciplined
approach. Now, he was fully supporting this PMO effort, and he brought to it a deep understanding
of the AtekPC culture and its challenges. In his view, only by working with business groups one at a
time could he get their buy-in to the PMO. He explained his approach:
The selling of the PMO outside of IT is an issue. As hard as I’ve tried to push this to get
some visibility outside of this department, I’ve not been able to get any official visibility. What
happened is that we began to get our PM people involved in projects and sent them down to
the users involved in it. Manufacturing was one of the first areas. The person who is the
spokesperson for the IT project in Manufacturing said, “What is this PMO going to do?” When
we told her all about it she jumped on it. The same thing happened in Sales.
It’s not so well received in certain groups, but fortunately it is in some areas . . .
Manufacturing is on board, and Sales is starting to come on board. But I’m not sure that the
other functional areas are totally on board with this concept yet.
With some functional areas in support, the PMO team continued their implementation efforts. As
Nelson remarked, their advancement to date had been in “baby steps.” The frustration of such tedious
progress tempted them to consider an alternative approach –- force the change with top-down
mandates and hired experts. Several managers, including those directly involved with the PMO,
recognized the need for a larger staff of experts to build standards and methods quickly, and they
advocated a rapid, more resource intensive implementation strategy. Such an approach would allow
the PMO to prove its value by actively managing more projects and helping AtekPC to achieve more
consistent and better project performance. IT management was concerned that such an approach
would fail because they couldn’t force radical change on AtekPC. Thus, the senior IT managers
encouraged a slow, incremental strategy that would allow the PMO concept to prove itself with small
victories won through mentoring one project at a time.
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
308-049 The AtekPC Project Management Office
12
Governance
The issue of PMO governance was not widely discussed, but already of some importance. At
present, there were no roadmaps or timelines for its maturation, so there was no way to measure
PMO performance other than through the subjective opinions of those involved. There was a sense
that AtekPC would know whether the PMO was working if the projects were getting done and the
company was getting what it needed. Field acknowledged that there were few measures in place for
projects or the PMO. He explained:
How do we measure ourselves? How does a project organization measure success? One of
the worries has been will project management, because of its bureaucracy, slow things down.
There is still some worry about that. We are trying to say that we will actually speed things up
and get things done quicker with less rework. So how do we measure ourselves to say that we
are succeeding? We haven’t really put those metrics together yet.
Determining how to prove the PMO’s value was a major challenge for Nelson: “Proving its value
is the only way it’s going to work. And this is going to be tough because there hasn’t been any
collection of data before. But even if it is anecdotal, we can show them that . . . we have to be able to
show progress.”
Given this approach to measuring PMO performance through subjective consensus and anecdotal
data, the next governance issue was figuring out to whom was the PMO accountable. For the
moment, it reported to Steinberg as Director of Applications Development which in his opinion was
because of his experience with methodologies and standards. He explained some of the current
governance options:
It currently reports to me in application development, but I really think it should be
elsewhere . . . The key is that I’ve been tapped as the person to get it started. I think at some
point down the road, it more correctly should report somewhere else—if not the CIO,
somewhere else in the organization . . . I think there’s a possibility it could report either to the
senior vice-president, or if we institute this new Planning Office, then maybe in the Planning
Office.
Strider recognized that the current governance model was only temporary, and explained his
views:
The only reason we can get a PMO established is because there is a Planning Office for the
company, and the senior vice-president is committed to a more planned, rigorous, project
management approach. I could not drive this internally within IT unless I had that support . . .
Right now, it reports to the head of Application Development. Steinberg and I have talked that
over time, probably, the PMO will report to me directly. But frankly, I just don’t have time
right now . . . There’s also the Planning Office that doesn’t report to me but to the senior vicepresident and that’s a possibility.
Understanding this close interaction between the new Planning Office and the PMO, Steinberg
shared his over-riding concern about it remaining within IT.
I think as long as it remains an element, a division apart within IT, there will still be this
‘us-them’ kind of a thing, and the feeling that we’re in there to get our way, and it’s our axe to
grind, and it’s to make us look better . . . We’ve done some work with group applications, and
they’ve been successful. People want more of them. So my hope is that we will have enough
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
The AtekPC Project Management Office 308-049
13
breathing room here to get started with the PMO and to show the benefit of it. That will sell it
to other areas and allow it to continue to live.
Deciding How Best to Move Forward
The PC industry was changing, and AtekPC was engaged in dealing with dramatic pressure from
larger competitors such as HP, Dell, and Lenovo. To compete in a changing industry in which
consolidation was occurring, AtekPC had implemented a corporate Planning Office. Recognizing the
role that IT would likely play in enabling AtekPC to respond to the industry pressures, the senior
vice-president had supported the creation of a PMO within IT. The role of the PMO might be
expanded to include non-IT projects if it proved to be successful. At the same time, there was a
possibility that the PMO might fail due to the challenge of implementing such a measured and
disciplined approach to projects in an environment where that was viewed as foreign to the culture.
After all, AtekPC was an organization that was used to people rushing around doing whatever it
took to build and ship products each and every day.
The PMO implementation had already raised several issues, some of which had proven too
controversial to resolve immediately. AtekPC was therefore feeling its way along with the PMO
effort. As they tried to hammer out agreement on basic PMO issues, everyone in the IT organization
was acutely aware of the challenges they faced and the risk associated with failure. Projects were
piling up quickly. Success would depend entirely on their decisions and their efforts, and that was a
cause of worry to each of them.
The traffic was at a standstill as Strider drove along the interstate trying to get out of Metropolis
and home to his family that evening. It gave him time to reflect again about the PMO. He had guided
his management team to this implementation strategy. He had strong convictions that the PMO-light
model was the way to go. He had held back on hiring more full time employees for the PMO. He was
concerned about the many issues that the PMO implementation had already raised. Were small steps
building on small successes going to get the job done fast enough? He thought to himself as he
waited for the traffic to move: “How can I get where we need to go, without violating the culture so
much that it causes a big red flag? . . . I feel that I’ve got to do it the way I’m doing it, rather than load
up a big PMO and say, ’Here’s my PMO.’”
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
308-049 -14-
Exhibit 1 AtekPC Information Technology Organizational Chart
Source: AtekPC.
Lead Analyst
Project Manager
Manufacturing
Systems Manager
Steven Gardner
Workgroup
Communications
Manager
Lead Analyst
Lead Analyst
Lead Analyst
Project Manager
Advanced Systems
Replacement
Project Manager
Director Project
Management Support
Group
Larry Field
Financial Systems
Manager
Chief Information
Officer
John Strider
Director
Technology &
Operations
Director Application
Development
Richard Steinberg
Sales Systems
Manager
PMO Director
Mark Nelson
Lead Analyst
Linda Starr
For the exclusive use of P. JONES, 2020.
This document is authorized for use only by PHIL JONES in 2020.
The AtekPC Project Management Office 308-049
15
Exhibit 2 AtekPC “Idea Form”
IDEA DEVELOPMENT FORM
Section A. (Requestor completes this section)
Requestor Name:
Date Request Submitted:
System Name (if known):
Date needed by:
Project Name:
Section B.
(Reviewer completes this section)
Idea Reviewer:
Date Reviewed :
Project ID:
Approved
Not Approved – Reason for non-approval:
Section C. Work Type (Reviewer completes this section)
Enhancement Emergency Fix
Section D. (Requestor completes this section)
1. Provide a Description (What is it?):
2. Why should we do this? (Explain the business value and select the appropriate benefit type) Explanation :
Benefit Type (more than one type can apply) Estimate if possible
Creates Revenue Estimated annual revenue: ______________
Cost Avoidance Estimated cost avoidance: ______________
Cost Savings Estimated annual savings: ______________
Operational Reliability
Customer Service Enhancement
Quality Improvement
3. Scope (Describe what it includes and excludes.)
4. Deliverables (Report changes, new screen, data entry, etcÖ)
•
5. Impacted Departments / Customers
•
6. Assumptions
•
7. Related projects
•
8. Risk/Impact of not doing project
•
Source: AtekPC.