Answers to all your queries related to Campus Interviews & Beyond

PMO Organization Models

Early on in PMO history, the Gartner Group identified three PMO models as

  • Project Repository Model ( a low or no value model)
  • Project Coach Model (a tactical model that can provide some value for short time)
  • Enterprise PMO model (a strategic model oriented to central control of all major projects)

There is also a fourth model as

  • Deliver Value Now Model ( a high value strategic model focused on throughput, delivery acceleration and choosing the right projects)

A) Project Repository Model

Serves as a source of information on project methodology and standards. The model assumes the enterprise has embraced a cohesive set of tools for project design, management and reporting. If the PMO becomes perceived as a “tool providing a solution”, the need for the “tool” will diminish over time for various reasons and PMO with it.

B) Project Coach Model

Provides training, mentoring and other help to project managers. In this model, the PMO is far removed from the executive level and will eventually be seen as unnecessary overhead.

C) Enterprise PMO model

Takes over the project management direction and function. The centralized approach usually brings discipline and standardization to project management across the organization. It also brings resistance from functional areas that feel like they have lost control.

D) Deliver Value Now Model (Recommended)

Is a holistic approach. It provides focus on the total project portfolio, linked to the organization goals and assets. It is launched with full executive support. It takes a consultative approach to win over teams and functional managers.

By focusing on the needs of PMO customers as the primary priority, PMO field demands will begin to rise. This will make the beginning of the PMO opportunity it help the organization’s executive meet the goals.


PMOs fail because they do not set out their mission as providing measurable value to their universe of customers. Each and every project manager must see the PMO as a trusted group who is helping them to meet their goals. Functional managers at all levels must  see the PMO as helping resolve resource conflicts and other crisis and getting the project work done faster and better. PMOs that report too low in the organization or PMOs that have an imbalanced steering committee often their focus on timesheets, methodology and other efforts that fail to drive value within the first 60 days.  In short value means completing more projects in less time year after year that contribute directly to the organizations goals. Value means continual improvement in predictability for three parameters-on time, on budget and within scope.

Many technically competent project management offices (PMOs) fail to maximize the value they can provide to their host organizations. Such PMOs-because they often focus only on technology, data, and processes-usually lack effective approaches for engaging stakeholders and managing these relationships. This article examines how organizations can transform their PMOs into components that translate business strategy into competitive advantages as a result of effective stakeholder relationships. In doing so, it discusses the nature and structure of PMOs in relation to supporting an organization’s pursuit of its strategic goals.

Although establishing and operating a project management office (PMO) demands specialized skills and expertise, it is an organization’s maturity level that most significantly impacts its capacity to establish a PMO which enables its project managers to achieve the professional excellence and success executives and clients desire.

The act of collaborating is both an art and a science, one that begins with shared trust and thrives through delegated authority. And yet historically, many companies have isolated their project managers, leaving them to practice without the support and authority they needed to implement projects, to maintain best practices, and to leverage team performance to achieve better results and to accomplish desired outcomes.

The traditional program management office continues to serve the organization well in the planning, tracking, and oversight role of these projects. Act while the opportunity is available! The lesson “late to market is loss of market share” has been well learned. As a result, the focus at the executive level is shifting from “do projects right” to “do projects right now”. This is a perilous attitude. Project mismanagement and an inability to transform the organization will lead to failure. “Do the right project RIGHT” must be the mindset of today’s corporate executive. But in the project management environment, these functions appear to play a more crucial role in realizing the business vision.

Project offices are typically established to formalize and standardize practices, processes and operations; standardized procedures should lead to consistent, repeatable results, and a greater probability of successful projects.


Many PMOs continue to struggle with the measurement process of PMO value. Implementing and improving PMOs are also projects. Much of the confusion is caused from the lack of well-defined value model.

We will focus on measuring the PMO value and how to measure that value in a measurable and easy to apply method through a PMO maturity model.

The PMO maturity model supports for profit and not-for-profit entities alike. Each stage of maturity indicates more value, more alignment between functional areas, more executive awareness and support and greater synchronization between projects, project managers and project teams.

The PMO model comprises of 8 levels of maturity and is measured across 9 knowledge areas of PMBOK® defined by PMI.

Overview of PMO maturity model:

Level 1 – PMO defining value

Level 2 – PMO organized

Level 3 – Searching for delivery value

Level 4 – Portfolio management

Level 5 – Community buy-in

Level 6 – Project teams delivering on schedule

Level 7 – Project teams calibrated w/portfolio

Level 8 – Organization delivering

Level 1 – PMO defining value: In this stage, the PMO is identifying what the current situation is as it begins to develop.

Some of the common characteristics are:

  1. Poor definition of in-scope or out-of-scope items
  2. Resources are allowed to work at their own pace
  3. Project costs are not estimated or tracked
  4. No standard project definition, terminology, scheduling or methodology
  5. Standard reporting processes for project delivery status are not implemented
  6. Projects start late and most finish late because of late start
  7. Resources are sought as tasks begin instead of pre-planned

Level 2 – PMO organized: Focuses on identifying the “As Is” of project delivery.

Some of the common characteristics are:

  1. A scope statement developed by supply-side PM often with IT emphasis
  2. Business partner participation is very limited and weak
  3. Functional requirements are poor and not aligned in value to the business
  4. Projects are managed on milestone reporting and predecessor / successor dependencies are not well known
  5. PMO mentors are available to help project managers determine customer needs and are assigned to the most important strategic projects as  a project management subject matter expert

Level 3 – Searching for delivery value: Brings awareness for the potential for project delivery speed improvements

Some of the common characteristics are:

  1. Functional requirements are better defined and easier translated for development purposes
  2. Regular PM community status meetings raise delivery visibility within the group
  3. Project  financials (plan vs actual) are tracked  monthly at the project level by the project team
  4. Overall fiscal health of  the project portfolio is known to date
  5. Project team members are focused on meeting customer needs that affect organization goals
  6. Project managers are using the PMO as an information source to learn and develop their own project level strategy for project delivery

Level 4 – Portfolio management: Brings more focus on working on right projects, reducing the number of active projects in the system and having greater senior management involvement in the process.

Some of the common characteristics are:

  1. Scope interdepencies between projects are understood among project managers
  2. All important projects are being tracked within project portfolio
  3. Procedures are developed to manage inter-project changes particularly in force ranking, track performance against plan and report on all projects affected assets and strategic objective compliance within the portfolio

Level 5 – Community buy-in: A change in work force attitude has emerged within the  culture. Project teams have an air about them that is fostering positive events.

Some of the common characteristics are:

  1. Executive buy-in and project management community buy-in exits for combined scope of all projects for the planned fiscal year
  2. A Project Management Information System (PMIS) is used throughout the project life cycle
  3. Project management metrics are established which supports quality goals

Level 6 – Project teams delivering on schedule: Brings about improved version in project delivery predictability.

Some of the common characteristics are:

  1. Projects are completing within scope most of the time
  2. Planning process always balances, scope, schedule and resources without overloading the system
  3. All project managers and teams have information in time to take preventive action on project threats and to take advantages of acceleration opportunities
  4. Quality issues preventing on time delivery and documented and addressed

Level 7 – Project teams calibrated with portfolio: In this level, the organization begins to see quantifiable payback in terms of unexpected budget money left over from projects completed earlier than expected.

Some of the common characteristics are:

  1. Project teams are using their delivery knowledge of scope interdepencies between projects to meet or optimize scope requirements
  2. Team based performance process has been implemented
  3. Bad multitasking is visibly reduced
  4. Metrics, procedures and training are used to raise visibility of delivery acceleration opportunities and to decrease delivery threats
  5. The steering committee demands and supports project management methodology from all functional areas

Level 8 – Organization delivering: Nirvana for PMO. By this time, there is no question about the PMO value to the business and to each individual in the workforce.

Some of the common characteristics are:

  1. All the strategic objectives of the organization are achieved in the fiscal year
  2. Over 95% of projects are completing on time worst-cases
  3. Approx 10% of projects are completing early
  4. The organization is delivering more projects without needing to add resources
  5. A process of ongoing improvement is in place, with statistical controls and identification of biggest leverage points for improved quality

PMO maturity is integrated with all other processes and is continually reviewed for  improvements and is enabling more than a 10% ROI, making it even better than plan.

Friends, we all know and agree that defining of any process or functions is easy but implementation is not a smooth road to success. Hence, we have to understand the reasons for failure of such implementations and here I will talk about why does PMO implementation fails and what we can learn from it.

Reasons for PMO implementation Failure:

1. One of the common pre-requisite for a person to be PMO is to be Project Management Professional and have a taste for the financial statistics and also able to present the data in a meaningful way. The data if presented is not used by the management to control their projects, then it is sheer waste. Hence, this may be one of the reason, why PMO implementation fails in an organization.

2. Moreover, there are no lessons learned and analyzed for such failures, because the management thinks it is a waste of time and continuous to do monotonous job and hence the PROJECT CRASH and lands to the ground with everybody in it getting hurt.

Recognizing the need for a PMO:

We need to understand that to avoid such crashing, PMO is also like an airplane traffic controller, who guides each and every project to land successfully to the ground without hurting anyone in the project.

Every leader faces two key project management challenges:

  • How many of our unit’s vital projects can we complete this year?
  • How fast can we complete them?

The PMO is the vehicle to help the executives deliver on their improvement effort goals. In order to meet its goals, every organization launches multiple projects during a fiscal year. Some projects may have dedicated resources that work on only one project at a time. However more commonly we see that some resources are used across many projects. Moreover, they are often assigned multiple projects at the same time.

Project development work requires process and communication. If you’ve worked on a project, you know that often the only constant is change. The changes maybe anything like change in customer requirements, resource availability and detailed schedule. These changes can place the best organized project team in dire jeopardy, leaving the project team to work in high stress situations that arise the delivery risk even higher. When change is frequent within a project, the ability to communicate changes rapidly to project team members, management and other business units can mean the difference between project delivery success and failure. However, communication is just one of several major challenges. Change brings about unplanned activity. Therefore changes are inevitable as it is truly said.

The push to establish a PMO often comes because of the reasons mentioned above. Often PMOs are established to bring order to timely project delivery expectations. Sometimes, they are established as “Mentoring PMO”, to facilitate process standardization such as consistent methodologies. In many organizations, the PMO takes on an authoritarian approach as a “Process Cop PMO”, to try to force everyone to use common processes. In other organization, PMOs are established as a “Palace Guarding PMO” to simply protect the organization from out of control and highly visible projects.

Generally speaking, PMOs established with any of these purposes often fail over time. Surely the PMO initially appears to have an impact. PMO sponsors are usually satisfied early on. However strange thing begins to occur. The organization reacts in a hostile manner to bring balance back itself as a functional unit, a project and a resource.

A PMO whose main value is a standard methodology will find its value eroded over time. Standard methodology is just one small part of total value proposition of a PMO. Once imbedded, project teams and business unit leaders will question the need for a PMO, if no other value drivers are in place.

PMOs can have the “right people”, the “right data” and the “right tools” but produce “wrong results”. If PMO does not have the correct charter, it will most certainly fail over time


The “right” people include a balance between people from the supply side and people from the market side of organization. PMO must be able to market its message in order to get the collaboration of people who do not report to PMO. This requires skills in marketing and communications. Finally the PMO should cover multiple disciplines. Every functional area that is involved in projects should feel that someone in the PMO represents their best interests.


If the PMO begins business without a marketing plan to gain strong buy-in on tool usage from most, if not all functional units, the PMO will have begun its own death march. The KISS (Keep It Simple, Stupid) formula works best at the beginning. The maturity of organization with respect to project management skills has a large impact on the acceptance by user community of Enterprise Project Management (EPM) tools and processes often in organization with low project management maturity, sophisticated tools meet heavy resistance. This is especially true with functional units that are normally autonomous to the enterprise in how they manage their work.

Thus in a PMO strategy, PMO must understand functional unit behavior characteristics and their needs. The PMO must determine what is in it for each functional unit. A PMO that has solid knowledge of the different politics in play and drivers for each functional unit will be able to establish itself more quickly as the ‘best friend’ of enterprise. Such a PMO can avoid falling into the trap of becoming a ‘process cop’.


In every type of organization, functional units compete with one another everyday. The issue is often scarce resources or different views of how and where to change the organization. When it comes to scarce resources, functional units often view themselves as stand-alone. To survive, they must compete or risk falling to the last spot and missing their fiscal year objectives. The challenge for PMO is to assist these units to be collectively better at project delivery. In order to improve, project delivery must be measured. The measurement process is often accomplished through project status reporting from all identified projects that are key to the business.

The PMO can be very effective by making sure that the project management methodology or tools provide timely information. If PMO can help the project managers to identify problems early corrective actions can be taken in small doses. This provides less stress to project teams and also to the steering committee members. Remember that the projects are more likely to be cancelled if the corrective plan requires more changes. Also, the more often this happens, the greater the likelihood and the steering committee will question what the PMO was doing all this time.


Why PMO implementation fails?

  1. PMO did not define its value proposition

The PMO is in business to help the organization meet its goals. Almost anything else is a waste of effort that will be realized sooner or later. For e.g. it may take weeks or even months to force project managers and their teams to use a methodology that PMO is pushing. PMOs should strive to demonstrate tangible value in the first 3 months in terms of improving project delivery speed. The political pressure to deliver value will increase month by month. At some point, PMO will run out of time.

  1. PMO is not perceived as impacting project delivery abilities

PMOs that are focused primarily as administrative score-keepers, information providers or process developers have a declining curve.

These PMOs start out by fulfilling a critical senior management need for information. The organization units and PMs receiving negative press without tangible help from the PMO, resist the PMO. This resistance becomes more serious overtime and is often a defensive reaction to PMO. When the combined resistance of a few functional units exceeds the perceived value of the PMO, PMO will cease to exist- it has no tangible value to prove its worth.

  1. PMO is seen as threat – most often too authorative

Many established PMOs operate in this manner. There are some environments where strict adherence to authority works well. For e.g. business that gain revenue through the military or government agencies are often required to follow strict project delivery guidelines such as “Earned Value” techniques.

These businesses are measured and compensated on the Earned Value metrics as a percent of available compensation for a project phase. So, if the business achieved 90% of Earned value metrics for a project phase, it would receive 90% of the available compensation for that project phase. For some firms operating this way, their survival may depend on cash flow and the careful tracking and progress associated with it. In cases of survival, authoritarianism works. Authoritarian PMOs operating in these environments can sustain themselves, because there is a clear value proposition.

  1. PMO is too low in the management reporting structure

PMOs that are established in this mode are usually found in the supply side of the business-normally IT. This type of PMO is sometimes established as a defensive measure against pressure from other groups. Often they are catching the blames for projects failing to meet requested timelines and promised quality levels.

This type of PMO exists near or below “radar” detection. This means that PMO often spends most of its time collecting data on IT project initiatives. The CIO/ management needs the data to survive and certainly wants to improve project management results.

  1. PMO does not have any buy-in from the senior functional managers

PMOs that do not cultivate the buy-in from the senior leadership of their organization or of other organization that are customers of senior leadership are making a serious mistake.

PMO that takes an initiatives that excludes or does not explicitly include the interest of senior managers across functional areas puts the project teams in a cross fire. The project teams must now choose priorities between the PMO initiative and the project managers initiative. Who do you think the project teams will listen to first and last?

  1. Project Management Overhead – bad PMO acronym

Teams may see PMO initiatives as unnecessary overhead.

  1. PMO is micromanaging – trying to control every project directly

According to Dr. Harold Kerzner, “If the project managers report to the PMO, then PMO effectively micromanages projects and the result may be a loss of strategic direction for the firm. For strategic efforts, it may be advisable for the project managers to report to the strategic PMO on a part time basis.”

According to Gerald and Steven, “Project managers should have internship within the PMO to understand its purpose, functions and methods. However, the internship, generally speaking, should be in performing a PMO role, not a project management role.”

Concluding this section, I will say that we should not ignore the importance of PMO and build the PMO team with the help of some PMO consultants and definitely it will give you results.

Friends, If you have any queries regarding PMO then please leave your comment and I will reply to you. Also, if you need consultancy for PMO implementation in your organization, then you can contact me or leave your comment.

Friends, In our first series we have talked about the functions of PMO and today we will talk about inputs and outputs of  PMO.

B) Inputs and Outputs to PMO

Every PMO member produces and receives information in various context, content and forms in interaction with the project management stakeholders. Some of the common inputs and outputs are outlined below:


  1. Project Status reports
  2. Project schedules
  3. Issues reports
  4. Risk reports
  5. Timesheet data
  6. PMO help desk calls (incoming)
  7. Troubled projects
  8. Training
  9. Strategic objectives for fiscal year
  10. List of Business assets


  1. Project Portfolio (e.g. PO calls trade summary report)
  2. Resource portfolio (e.g. Headcount report)
  3. Asset Portfolio
  4. Strategic objectives portfolio
  5. Integrated portfolio
  6. Operations planning and forecasting report(Monthly)
  7. Training
  8. Resource Assignments report
  9. Prioritization worksheet

Developing and reporting and data collection and using it to provide meaningful information to all stakeholders raises the value proposition of your PMO to its customers.

Next we will talk about why does PMO implementation fails.

Today I will talk about the PMO – Project Management Office, definitions and reason for having PMO in an organizations.

First Let us talk about what you mean by Project Management.

Project management in a broader context includes program management, portfolio management and project management office. Though, project management office has its own different forms; some called it project office, some as program office. But whatever it may be called as, the bottom line is to optimize the utilization of the resources across the projects in an organization, project planning, monitoring and control and give value addition to avoid falling of the projects in the pothole.

We’ve also  seen that the project fails not because of the quality, but because of the project management in true sense.  The idea to present this article, is to create the awareness of the PMO functions to the Project Team, Stakeholders involved in the projects. In India, this role is still at its infancy stage and for successful implementation of PMO; we need to first understand, what are its functions and value provided to the organization as a whole.

There are 6 series in which I will be presenting the article and are outlined below:

1. PMO functions

2. Inputs and Outputs to PMO

3. Why do PMO implementation fails?

4. PMO maturity models

5. PMO organization models

6. Suggestions for the successful implementation of PMO in an organization

Apart from the above series, I’ll be adding the topics which are indirectly related to this article and also sharing some templates/formats used during my tenure as PMO in the organization.

The article will guide you in which areas of PMO, it can be improved and also the responsibility can be made more concise and the measurements for measuring the values of the implementation of PMO.

I)   PMO functions and inputs and outputs to PMO

Project managers execute their projects in isolation without clear understanding of the overall organization goals and the customer requirements (senior managements). There is a disconnect between the project goals and the organization goals. To bridge this gap, PMO plays a very important role and helping project stakeholders to align with the organization goals and the customer requirements.

A) PMO Functions:

  • Oversees the management of projects, programs or a combination of both
  • Focuses on coordinated planning, prioritization and execution of projects and subprojects that are tied to parent organization’s or client’s overall business objectives
  • Can receive delegated authority to act as an integral stakeholder and a key decision-maker during the initiation stage of each project
  • Can have authority to make recommendations or can terminate projects to keep the business objectives consistent
  • Can be involved in the selection, management and redeployment, if necessary, of shared project personnel and where possible, dedicated project personnel
  • Shared and coordinated resources across all projects administered by PMO
  • Identification and development of project management methodology, best practices and standards
  • Clearing house and management for project policies, procedures , template and other shared documentation
  • Centralized configuration management for all projects administered by PMO
  • Central office for operation and management of project tools, such as enterprise-wide project management software
  • Central coordination of communication management across projects
  • A mentoring platform for project managers
  • Central monitoring of all PMO project timelines and budgets, usually at the enterprise level
  • Coordination of overall project quality, standards between the project manager and any internal or external quality personnel or standards organization
  • Contracting, financial control and representation of all functional areas

Choosing a career


Choosing a career is always a difficult choice and time consuming. It’s like you are standing in a cross-road and don’t know which road will lead you to your destination.

Choosing Career

Choices start from the day you joined your graduation course till you complete it. During this day, you come across various options to select and if you keep your mind focused and work towards it, then you can reach your destination and if you decide it after completing your graduation then it might be too late.

There are many factors that affects to choose proper career path, which I will share it in my next article.

Conclude: It is never too late to decide on your career, but whatever you choose, do it with determination, passion, discipline and hardwork.

Next: Factors affecting the career path.

Web Engineering


First we need to understand the difference between Software Engineering (SWE) and Web Engineering (WEBE).

Although both of them follows the disciplined approach to develop, deploy and maintained the applications; the basic difference is that the requirements (Scope) of web projects is different from the software projects. Software projects have the various models like Waterfall, Spiral, Incremental, etc., but there is no defined models for Web Applications project, as the requirements are dynamic (not fixed).  For simplicity we can define model for web projects as PDCA model. (P)lan, (D)o, (C)heck and (A)ct. In the planning stage, you ‘Plan’ as what are the requirements, concept, planning, costing, timeline and get the approval from the customer before starting the project. Next comes the ‘Do’ – which is defined as “How the concept has to be designed and developed”. Here the prototype (models base on blueprint) has to be build and then get it reviewed from the customer. Based on his feedbacks, action has to be taken.

PDCA cycle is the base of all the models.

Secondly, WEBE is more complex then SWE, as former is dependent on the various types of browsers, OS, and servers like Web server, application servers.


WEB Apps is more complex then SW Apps, in the sense that to build such applications, you have to know at least HTML, Database, Server side scripting language, Java scripts and Photoshop for editing images.

Next we will talk about the characteristics and attributes of Web Apps.

%d bloggers like this: