Is Project Management a commodity or a craft?

Some days back I visited the Regional Transport Office of Bangalore North district, more commonly called RTO office. For those unfamiliar about my part of the world, RTO issues driving license if you pass their written test and driving test.

Bangalore, and I guess many of the cities in India, is teeming with driving schools. As the name would suggest, these folks teach you how to drive. In Bangalore and again, probably in other Indian cities, driving schools have, in a way, exceeded their brief. They also help you get the driving license. It is not uncommon to see a driving school agent chaperoning young would-be drivers around the RTO offices, filling up forms on their behalf, making them rehearse the driving rules and in general making them feel at-ease. With the passage of time, this has been stretched to such an extent that many would-be drivers go to a driving school, not to learn driving but to get a driving license!

Does this sound familiar? Rather very familiar? Isn’t this very similar to what is happening of PM education? You don’t see much of PM education happening around except maybe people getting coached to pass an exam. Traditional colleges and institutes do not offer PM as a course except maybe as an elective. The ones that do offer are not necessarily aligned to the practice.  Add to it the growth in number of PMI^® registered education providers who at the best provide only PMP^® exam prep programs.

As per PMI^®’s website an R.E.P. program has been designed to enhance the ongoing professional development of PMI^®’s members, those credentialed through PMI^® and others in the project management profession. But as time passed, a good number of them are now merely PMP^® exam coaching centers, with more following the suit. Some of them guarantee you passing the examination. A savvier few would even return your money back if you do not pass. Being a project management mentor, I have got requests for help in filling up in the PMP^® application from aspirants. (I feel like screaming at such requests!)

The conflict between credential being a commodity versus it being recognition of a craft (A craft is a skill, especially involving practical arts – Wikipedia) is a much debated and discussed topic in multiple forums. The jury is still out on this decision. But in the meanwhile, someone has to take serious look at PM education.

Coming back to my story, I had gone to the RTO for my daughter’s driving license. Even if she gets it, I would be really wary of handing her my car keys. I hope the powers-that-be in the industry do not share such apprehensions about a PMP^® certified project manager!

Eager to know if you would agree or disagree with me. Please do write.

Knowing your customer’s business.

I drive around in a Mahindra Scorpio shown here. It gives me unfair advantage on the roads in Bangalore where the right of way is based on the size of the vehicle! Lest you think so, this blog is not about the comforts of Scorpio or the horror called Bangalore traffic.

It so happened, some days back I rode in this SUV with my friend who is a mechanical engineer. As he got down, he looked back at the vehicle for a moment and said “Tell you what, my team designed the gear box for this SUV. Mahindra chose the design from a couple of prototypes we had made. Today, all the Scorpios in the country run on my gear box design.” Otherwise very restrained, my friend had to struggle to hide his sense of pride when he said that.

As you would have guessed, my friend does not work for Mahindra but his organization provides services to them, typically as projects.

This conversation set me into thinking. How many of us in our projects appreciate why the customer has entrusted us with the project? Or how many of us know where the project fits into the proverbial larger picture?

If you ask me, my answer would be “Not many”. Some if not most of, projects run on the classical iron triangle of scope, schedule and cost. The team gets the project with the requirements. It is executed hopefully in schedule and within costs and delivered back to the customer. Then you return to your home team and get reallocated to the next project in line. Taking further liberty, I would like to say that the PM is worried about on-time delivery and the team about sale-ability of the skills acquired through the project. And the twain sometime does not meet.

The basic question is should the project manager and the team know the customer’s business? Is this a nice to know or badly needed piece of information? Probably, the later.

Let me paint a few scenarios.

Is your project a part of mature well proven product? If yes, you can expect clear requirements but the customer would expect quick turn-around time.

Or, may be your project is a part of a brand new product/platform. You can expect uncertainty in requirements. (I am sure my friend in the above story would have faced a lot of this.) Don’t fret over frequent requirement changes.

Or is the customer meeting some legal compliance through your project. Expect very clear requirements but don’t get frustrated by thorough verification with a magnifying glass, almost nitpicking.

So, knowing the larger picture does help you in managing your project better.

If you become invisible and get into some of the project meetings, you will get to hear a lot “we and they” talk (or should I say “us versus them”, anyway). Like “They always change requirements”, “They do not know what they want”, “We are already overworked” etc. If you know the customer’s business, you will have less reason for the “we and they” talk.

I want to end this blog on a philosophical note. Inherent in the human heart is the desire to be of some use to somebody and to leave a legacy behind. Knowing the customer’s business fulfills this desire. Like “thousands of vehicles ply on the bridge that I worked on” or “every time you talk on this phone, my compression software kicks in”.  How do these statements compare with “we completed the project within 10% schedule variance but got beaten on cost escalation of 50%”?

Need I say more.  As usual, eager to hear your views and experiences. You could also vote at http://polls.linkedin.com/poll-results/95180/gamah.

Observations on the practice of estimation

I had heard this story long time back. There was this gentleman visiting a historical fort situated in a small village. He was walking his way to the fort but unaware of how far the place was. On the way, he saw an old man sitting on the steps of his house soaking the morning sun and asked him “Baba (loose translation: the revered), how long will it take to reach the fort?” The old man remained silent. Assuming the old man to be hard of hearing, the visitor continued his walk. In about two minutes, the old man called him back and told that it might take him forty minutes. Looking at the nonplussed and almost angry expression on the visitor’s face, the old man added “Son, unless I know your pace, how would I be sure of the time you would take?”

I wish the many of us in the project management community had the same patience and wisdom which the old man had in this story, when it comes to estimating and scheduling.

Through this blog I wanted to bring out some prevalent mistakes in estimation and scheduling.

Inherent inaccuracy: All the project managers (and their supervisors and customers) know that by its very definition every project is unique. The very first slide in any project management training course would say this. But probably this realization is only at the intellectual level. None probably wants to accept the fact that along with uniqueness comes uncertainty which in turn leads to inaccuracy in estimation. Moreover, this inaccuracy cannot be wished away till you are actually done with all the activities.

Single value certain estimates: Given the inaccuracy, shouldn’t the estimates have a range. Say 20 staff days plus minus 5. Or 10 staff days at 10% accuracy. But usually there is no range specified. You get to see only single and certain values.

Two, all the work elements get the same treatment. There is no distinction made on the uncertainty of the work element and thereby higher or lower tolerances in the estimates.

Same productivity for all resources: When resources are allocated to work elements it is assumed that all the resources have the same productivity. This simplifies duration estimation to division of work estimation by the number of resources. But unless the resource is a machine, you cannot assume same productivity. In fact, human beings are notorious for having different productivity at different times in the project. Needless to add, there are differences in productivity across humans too.

Progressive elaboration not considered: As project progresses, accuracy of the estimates is expected to improve. During the concept phase there would be a wide spread say -50% to +75%. During the design phase the spread would narrow further to say -35% to +50%. This implies that the project schedule gets re-baselined at the start of every phase if not more frequently. But this rarely happens. Once a schedule is base lined at concept stage, it is cast in stone. No re-estimation, no base lining.

Single project finish date: For all the reasons mentioned till now, should not schedule show the project finish date as a date with a range. Say 14-Aug-2010 plus minus 5 days.

But this is rarely the case.

Variations not anticipated: All schedules depict interconnected activities. Variation in one activity has a cascading impact on the schedule. Variation in a dependency outside the scope of your project may also impact your schedule. This is again a well known fact, which largely gets ignored. There is an entire new approach to scheduling called Critical Chain Project Management (Goldratt) which takes care of statistical variations and interdependencies. Even without buying the add-ons for CCPM to their existing scheduling software, project managers can use the concepts of feed buffer and project buffer put under the control of the project manager. But this is rarely done.

No Plan B: Most of the projects have foreseen risks. There is an elaborate risk register containing risk description, mitigation plan, owner etc. But when it comes to plan B, project managers behave like the proverbial ostrich with its head buried in sand. Foreseen risks with high exposure should prompt the project manager to be ready with plan B which would control the damage done by the risk. But one rarely gets to see plan B. Most of the contingency plans talk of communication and escalation like “inform the management” or “inform the customer” in place of a plan B.

So much said and done in the practice of estimations, I will be eager to know your view and experience regarding this topic.

An effective IT PMO can deliver breakthrough results in most PM areas including increased throughput, speed & reliability, significant reduction in resource burn-out, higher productivity, leading to high benefit/ cost ratios for IT investments.

Long before Hrithik Roshan[1] became their brand ambassador and set hearts “Dhak, Dhak, Go”, Hero Honda used to run an advertising campaign – “Fill it, shut it, forget it”. They were referring to the fuel economy of their bike which was claimed as 80 kilometres per litre. That’s why the line “Fill it …”

This popular ad-line popped up in my mind from nowhere, when a close colleague remarked that his project just goes on and on and on.  I began to wonder if the Hero Honda tag line “Fill it …” applied to project management too. I see more people looking at project management as a template filling game. The biggest and most talked about template we fill up is the risk management template. Fill it, save and close it and forget it seems to the practice of risk management.

My observation has been that using standard checklist people do prepare a list of risk or a risk register as described in PMBOK.  But the question is, do we move beyond risk identification and manage risks at all?  So in-spite of all the great intent with which register and plans are prepared, projects continue to fail.  In my view this is perhaps due to two problems

One, the risk register is not integrated with the rest of the project plan.

Two, the risk register remains a well intentioned document but there is hardly any follow up or in the PMBOK parlance, monitoring and control, of risks.

Problem one, is largely an issue of integrated planning. Revisiting the plan taking the risk as inputs is an area that needs improvement. It’s a good practice to show significant risk mitigation steps in the schedule as activities. This ensures that the mitigation plans have an owner and a date.

For example, if the lack of expertise in technology is identified as a risk condition, the corresponding mitigation response would be training the team. One or multiple activities related to training should be there in the project schedule. Taking the same example further, if this training involves hiring a vendor’s services, one should allocate a cost to this which in all probability may consume the reserves or contingency fund.

It is also possible that training once conducted, may not reduce the risk exposure and one will now need a contingency plan or plan B to reduce the impact of this risk to the objectives. For example, hiring expert services on short term contract could be your plan B.

Problem two is the ongoing monitoring and controlling of risk register. It is not sufficient that risks be documented during planning alone. The on-going effort and not just intent to monitor and control, is critical and not doing this is as good no risk management at all.  Remember a risk never closes completely, it just retires. At the same time, a new risk could be just lurking around the corner.

Apart from this, it is possible that the risk exposure of active risks changes that in turn may impact the overall project objective.

Identifying risk triggers is not only useful for monitoring but also assists the manager in defining the appropriate mitigation steps. Risk trigger plays an important role in alerting the manager if a risk is likely to occur. If you are not watching out for the trigger and looking at the actual risk event instead, you may not be left with much leeway to act.

Like they say, chance only favors a prepared mind, just filling up the risk register template and shutting it is not good enough or else we forget about project success.

The maturity of business organizations when it comes to management of IT projects is an area of concern for many CIOs. CIOs lack the visibility they need into project performance, and do not know the magnitude of project delays or the reasons for these delays. Most IT projects fail or are abandoned half-way not due to technical reasons, but largely because of management issues which start from the project selection process itself. There is a need for all to understand that management of IT projects as a service provider (an IT consulting and services company) is very different from managing an IT project as a business organization.

One of the key differences is the approach towards management of IT projects. While the user organization focuses more on the project’s outcome, the service provider’s focus is on project delivery to specifications. The distinction between these two from a project management perspective is not clear, nor is it clarified by industry associations or proponents of project management.
 
There is a need to look at the entire project lifecycle from a business perspective for effective management of IT projects. Aligning the project to business objectives and defining the project’s success criteria early in the lifecycle is a critical aspect. You should look at the success criteria beyond just the efficiency metrics of being on time and within budget. In fact, these are success criteria for the consulting, vendor and contractor community. The user organization should focus more on the business benefits, and not on efficiency of project execution. We are not suggesting that efficiency metrics be ignored, but that they are the responsibility of the contractor (or consultant), and that their impact on the business needs to be measured and controlled.

There is a clear need to distinguish between the various approaches adopted by business organizations or user organizations of IT when it comes to management of IT projects. Moving to a program management process approach could perhaps assist the CIOs and IT managers to appreciate this difference and improve success. Given that most projects have a business case, once the implementation is done, it is important to check whether you have achieved the business objectives. This approach is generally not followed by Indian organizations, so CIOs need to focus on this.

IT project management has moved from being a tactical discipline, and now involves the integrated discipline of program and portfolio management. There is a need to make the IT leaders, the CIOs, aware about this. The use of the traditional development lifecycles (such as SDLC) approach to the management of IT projects needs to change, at least for the user organization.

Current research indicates that more than 50% of PMOs close down as quickly as they are initiated.

They fail to deliver the expected value and are seen as an unnecessary cost overhead by organizations, especially in today’s challenging business and economic environment. In several IT organizations, my direct experience has been that the CIO is getting increasing caught in a tight balancing act between operational and strategic responsibilities. Conflicts arise out of a dual focus on administrative and informational oversight of project investment and performance, and on justifying the PMO investments and the time it takes to deliver value. The question I find each CIO really asking is – how do I get my PMO to create significant and demonstrable business value, and fast?

There is considerable discussion today about what building an effective PMO is about – managing projects, programs or portfolios? (Download a White Paper on this subject). A general thread I see running through IT organizations that have been effective in achieving great results in this area is that their PMOs are invariably focused on Portfolio Management.

While designing PM performance metrics and dashboards is important, I believe that a focus on Portfolio Management drives home the need to understand the decision-making mechanism, which helps in creating governance and assurance processes, backed by relevant and timely information. This critically ensures that IT is directly aligned to business objectives.

An effective IT PMO can deliver breakthrough results in most PM areas including increased throughput, speed & reliability, significant reduction in resource burn-out, higher productivity, leading to high benefit/ cost ratios for IT investments.

In one ongoing engagement, where i2m operates as a PMO Managed Services Provider for a large financial services organization, we have been able to support the IT team, to achieve near 100% improvement in project throughput, speed, visibility and reliability, a 5-fold increase in number of projects completing in time, an increase in objective project selection to 75%, and an IT cost to benefit ratio of 1:20. (See related Case Video and or download the Case Study).

We invite CIOs, Project Managers and others working in this area, to share similar or differing experiences.

Separating the best from the rest!

Are you involved in evaluating project management talent for your organization? If the answer is yes, then you are sure to have grappled with the problem of outlining the ingredients that go into determining that a project manager is indeed capable, competent and a professional; and then going a step further, taking a call on which project managers are the cream of the lot!

Across the industry, many others are in the same boat. So, we decided to talk to a number of CxOs, portfolio managers and HR professionals from around the world, to get a handle on what exactly goes into choosing the right project managers. While certification requirements have become de rigour, and assessment of core PM competencies is critical, most of our respondents agree that these alone only take you halfway to your objective. Therefore, our focus while writing this article was more on the qualitative indicators as opposed to developing a rigorous assessment model.

What emerged was an illuminating Competence Checklist that goes a long way into ensuring that evaluation errors are minimized and capability recognized. And then there are those traits that the select few possess to scale the summit of project management excellence and be pronounced as The Best.

The Competence Checklist

Here is a list of the 12 most agreed-upon qualitative aspects and also sample evaluation strategies, which will help you to assess a prospective project manager’s competence on each aspect. Please note that these are in no particular order but that each of these has been recognized by industry insiders are being crucial to selecting the right person for a project management role.

1. Effective communication skills
Sample Evaluation Strategy
Ask the candidate to explain some aspect of previous work so that you get a better understanding
This will give you a flavour of her ability to communicate and explain complex subjects in lucid manner

2. An understanding of project management lingo
Sample Evaluation Strategy
Ask about the most important project she has managed and how she went about it
This will provide you with the candidate’s comfort with PM language and slang (such as Change Requests, Charter, EVA, etc.)

3. Ability to take challenges head-on and come through successfully
Sample Evaluation Strategy
Ask about how the candidate applied her experience to pull a project out of trouble
The answer should give you the necessary confidence to judge whether the necessary experience exists. A little probing can also bring out the depth of the candidate’s involvement.

4. Ability to deliver on desired outcomes
Sample Evaluation Strategy
Talk to stakeholders who had a major stake in the candidate’s past projects
This is a form of reference checking, but more specific.

5. Self-learning propensity

Sample Evaluation Strategy
Ask about learning from failed/ troubled projects
This will give you an insight into the candidate’s ability to recognize and learn from mistakes and also to accept and use feedback to improve

6. Confidence to Lead
Sample Evaluation Strategy
Ask about specific project and how she led her team and managed stakeholder relationships (internal and external) to achieve the results
This will give you an insight into the candidate’s confidence, role clarity, leadership style, ability to motivate and manage conflicts and stakeholder expectation management

7. Customer Centricity
Sample Evaluation Strategy
Ask about her experiences with customers and the problems she may have faced in interacting with them
This will give you an insight into the candidate’s focus (or lack of focus) on customer requirements and feedback.

8. Ability to take calculated risks
Sample Evaluation Strategy
Ask about a particular instance of how she handled a situation where there were potential time and/ or cost overruns

9. Ability to Innovate
Sample Evaluation Strategy
Ask about specific instances of a long term project where a change of approach during the execution led to better results over time

10. Productivity Focus
Sample Evaluation Strategy
Ask the PM for previous project plans, scope and planning reports, Gate Review presentations, etc.

11. Ability to align to organizational/ project contexts
Sample Evaluation Strategy
Ask the candidate about his experience with different types of projects and elaborate on the unique aspects

This should give you an understanding of how she adapts to the context in which he/she has to deliver (organization, environment, technology, industry).

12. Ability to get the ‘right decisions’ from stakeholders
Sample Evaluation Strategy
Ask about a specific situation where the candidate used the power of information to elicit the right decision from stakeholders on a contentious issue

The Best

Here are the six unique traits that differentiate the best from the rest (Source: Andy Crowe, Alpha Project Managers). These are traits of project managers who have been rated “The Best” within their organizations and peer groups.

1. They just love their jobs as a PM

Indicator: They view their jobs as a career and seek education and development opportunities on their own

2. They believe that they have more authority than their counterparts. Even if something is not within their sphere of responsibility, they seek to influence the outcome without formal authority. As Tom Peters aptly puts it “Nobody gives you power, you just take it.”

Indicator: They believe and value their role as a PM and know as well as demonstrate that their role is critical to success

3. They are not overwhelmed by multiple tasks, and have a mechanism to maintain their focus and to prioritize their work and day

Indicator: They receive fewer project emails that their counterparts and not glued to their PDAs during meetings.  Also they log less time spent in project meetings.

4. They accurately handle their communication effectiveness

Indicator: They probe communication expectation of stakeholders, articulate and summarize their understanding and validate it with the stakeholders either verbally or in writing.  They adhere to their communication schedule stringently.

5. They balance the relationship and conflicts effectively

Indicator: They build informal relationships and networks and separate the person from the problem when a conflict arises. They also confront the conflicts early on and do not swipe them under the carpet.

6. They align the stakeholders to the objectives of the project

Indicator: They speak about not just the project objectives but the business/organization goals and translate their projects’ status to business performance numbers.

Read a whitepaper on how to develop a competency development framework for assessing project managers

Changing the looking glass affects how we experience reality and the same holds true while managing projects–project reality continues to be stubbornly affected by blurry assumptions and misaligned goals. Even in the age of program management, selecting the right portfolio of projects continues to be an individual driven process—a process which is largely based on “gut feeling”.

Many organizations today are implementing a strategy formation process with a clear focus on defining metrics for success.  But the challenge lies in translating this into selection of investments and choice of projects to achieve the goals.  Project and especially Program managers make an important contribution to this process.  Given their delivery and execution background, these professionals rely on their problem solving capabilities to meet these challenges. They use the problem solving approach in the context of defining objectives for building effective metrics to demonstrate success.

Here’s how this approach works: problem solving focuses on eliminating undesirable results.  Its starts with identification of gaps—this means that we tend to concentrate on what is not happening. For example if the project has achieved 85% of the objective, the focus of the manager would be on the 15% missed.  So focusing on closing gaps becomes a full time business and if one cannot identify a gap and demonstrate the negative consequence of not filling it, then the manager is unlikely to succeed.

The measure of all things

There is a time honored expression that in management what gets measured gets done.  But the challenge is in ensuring what you measure is aligned to objective that endeavor is trying to achieve.  What is the use if you are measuring efficiency of execution when the goal is to achieve a strategic benefit?  Maybe we measure the things we can and not the things we should. Obviously we do this to achieve results that are perceived to be linked to success.  When was the last time your performance reports actually encouraged you and your team to improve performance except working more hours at work?

But this is more evidence of uncreative thinking which blurs the complexity behind the decision making process. Moreover, it leads to an avoidance mechanism (commonly known as risk aversion) that has a major influence on the type and quality of questions asked in the goal-question-metric process.

The Goal-Question-Metric Process

Basili et.al. offers a creative thought process for designing metrics by asking fundamental questions about the goals. The first step is to split the goal into its discernable component parts. These are purpose, issue, object and viewpoint.
Here’s an example:

Next is to identify underlying questions relative to the goal.  In this instance the question might be;
How many agents (variable cost) can each manager (fixed cost) manage and how can we increase the number of agents a manager can manage?  Answering the question points to the appropriate metric, such as span of control of manager (no. of agents per manager)

Based on the above goal-question-metric process the strategy becomes clearly defined in order to meet the metric, answer the question and achieve the goal.  In the process it becomes obvious which project investment will be necessary to execute the strategy. To illustrate:

If the goal remains the same and the question changes, the metric changes and project investment will change too:

Example:

So we see how the question that underlies the goal significantly affects the way metrics are constructed, how strategy is formulated and investments that are the results.  These investments are projects to be implemented.  So it should come as no surprise that after a successful project execution, benefits are still to be seen.

One way of looking at this problem is through AI—not artificial intelligence—but Appreciative Inquiry. It’s an organizational development process, a discipline, and a philosophy that helps reframe our old dilemmas anew.

What is Appreciative Inquiry (AI)

Understanding the basis of Appreciative Inquiry allows us to better contrast the goal-question-metric process against the conventional problem solving approach. Applied coherently, AI offers a greater insight into organizational goals and improves chances of success by taking the corporate spirit as a whole. In practice, it involves AI involves “asking questions that strengthen a system’s capacity to apprehend, anticipate, and heighten positive potential”.

When we start thinking about organizations in terms of living systems, then our paths of inquiry can involve

“the systematic discovery of what gives “life” to a living system when it is most alive, most effective, and most constructively capable in economic, ecological, and human terms.”

So the focus should not be on asking about what is not working but rather what is working as well and if we do more of what is working well then we will see more benefits.  This is the Appreciative Inquiry process and is a critical skill that capitalizes on what works to create a better set of results.

How AI Works

There is a cycle of 4 processes that Appreciative Inquiry utilizes:

1. DISCOVER: The identification of organizational processes that work well.
2. DREAM: The envisioning of processes that would work well in the future.
3. DESIGN: Planning and prioritizing processes that would work well.
4. DESTINY (or DELIVER): The implementation (execution) of the proposed design

When compared to conventional problem solving approaches, AI offers the kind of positive orientation and leverage that creates a whole new set of possibilities in terms of goal clarity and better choice of questions, leading to better metric design, clearer strategies and more appropriate project investments. AI enables organizations to focus on creating exceptional performance which occurs because its core strengths (people and organizational assets) are aligned.

Reference and adapted from:

Executing your strategy: How to break it down and Get it Done.
Mark Morgan, Raymond Levitt, and William Malek, Harvard Business School Press.
http://en.wikipedia.org/wiki/Appreciative_inquiry
You can find out more about Appreciative inquiry at http://centerforappreciativeinquiry.net/

On a rainy day this July, I got a call from a friend of mine. I was a bit surprised to hear from him back then and could barely comprehend the situation he was describing on the phone. What I ultimately managed to gather was that he’s busy fitting himself a new CxO level role these days and needs to put the final touches to his presentation to the corporate planning head. The question he posed was whether he should recommend a significant budget increase in his area of responsibility, or manage within the existing limited budgets. The real issue in his mind was how he could assure optimum alignment of spending with the direction of his organization. Moreover, if he acts either way, how can be sure of delivering the value he promised the organization on the basis of his strategic initiatives?

This question is all too familiar and the concerns are real and legitimate. Indian industries facing a shaky economy and fierce competition, find themselves in a position where they have to innovate for their survival and growth. Nearly every large organization across the globe is feeling the impact of this internal misalignment of priorities. In a nutshell, each company is struggling control its own catfish – its portfolio of projects (F. Warren McFarlan, 2003).

In this scenario, organizations are asking themselves the following questions:

• How does the enterprise ensure that its expenditures and resources are aligned with its key business goals?
• Is there a way for the enterprise to find out if the totality of its works is directed towards moving the business forward?
• What does the enterprise do when it has defined more projects than it has resources for, especially with cost pressures increasing every day?

The answer to these questions lies in the discipline of ‘Project Portfolio Management (PPM).

PPM is a disciplined process which enables enterprises to prioritize its various initiatives by understanding its business goals and balance multiple evaluation criteria. It enables enterprises to view and control their entire suite of investments as one set of interdependent activities in one place, as a portfolio, rather than one at a time. This way the project portfolio as a whole continues to address strategic initiatives, even as these initiatives change over time, thereby serving as the critical link between executive vision and the work of the enterprise.

Key steps involved in implementing a PPM process are:

1. Define the Funding and Budgeting Process: This step involves defining the crucial funding, budgeting and decision making processes. Critical questions on budget allocation, funding decision hierarchy, ownership and governance matrix are defined.

2. Define the Portfolio Management Process: This step involves defining the process of receiving, validating and approving new project requests along with the Portfolio management team and its responsibilities.

3. Define the PPM Framework and Prioritization Criteria: This step involves defining the criteria across different business domains along with project classification, prioritization criteria/parameters, weight ages, scoring anchors and ranking methods. All such criteria need to be aligned to the business strategy and articulation of the strategy is critical.

4. Determine the Project and Resource Capacity: This step involves determining the capacity in terms of resources that will be used for project work. This proves useful in prioritizing the projects vis-à-vis available resources and bandwidth.

5. Define the Portfolio Review and Updation Process

No process is complete without defining the updation and review process. The portfolio reports and communication process needs understanding from multiple stakeholder perspectives. A sound PM practice becomes critical for relevance of project performance information.