Tag Archives: Portfolio Management

Projects, Programs and Portfolios – 3 Common Traps


I recently got the following email from a reader of my blog:

I am a student of project management…  Thank you for the article Project vs. Program vs. Portfolio Management.  However, I have a challenge deciphering the relationship between these terms and I think an illustration using an example would help me a lot. I kindly requesting you to help me with that. May you help me please!”

I replied with an analogy, rather than an example, and, per her response, I guess the analogy helped!  Given that the post she referred to continues to be among the most highly read posts on my blog, I thought I’d repeat the analogy here, and use it to discuss three common traps I see IT leaders falling into.

Managing an Investment in a House

Let me take an example of owning a house.  (By the way, the details behind this analogy are totally fictitious!)  I may decide that I am going to invest $20,000 per year in this house.

I decide to allocate this $20,000 into a portfolio.  I will spend 20% on recurring operating costs (home owners fees, real estate taxes, etc.)  I will spend 40% on improvements – things that make the house nicer to live in and hopefully add value to the house.  I will spend 20% on maintenance – painting, pressure washing, annual contracts for maintaining heating and air conditioning, etc.  And I plan to spend the remaining 20% on major repairs – a new roof every 12 years, new air conditioning, etc.

Essentially, I have defined my $20,000 annual investment into a portfolio model.  This helps me manage my spending and hopefully lets me balance investment in future value (improvements) against necessary ongoing costs.  I can track my spending by portfolio category and either adjust my portfolio or get better at managing costs.

My Handicap Access Program

As part of my improvement investments, I decide that I want to make the house handicap accessible.  So I create an Handicap Access Program.  The goal of this program is to make the entire house conform with handicap access regulations.  I believe this will make the house more valuable on the market given the demographics (aging population).

My Handicap Access Program will take about 3 years to complete and will be funded out of the 40% “improvement” bucket of my total $20,000 portfolio – i.e., approximately $2,500 per year over 3 years.

The Handicap Access Projects

My Handicap Access Program will comprise 5 major projects:

  1. Ramps at the front and rear doors
  2. Wider doorways
  3. An elevator
  4. Grab handles around the baths and showers
  5. Invalid access bathtubs

Each of these 5 projects will be managed by a project manager and managed as separate projects.  I will take responsibility for the whole program, and at the end of the 3-year program, I will apply to the local authorities to get the house handicap access approved.  I know I’ve been successful when I get the approval.

So I have a Portfolio Investment Model for my house, one major Program (Handicap Access) and 5 home improvement projects that all have to be successful for the Program to succeed.  Also, there will be dependencies between the projects (I need to get the ramps constructed first to make it easier for the builders to do the inside jobs).

Common Trap #1 – Ignoring the Power of Program Management

I am fully convinced that these 3 disciplines – Project Management, Program Management and Portfolio Management build on each other – each is a foundational disciple for the next.  If you have lousy or inconsistent Project Management, you’ll never have effective Program Management or Portfolio Management.

The first trap I see many companies fall into is that they focus on Project Management and Portfolio Management, and forgo Program Management because they don’t really understand it!  Then they wonder why Portfolio Management never really gains traction or helps to elevate the business value of IT investments.  The Portfolio they end up with a simply a laundry list of projects. In my simple analogy, I’ve recognized that the 5 Handicap Access Projects are connected – I can’t gain the full benefit of the Program until all 5 Projects are completed.  Also, by recognizing they are interdependent, I ensure that they projects work together to reach my program goal.  You can’t easily connect Projects to a Portfolio without the intermediate abstraction of Programs.

Common Trap #2 – Portfolio Management as a ‘Bottom-up” Exercise

The second common trap is that people “back into” their portfolio model bottom-up.  Rather than take a position that they will budget 40% (using my analogy) of their total investment in “improvements”, they derive that number by summing up all their improvement projects.  That is hardly strategic!  They have failed to establish a portfolio strategy.  It would be like randomly picking stocks, bonds, precious metals, and so on, and figuring out what your portfolio model is, rather than saying, “At my life stage I want a conservative portfolio of 80% bonds and cash equivalents, and 20% mostly domestic stocks.”

Common Trap #3 – Failing to Engage Business Leaders in Defining the Portfolio Model

The third common trap is failing to bring senior business executives into the strategic thinking that leads to a Portfolio Model.  If business executives recognize that 80%, say, of the IT budget is consumed by day-to-day operational costs, and that only 20% of investment going to new capability, they may get quite interested in tackling the operational cost problem if it can free up investments in new capability.  And it is often the case that most of the cost drivers in operating IT are in the hands so the business executives.  Bringing them inside the tent and engaging them in deciding the right portfolio mix for the business strategy can be transformational!

 

Graphic courtesy of PM Study Circle

Related articles
Enhanced by Zemanta
About these ads

Do You Have IT Organizational Clarity – Part 3


This picks up on Part 1 and Part 2 in this series on IT Organizational Clarity.

In Part 1, I discussed the importance of IT Organizational Clarity, the symptoms when clarity is compromised, and the challenges of trying to address those symptoms rather than the root causes that lead to compromised clarity.  Part 1 closed with a discussion of the two key dimensions along which IT Organizational Clarity can be tackled – scope (units of IT Capability) and meaningful and assessable characteristics for evaluating and improving IT Capabilities.

In Part 2, I discussed ways to define IT Capabilities and provided guidelines on the manageable number of IT Capabilities and appropriate depth of decomposition.  In this post, I will describe three different types of IT Capability.

Not All IT Capabilities Are Born Equal

It is helpful to classify IT Capabilities into one of three different types, as illustrated in the graphic above.

Value Chain Capabilities

At the core are those capabilities that take inputs, add value, and deliver outputs to a customer or end consumer (in the world of IT, these tend to be services and products).  Think of these Value Chain Capabilities as those that the end customer appreciates (hopefully!) and is willing to pay money for.

For example, as a business user, I may have a business problem I’d like IT help to solve.  That problem (or opportunity) is the input to a Value Chain.  The first Capability that will approach that problem adds value by analyzing the problem, identifying and proposing a solution.  As the business user, I appreciate that value has been added – drilling into my stated problem and offering (and perhaps demonstrating via a prototype) one or more proposed solutions.  The next Capability in the Value Chain might take the chosen solution and develop and deploy that solution.  Again, as the business user, value has been clearly added – taking a proposed solution and delivering it.  The final Capability where value can be added is supporting and maintaining that solution – again, a recognizable way of adding value for me, the customer.

Ultimately, as the business user or consumer, these are the only Capabilities I care about and am willing to pay for (directly or indirectly) because of the value they add for me.  Unfortunately, while these Value Chain Capabilities are necessary, they are not sufficient.

Enabling Capabilities

Value Chain Capabilities typically draw upon other Capabilities that enable them.  Think of these as Shared Services that are common to other Capabilities, or to other instances of problems/solutions working their way through the Value Chain.  Examples of IT Services that might enable the Value Chain Capabilities include Project Management, IT Operations, and IT Supply.

Alignment and Governance Capabilities

Value Chain Capabilities also typically depend upon other Capabilities that ensure that the work they are doing is aligned and governed to ensure they are operating effectively and in the interests of the enterprise.  For example, determining which business problems will be addressed, which solutions will be selected, how staff and resources will be allocated are all important control that Value Chain Capabilities will be subject to.

Why These Distinctions Matter to IT Organizational Clarity

The distinctions between Value Chain, Enabling and Alignment/Governance Capabilities are significant:

  1. Different types of IT Capability tend to be optimized towards different value propositions, with implications for how they are organized.  For example, Enabling Capabilities tend to be optimized for Operational Excellence (as shared services, they need to deliver predictable, consistent, quality services at the lowest possible cost).  Value Chain Capabilities tend to be organized for Customer Intimacy, delivering what specific customers want; anticipating customer needs.  Alignment and Governance Capabilities tend to be more about decision-making – rather than delivering services, they make decisions or provide decision-making frameworks – think Enterprise Architecture and the mechanisms and structures that support it as Alignment and Governance Capabilities.  As such, these tend to be networked, linking stakeholders and decision makers, and optimized to maximize the business value delivered or enabled by IT Investments..
  2. Some types of IT Capability lend themselves to alternate sourcing more than others.  For example, Aligning and Governance Capabilities lend themselves the least to straight outsourcing approaches (do you want to pass decision rights to an external vendor?)
  3. Different types of IT Capability lend themselves to different funding models.  For example, Value Chain Capabilities lend themselves to direct business funding, whereas Enabling Capabilities lend themselves better to indirect funding models (e.g., overhead charge).

IT Capability Model Example

As an illustration, below is a ‘normative’ IT Capability Model.

The Fractal Nature of IT Capabilities

Note, that as you decompose any IT Capability, you will generally find that the decompositions will have a similar structure – a primary Value Chain, drawing upon underlying Enabling Capabilities and influenced by Alignment and Governance Capabilities.

For example, Manage Business-IT Portfolio & Programs might decompose into the following sub-Capabilities:

In the following post, we will look at the assessable characteristics of any IT Capability as a means of determining Capability Maturity and determining how to increase maturity and thereby improve performance.

Enhanced by Zemanta

Four Common Mistakes in IT Portfolio Management


Among my most popular topics, week after week, is Portfolio Management.  It’s a key discipline, especially crucial in driving Business-IT Maturity past the tricky mid-point where many IT organizations tend to get stuck.

IT Business Edge has just published a short slideshow on “Four Common Mistakes in IT Portfolio Management“, re-purposing a post of mine from January 2008.  I think they did a great job simplifying and bringing to life some of the key points in the original post.  Enjoy!

Enhanced by Zemanta

IT Leadership – Caught between Two Realities?


It’s always been tough being an IT leader.  The “Career Is Over” distortion of the CIO acronym is humorous because of the real world challenges associated with the CIO job.  I think that today is an especially challenging time for IT leaders.  I say that because these jobs are typically caught somewhere between two very different realities – realities we might refer to as “1.0″ and “2.0″.

IT Reality 1.0

Reality 1.0 holds that IT must be managed.  It is difficult and complex – fraught with crucial technical details.  Mastering these details requires teams of technical experts, following rigorous processes and procedures.  Issues that mere mortals don’t often think about – things such as back up and recovery, security and privacy, regulatory compliance, business continuity – must be planned for and managed by IT specialists who have been properly trained and certified in these disciplines.

Reality 1.0 holds that IT should be owned, and certainly, must be controlled internally.  It holds that business users must be protected – both from themselves and from the raft of vendors and consultants, all trying to sell them stuff that could cost them money (at the very least) and might even get them in trouble.

Reality 1.0 holds that qualified IT resources are scarce and costly.  They take time to develop and cannot be ramped up or down quickly.  Therefore, long term planning and concerns about scaling are constantly on the IT professional’s mind.

Reality 1.0 is obsessed with risk avoidance.  Constantly aware of many of the horror stories that are told around the IT campfires (and sometimes involved in either perpetrating or recovering from such horrors), IT leaders work to prevent the many risks associated with IT.

Given resource and risk issues with IT, Reality 1.0 deploys sophisticated tools and governance processes to filter the many opportunities for IT-enablement and weed out all but the key initiatives that justify the the investment and risks.

Reality 1.0 perceives the world of IT as relatively closed and proprietary.  Therefore, it is obsessed with IT architectures and standards – with figuring out how to weave together point solutions into capabilities that meet enterprise needs.

Reality 1.0 is about large projects and solutions – multi-month, sometimes multi-year initiatives designed to last for years.

Reality 1.0 separates the world into ‘development’ and ‘production.’  The move from one to the other is like the move through an airlock – from a dangerous and polluted free-for-all into the safe, secure and sterile data center.

IT Reality 2.0

Reality 2.0, by contrast, holds that IT is simple, ubiquitous and inherently safe.  Almost anyone can be creative and productive with IT – all they need is an Internet connection and a device equipped with a web browser.  If the user knows nothing, they can simply leverage what is already on the web – and learn as they do so.  If they know a little, and are adventurous, they can do much more than passively leverage what is already there – they can “mash up” new capabilities from existing ones to solve new problems.  They can learn as they go, become even more adventurous and creative – perhaps even commercialize what they have created.  Over time they will become even more skilled – creating more sophisticated solutions – or leveraging ‘crowdsourcing‘ to engage others to help them create the solutions they need.

Reality 2.0 does not care about IT ownership or control – they care about results.

Reality 2.0 sees the world as a sea of opportunities and solutions to be tried and exploited.

Reality 2.0 sees IT resources as ubiquitous – found with a click of the mouse, engaged with a few more clicks, and paid only when they’ve delivered.  Resources are paid for as they are needed – no long term commitments or overhead payments to worry about or justify.

Reality 2.0 is about risk management – moving incrementally and organically, managing risks as they are recognized.

Reality 2.0 has no time for bureaucratic processes such as governance committees and cost justification rigmaroles.  It sees any opportunity as worthy of a quick experiment to see if its real – it believes that in the time it takes to create a business case or wait for the next governance committee meeting, the idea can be tested and validated or eliminated – let the proof of the pudding be in the eating, so to speak, not in the political machinations of investment review bodies.

Reality 2.0 perceives the world of IT as essentially open.  Things in its world naturally fit together.  Therefore, things can be built in small incremental steps – evolving in the light of experience and changing needs.  Things can also be built as discrete point solutions – and yet still can be fitted together if need be.

Reality 2.0 is about small projects and solutions – created in days or weeks and designed for just as long as they are effective.

Reality 2.0 sees development and production as living side-by-side in some virtual place in the sky – while I’m working on its creation, it’s in development.  Once it’s working, I declare it ‘production’ and it is so.

The Best of Times, The Worst of Times…

If IT Reality 1.0 accurately reflected today’s world – as it did for most of the last 50 years or so – life would be ok for IT leaders.  Both they and their business consumers would understand their respective roles and would work together for the mutual good.  If Reality 2.0 accurately reflected the world – as it might do in the next 50 years or so, life would ok for IT leaders.  While their roles and those of their business consumers would be very different from those typical today, again they’d be on common ground.

The really big challenge today is that the reality today is neither 1.0 or 2.0 – it is in transition.  And in the immortal words of William Gibson, “The future is already here, it’s just unevenly distributed.”  This ‘uneven distribution’ of IT Realities 1.0 and 2.0 is going to represent both a curse and an opportunity to IT leaders.  For the progressives, it’s a wonderful opportunity to shift IT into overdrive.  For the laggards, I fear that it’s going to make their lives more and more miserable!

Do you live in this dichotomy?  How quickly is reality 1.0 being replaced by reality 2.0?  Are these realities coexisting?  What are you doing to accelerate or impede the shift?

Image courtesy of Rumple at Flickr

Reblog this post [with Zemanta]

We Picked the Wrong Tool!


How many times have you heard, “We picked the wrong tool!” when referring to a project management or portfolio management or just about any other kind of tool for the IT organization?  I’ve heard that many, many times over my 30 year consulting career.  So, it’s time for a couple of uncomfortable truths – expressed as “Merlyn’s Rules of IT Tools”:

  • Merlyn’s Rule #1:  You will always pick the ‘wrong’ tool.
  • Merlyn’s Rule #2:  If you focus on the process being automated or supported, and the management of organizational change, you will probably find you actually have the ‘right’ tool.
  • Merlyn’s Rule #3:  If you focus on the process and management of organizational change and still want a different tool, then switching to a new tool will be trivial.

The Cobbler’s Children

All IT people know the three rules above.  You would never allow technology to be applied to a business process without reengineering the process first.  And yet, when the “customer” is the IT organization, all the conventional and hard-earned wisdom goes out of the window and into the shredder!  I’d like to explore why this is, but frankly, I don’t know.  I guess it is a syndrome that all professions are prone to – hence the ancient proverb.

Image courtesy of USDA Agricultural Research Solution

Reblog this post [with Zemanta]

How “IT-Savvy” Is Your Company? Why Does That Matter?


weillross_300dpiRegular readers will know that from time to time I refer to research by Peter Weill, Chairman & Senior Research Scientist, Center for Information Systems Research (CISR) at the MIT Sloan School of Management.  I’ve had the privilege of knowing Dr. Weill for many years, and having collaborated with him on several multi-company research initiatives.

Peter and his colleague and co-author Jeanne Ross recently published their latest book called IT Savvy: What Top Executives Must Know to Go from Pain to Gain.

This is an excellent and important book.  It is notably the first book by this duo written for the top executive community, rather than for IT professionals – the target readership for prior Weill/Ross books.  I’m well known for repeating the mantra, “Organizations get the IT they deserve!” This book really reinforces the leadership roles and practices that help converge business and IT.  The ideas are beautifully organized, clearly presented and convincingly illustrated by interesting case studies.

I don’t want to pretend that one book can, by itself, move you along the road to “premium return on IT.”  But it sure is a great resource and, most importantly, a way to educate your key stakeholders what it takes to get on the right road!

Practices that Earn a Premium Return on IT

The authors, building on 15 years of research, describe what they refer to as the “Three Obsessions of the IT-Savvy Firm.”  These are:

  1. Fixing What’s Broken About IT.
  2. Building a Digitized Platform.
  3. Exploiting the Platform for Profitable Growth

Citing several case studies to illustrate their points and help make the practices real, they work through issues of business operating model and the IT implications of operating model choices: IT funding model, digitized platforms, governance, driving value, and leadership.

Read, Share and Discuss!

Read this book with the idea of sharing it with your business partners and stakeholders.  Set up or take advantage of current opportunities to drive dialog around the implications of IT Savvy to your organization.

I believe you will recognize in the IT Savvy book many of the practices, recommendations, and “vignette’s” that surface in this blog from time.  In fact, Peter and Jeanne’s work over the years, and my research experiences with Peter, has greatly influenced my belief system, and with it, my approach to IT management consulting, at least over the last 15 years!

Book Cover Image Courtesy of Harvard Business Press

Reblog this post [with Zemanta]

Supposing You Funded IT Like a Charitable Donation?


charity_box1I’ve had this IT funding fantasy for years (I know, it’s really sad that my more exciting fantasies are to do with IT funding scenarios!) Supposing the CIO had to do a fund drive every year or every six months the way our local National Public Radio stations had to operate in order to fund certain IT activities?

I actually hate the NPR fund drives, but I love what privately funded radio brings compared to all other forms of news and quality radio programming  in the USA, and I realize that the funding model is necessary and ultimately important to the NPR mission.

Listening to my local radio station’s NPR funding appeal for a couple of weeks twice a year always gets me thinking about IT funding and my “IT Charitable Donation Fantasy.”  I’m not suggesting this is the way to fund all IT activities – far from it.  I believe that funding, for good or bad, drives behavior, so if we want responsible business behavior around IT assets and activities, we need to think through the desired behaviors and how funding models promote or detract from those behaviors.

Three Distinct IT Funding Pools

It is useful to carve IT spending into 3 broad categories:

  1. IT infrastructure.  This should be defined very broadly to include all shared IT capability.  To borrow from Prof. Peter Weill’s definition, IT infrastructure is the base foundation of IT capability budgeted for, centrally coordinated and shared across the enterprise.  I don’t see this being funded through a charity-like, voluntary basis.  Like all infrastructures, nobody really wants to fund it, and few understand the technology details, risk management, capacity planning and other implications that render IT infrastructure either reliable and supportive of the business mission on the one hand,  or unstable and get in the way of the business mission on the other.  I think IT infrastructure is best funded as a kind of tax – in a way that fairly represents the proportional value to the organization that uses it.  Depending upon the nature of the business, this might be a function of headcount, divisional revenue, or some other factor.  And, as an aside, the CIO should be looking to continuously improve the cost per unit of infrastructure over time.
  2. Business Solutions.  These should essentially be funded by the business units that require them and will benefit  from them.  If more than one business unit, then the combination of business units will fund the solution in proportion to the degree of benefit or value each derives.  This will never be pure science and will typically involve some kind of negotiation between the parties.  By the way, this type of activity should have a robust value realization approach to go along with the funding.  (I’ve posted on value realization quite a bit in the past – if you are not familiar with this material, please either search my blog for “value realization” or drop me a line, and I’ll send you the links.)
  3. Innovation/Research and Development.  This is the part of the IT budget that I think lends itself best to a voluntary funding model.  The most common funding practice I come across for this category of activity is “stealth funding” – i.e., the CIO squirrels away funds from other activities, and runs them below the radar – some unspent training dollars here; some savings from a renegotiated vendor contract there; some money left over from a project that came in under budgets, and so on.  The problem with stealth funding is that it is unpredictable, and it hides from the customer base the fact that money for innovation and R&D is actually necessary, and a sign of a healthy IT organization.

Fund Raising for IT R&D

So, how might this work?  First, the CIO needs to decide a funding target for IT Innovation and R&D.  This might be something between 1% and 5%.  Then build a business case – how will the funds be used?  Why should the business care – how might they benefit?  Typically, these funds will be invested in a mini-portfolio of activities, from low-risk to high-risk, and from short-term to long-term.  Will there be an expected payback on the whole portfolio?

For those business heads that chose to participate, will they get any special treatment compared with those who chose not to participate?  (This is a thorny question!  NPR does not threaten to cut me off listening to the wonderful Morning Edition or All Things Considered, or any of their great weekend shows should I not ante up each year for “membership.”)  For the CIO, I’m not sure how best to play this out.  I think some special treatment might be the ability to participate in business experiments that are associated with the R&D activities, but there may be other quid pro quos for those who pony up to the R&D fund.

Comments?  Questions?

So, what do you think?  How “fantastic” is my IT funding fantasy?  Are any of you doing anything like this?  How is it working?  Could it work?  Answers on a postcard, please!

An IT PMO Glossary


glossary

I’ve been working with a couple of clients around PMO’s and the thorny space of Portfolio and Program Management.  Not coincidentally, this continues to prove to be an area of great leverage for organizations trying to drive up their business-IT maturity (and with that, increase the business value delivered through IT investments, assets and capabilities.)  It also continues to be among the most popular topics on which I blog.

Each client quickly found the need to get themselves aligned around the terminology, and asked me to create a simple Glossary that would help them differentiate and standardize on the various terms that are central to IT Portfolio Management.

To that end, I offer here a “starting point” for such a glossary.  Of course, in our industry, where terminology is used inconsistently, and where opinions about meanings tend to differ widely, I realize that this exercise is fraught with danger.  However, I offer this as an initial point of reference.  I’d be delighted to hear any major issues with my use of these terms, and suggestion for modification and for extension to this list.

An IT Portfolio Management Glossary of Terms

(Note:  * Source is Wikipedia)

Term

Definition

Comments
Project Management Project Management is the discipline of planning, organizing and managing resources to bring about the successful completion of specific project goals and objectives.* Project Management is typically focused on deliverables, budgets and timelines to meet specific objectives.
Project Management Office Project Management Office (PMO) is the department or group that defines and maintains the project management standards and processes within the organization. The PMO strives to standardize and introduce economies of repetition in the execution of projects. The PMO is the source of documentation, guidance and metrics on the practice of project management and execution.* Project Management Office models vary from organizational entities that define the process and standards for others to follow, to those that actually manage projects for the organization.  Considerations as to type of Project Management Office model will include organizational experience and maturity with project management, organizational goals in terms of consistency, commonality and control, and preferences for centralization versus decentralization.

PMO’s are sometimes responsible for Project, Program, and in some cases, Portfolio Management.  In such cases, the acronym may be extended to PPM or even PPPM.
Project  Manager Project Manager is a professional management role typically vested with the responsibility for the planning, execution, and closing of any project. Some organizations insist on certification (such as by the Project Management Institute) for IT professionals who will manage projects above a certain size or criticality.  Sometimes, Project Managers are physically grouped into a Project or Program Management Office (PMO); other times they are virtually networked into a Project or Program Management Community of Practice, and sometimes they are simply expected (or at least, encouraged) to follow the processes, standards and methods laid down by the PMO without being part of the PMO organization or community.
Program Management Program (or Programme) Management is the process of managing multiple interdependent projects that lead towards an improvement in an organization’s performance.* Projects deliver outputs; programs create outcomes. A project might deliver a new factory, hospital or IT system. By combining these projects with other deliverables and changes, their programs might deliver increased income from a new product, shorter waiting lists at the hospital or reduced operating costs due to improved technology.  Program management is concerned with doing the right projects, whereas project management is about doing projects right. Successful projects deliver on time, to budget and to specification. An organization should select the group of programs that most take it towards its strategic aims whilst remaining within its capacity to deliver the changes*

Many enterprise IT organizations tackle large, complex efforts that combine the delivery of software elements, new and changed business models, and overall changes to organizational structure and capabilities. Typically these efforts involve several parallel projects, and managers find that “traditional” project management approaches fall short for such undertakings. Consequently, many IT professionals are turning to the substantial body of experience, and the smaller body of documentation, that supports the discipline of program management. This discipline describes principles, strategies, and desirable results for managing large-scale efforts comprising parallel projects. (Source: IBM White Paper: Program Management – Different from Project Management)
Program Management Office A Program Management Office is the department or group that strives to standardize and introduce economies of repetition in the execution of projects and programs. The PMO is the source of documentation, guidance and metrics on the practice of project and program management and execution. The term PMO sometimes refers only to Project Management, other times to both Project and Program Management, and in some cases extends to Portfolio Management. .  In such cases, the acronym may be extended to PPM or even PPPM.
Program Manager A Program Manager is a professional management role typically vested with the responsibility of coordinating multiple interdependent projects that lead towards an improvement in an organization’s performance. Program Managers have ultimate responsibility for the organizational performance outcomes. Program Managers are highly qualified and experience Project Managers who have also mastered the disciplines associated with managing complex, inter-dependant groups of projects that collectively lead to improvements in an organization’s performance.  In addition to project management excellence, they are highly proficient in organizational change management, managing up as well as down through the organization.
IT Portfolio Management IT portfolio management is the application of systematic management to large classes of items managed by enterprise Information Technology (IT) capabilities. Examples of IT portfolios would be planned initiatives, projects, and ongoing IT services (such as application support). The promise of IT portfolio management is the quantification of previously mysterious IT efforts, enabling measurement and objective evaluation of investment scenarios.* IT Portfolio Management is founded on Modern Portfolio Theory which proposes how rational investors will use diversification to optimize their portfolios.  When applied to IT, Portfolio Management proposes how the organization (assuming it is acting in a rational way towards its investments) uses diversification to optimize its IT investments.  In this case, optimization may include balancing:

  • Short term and long term investments.
  • Low risk, low return against high risk, potentially higher return initiatives.
  • Common and shared (i.e., IT infrastructure) against business unit specific investments.
  • Investments by major business process.
  • Creating new capability versus maintaining existing capability.
  • Investing in IT process and capabilities (i.e., improving the “business of IT”) versus investing in IT capability for the business.

IT portfolio management is the primary means to elevate IT decision making and investment prioritization to a business issue.  In this context, IT portfolio management includes a top down decision making framework, implying that:

  • Senior executives have debated, considered and reached consensus about their IT investment portfolio strategy.
  • This, in turn, implies that senior executives have considered and agreed to a business-IT strategy.
  • They have wrestled with the thorny questions about “level of optimization” of IT investments – whether this should be a business unit or function (implying a conglomerate or holding company model) or the enterprise (implying a more integrated business model.
  • If they balance by business process, that the major business processes have been defined, and their importance to business strategy execution determined.
  • * They are able to monitor the gaps between their actual IT investments by portfolio category, against their target, or “model” portfolio, and can make adjustments as necessary.
Portfolio Management Office See Program Management Office IT Portfolio Management Offices are rare.  Rather, Portfolio Management is seen as a responsibility of business-IT governance, and the highest levels of business-IT investment decision-making.  As such, disciplines and groups such as PMO’s (or PPMO’s) are invaluable tools in support of effective IT Portfolio Management.

Portfolio Management: So Much More Than a Collection of Projects!


collectionI’ve posted recently about Program Management – mainly in response to a reader’s question about how to group projects into programs.  Her question, in turn, was in response to one of my most popular posts on the distinctions between Project, Program and Portfolio Management.

IT Portfolio Management Matters!

I’m delighted that my old post on this topic (about 16 months ago) keeps attracting readers – portfolio management is one of the most important keys to business value realization from IT.  It is also often poorly implemented.  In fact, quite often, the term “portfolio management” is used without any justification in reality.

Modern Portfolio Theory

IT portfolio management is rooted in Modern Portfolio Theory.  Defined by Wikipedia, Modern Portfolio Theory:

proposes how rational investors will use diversification to optimize their portfolios…

When applied to IT, Portfolio Management proposes how the organization (assuming it is acting in a rational way towards its investments) uses diversification to optimize its IT investments.  In this case, optimization may include balancing:

  • Short term and long term investments.
  • Low risk, low return against high risk, potentially higher return initiatives.
  • Common and shared (i.e., IT infrastructure) against business unit specific investments.
  • Investments by major business process.
  • Creating new capability versus maintaining existing capability.
  • Investing in IT process and capabilities (i.e., improving the “business of IT”) versus investing in IT capability for the business.

IT portfolio management is the primary means to elevate IT decision making and investment prioritization to a business issue.

In this context, IT portfolio management implies a top down decision making framework.  It implies that:

  • Senior executives have debated, considered and reached consensus about their IT investment portfolio strategy.
  • This, in turn, implies that senior executives have considered and agreed to a business-IT strategy.
  • They have wrestled with the thorny questions about “level of optimization” of IT investments – whether this should be a business unit or function (implying a conglomerate or holding company model) or the enterprise (implying a more integrated business model.
  • If they balance by business process, that the major business processes have been defined, and their importance to business strategy execution determined.
  • They are able to monitor the gaps between their actual IT investments by portfolio category, against their target, or “model” portfolio, and can make adjustments as necessary.

Not a Collection of Projects

From time to time, I see consulting clients attempting to implement portfolio management from a collection of projects.  Sometimes, this activity includes taking a huge list of several hundred (in one recent case, nearly a thousand!) to the business so they can “prioritize the portfolio.”  This bottom-up approach is always doomed to failure.  It is often the result of several years of “order taking” behavior by the IT organization, and is, in fact, the order taking equivalent,  elevated to a different level.  It effectively says:

We’ve taken orders from you for years, and now we have this huge list of projects.  So, please take a look at them, and help us prioritize them, because we can’t do them all!”

This cannot work, and ultimately, reinforces order taking behavior, and the sense that IT does know know what it’s doing, and does not deserve the trust of its business partners.

A Question of Business-IT Maturity

I’ve written extensively about Business-IT Maturity and its relationship to business value. (For a more comprehensive treatment, use this search.)  At very low maturity, by definition, the business executives will not have the wherewithal to engage in and answer the questions exemplified in the bullet points above, so implementing portfolio management is going to be virtually impossible.  But, to get to higher maturity, these questions have to be understood, discussed and decided upon, so the IT leadership is best served educating the business till it is ready to engage meaningfully in these questions.  At that point, they will be ready for IT portfolio management.  Until then, be careful not to call bottom up collections of projects, “portfolios.”  If you do, when you are finally ready to introduce portfolio management, the language, and the business discipline it connotes, will have been polluted.

An the Link Back To Programs?

Finally, linking back to the start of this post, and the readers question, “Programs” become the most meaningful intermediary between “projects” and the “enterprise IT portfolio” – a manageable and meaningful “unit of value-producing work” that business executives can get their heads around.

Photo courtesy of the Building and Fire Research Laboratory.

The Art and Science of Grouping Projects into Programs


groupingI just received a comment on an old post, Project vs. Program vs. Portfolio Management.  This has been a popular post since it was written back in October 2007.  The comment read:

I’m doing a research on how do organizations group their projects into programs, please tell me how do they go about doing that. e-mail me as soon as possible.

First off, this is an important question.  Second, my blogging philosophy is that if a question is worth answering by email, it’s worth offering on the blog, so others might get into the discussion and benefit from it.  Mostly, I reply to a comment with a comment, but when a question is as important as I believe this one is, then I think it deserves a post of its own.

What is Program Management?

Wikipedia covers Program Management well (as usual!) Their simple definition is:

Program management or programme management is the process of managing multiple interdependent projects that lead towards an improvement in an organization’s performance.

Wikipedia goes on to say:

Projects deliver outputs; programs create outcomes.  Program management is concerned with doing the right projects, whereas project management is about doing projects right.

These are key distinctions, and begin to get at the heart of the reader’s question above.

Another great reference is from IBM and their white paper entitled Program management: Different from project management.  In this, IBM says:

Many enterprise IT organizations are tackling large, complex efforts that combine the delivery of software elements, new and changed business models, and overall changes to organizational structure and capabilities. Typically these efforts involve several parallel projects, and managers are finding that “traditional” project management approaches fall short for such undertakings. Consequently, many IT professionals are turning to the substantial body of experience, and the smaller body of documentation, that supports the discipline of program management. This discipline describes principles, strategies, and desirable results for managing large-scale efforts comprising parallel projects.

This description, like the Wikipedia definition, provides clues to the question posted as a comment in my earlier blog entry.

Beware the Language Traps!

A caveat here – organizations tend not to be rigorous (and certainly not globally consistent) with their use of terminology here.  So just because you use the term “Program Management” does not necessarily mean you are doing it.  (Nor does the fact that you use the term Project Management mean you are doing that, or that you have Project Managers mean you are actually doing good project management practice!)  By the same logic, you may actually be doing great Program Management, even though you don’t use the term.  (I have to say, I have never seen this, but it’s possible).

Another language complication is that the term Program Management may have already been adopted by your organization – perhaps with accurate and appropriate usage, but perhaps not.  I’ve worked with aerospace and defense companies where the term “program” has a very specific meaning related to government procurement.  This is a tough issue, because they are not going to throw out that terminology, so you really need some other terminology to distinguish between those sub-units of work that focus on deliverables, timeframes and budgets (project management) and those collections of mutually dependent projects that collectively produce business outcomes.

So, How Do You Group Projects Into Programs?

This is part art, part science, and frequently involves both top-down and bottom-up planning approaches.  The key element is wrapped up in the notion of a business outcome.   A business outcome is a measurable result – both in terms of time and quantity – that is significant to business leaders.  “We will increase the results of cross-selling our services by 15% by the end of 2009″ is a business outcome example.  Note, it is specific as to degree and timing.  It is also of value to the business – sufficient to drive change, and relatively easily turned into one or more financial impacts.

So, how will be achieve this increase in cross selling?

  • We will implement a Customer Relationship Management solution
  • We will re-engineer our customer acquisition process
  • We will reorganize our sales force
  • We will change our sales compensation, reward and recognition model
  • We will retrain our sales executives
  • We will realign our service portfolio to make it easier and more logical for our customers to buy additional services that cross traditional boundaries.

These changes might involve technology, organizational change, change in HR practices and compensation, training and development, changes to the service portfolio, and changes to our marketing approach.  All in all a complex set of changes that are collectively necessary to achieve the outcome.  In this case, the program is likely to be  the “Cross Selling Enhancement Program” or something similar.

The underlying projects that will be grouped into that program are typically defined by organizational units and their primary responsibilities.  The technology changes will be owned by IT, and may include software, data base, and workflow projects (or analysis, design, implementation projects as a different way of breaking things down.)  The sales reorganization and process changes will be owned by Sales, the HR changes will be owned by the HR organization, and the service portfolio changes owned by product management.  The overall program might be owned by Sales and Marketing, or there might be an Enterprise PMO, that could be part of the IT organization, or a separate entity.

The process I’ve outlined about is essentially top-down – start with the outcome, and decompose into component parts by organizational impact or specialization, form into projects and connect together in an overall program plan.  This is ideal.  Often, however, things happen much more organically and chaotically.  A sales VP gets on a kick about cross selling, but after a few months talking about it and hoping it will happen, decides they don’t have the right tools.  She reaches out to Salesforce.com, but fairly quickly realizes she’s going to need help and support from the IT organization.  And, as the onion gets peeled back, new layers of complexity and new issues occur, and the number of projects spawned by the desire for more cross selling mushrooms.

Unfortunately, these individual projects have little or no sight into the original outcomes – increase the results of cross-selling our services by 15% by the end of 2009!  So, the projects loose sight of the goal (and therefore miss it).  They also attach their own “pork” or “earmarks” (to put this in the context of the latest US political debates).  “While we are creating our partnership with Salesforce.com, let’s experiment with their platform to bring some social networking capabilities to bear.”  “While we are training the salesforce in cross-selling, let’s also teach them solution selling.”  While we are cleaning up our customer relationship data base, let’s build a data warehouse to support our business analytics.”  And so it goes.  All potentially worthwhile ideas, but none of them may be essential to achieving the original business outcome, and may potentially derail or de-focus us from achieving that outcome.

Anyway, in the bottom-up case just discussed, the program may be created by recognizing a growing collection of projects that need to be better connected, coordinated and shaped to meet an outcome of importance.  That might mean killing some projects and re-chartering others.

A Question of Governance

So, how do you group projects into programs?  Above all, based on the business outcomes you are trying to achieve.  Ideally, this is a top-down planning exercise, then a bottom-up governance and control exercise to keep the projects collectively on track to achieve the outcomes.  In a less than ideal world, it is first and foremost a governance exercise – you need a mechanism that produces visibility into all the projects going on.  That mechanism also needs visibility into the enterprise and business units strategic intents and desired business outcomes, so that it can recognize opportunities to synchronize, coordinate, refocus, delay or even kills projects that are consuming time and resources, but may not be moving the enterprise or business unit towards its stated goals.   And, by the way, just as Projects group into Programs, so do Programs group into Portfolios.  But that’s a topic for another day!