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 didnt 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 couldnt 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

initiativetoo much, too soon, too fast.

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

alignmentaligning 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 worlds other

PC makers as they grappled with the transition from a growth industry to that of a maturing

industry. Strider explained:

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

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 didnt realize it. They

got everyone together; they talked about what its 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 were through

with that, weve got to get back to doing projects normally. They didnt 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

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 dont have it all figured out. Thats better than thinking you do when you dont. 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 weve only done operational maintenance, and now weve

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 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 Ive 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 standpointregular 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 requesters

side. It helps them think through about usage and all. Why are we going to get savings here?

Whats 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 were

working on.

The enterprise-focused services developed by Nelsons 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 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, were doing in three or four months now because we have put these

practices in place. And thats 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, its four people full-time. . . . Given the speed with which we as a company want

to movewe as an industry need to moveI 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

dont see all of the management moving into this group. Theres kind of a difference of opinion

between me and the PMO at this point about that. Were going to have to find some middle

ground, . . . Im fairly convinced it should be light. That doesnt mean I dont 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 dont 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 elses work to advance his own. Strider struggled with this challenge and the current four. 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 PMs 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 dont literally understand

what the PMO is. They think its sort of a road block and an obstacle to progressa bureaucratic

thing.

Steinbergs 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. Theyre not going to

write code; theyre not going to install servers; theyre not going to meet with users who

understand functional requirements; theyre 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 wasnt 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 chargethe leadfor 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 Ive made

myself in order to create and do the analysis and keeping track and all that. So I thought,

theyre coming in with all these tools, and eventually theyll be teaching us; and eventually we

will be project managers that can stand on our own.

Stars 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 groups 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, and you could borrow that one person for a while. And your project would report to them. I

think its the understanding that they have project managers to which you assign the various

projects throughout the department. For instance, were 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 everybodys

informedthe typical project manager type tasks. . . . As far as project management goes, the

project is her responsibility. Its her job.

In Gardners 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 Gardners 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 isnt just bringing on the project managers and analysts.

Its also the business resources. Today, we have line managers who are working on multiple

projects in addition to their regular jobs, and they cant 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 its 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 dont think theres 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 were

developing well 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 AtekPCs 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.

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 overheadsomething 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

cant 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 cant 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 thats 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 Striders 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 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 cant call it bottom up (his implementation approach) because we got approval at the top

for us to come in. But its like it is almost at the top but not quite there . . . Its viewed as

bureaucratic, or its viewed as having the potential of being bureaucratic. And thats because of

the industry itself and its time frameget the products out, get the orders in. One of the things

weve heard from the top is just dont let this project management and process management

slow things down. These are all great things, and we want to see them work; but dont 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 Ive tried to push this to get

some visibility outside of this department, Ive 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.

Its 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 Im 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 couldnt 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 . 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 havent really put those metrics together yet.

Determining how to prove the PMOs value was a major challenge for Nelson: Proving its value

is the only way its going to work. And this is going to be tough because there hasnt 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 Ive been tapped as the person to get it started. I think at some

point down the road, it more correctly should report somewhere elseif not the CIO,

somewhere else in the organization . . . I think theres 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 dont have time

right now . . . Theres also the Planning Office that doesnt report to me but to the senior vicepresident and thats 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 were in there to get our way, and its our axe to

grind, and its to make us look better . . . Weve done some work with group applications, and

theyve been successful. People want more of them. So my hope is that we will have enough 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 Ive got to do it the way Im doing it, rather than load

up a big PMO and say, Heres my PMO''.

from the above case study:-

Questions to answer in the report are listed below

What is the purpose and mission of a PMO? What are the main challenges and obstacles in implementing a PMO? What structures and governance mechanisms are critical to effective PMO implementation? How much PM is enough PM? How much PMO support is enough PMO support? How would you structure a PMO to ensure long term success and fluidity amongst projects within the company?