Category Archives: Portfolio Management

The Keys to IT Demand Management


Once again, I’m posting in response to a reader’s emailed question.  The reader wrote:

While trying to understand the difference between Demand management, Portfolio Management and Project management from an IT Infrastructure Service delivery perspective, I stumbled upon your blog and found some interesting reads.  Could you please share your thoughts on how to define Demand Management for a service delivery company – what is in-scope and out of scope?”

IT Leaders Tend to Focus on Supply Management

Delivering IT products and services has been challenging since businesses first became IT-dependent.  There’s lots of complexity, layers of specialization, an unnatural separation of IT producer and consumer, and significant capital investments.  Exacerbating this is the typically high ongoing maintenance and life cycle costs, rapidly changing generations of technology, with resulting technological obsolescence.  As a result, IT leaders have focused far more on supply management – figuring out their supply chains, providing security, integrity and stable services, squeezing out costs,and so on.

Meanwhile, the demand side has typically received short shrift.  Demand chains are unclear at best, and complexities such as the IT infrastructure implications of supply activities and changing technologies are opaque.  IT planners have a hard time answering fundamental questions such as, “What’s in the pipeline for the next 6 months?” or, “What is our projected resource utilization for the next 6 months?”

There are also common problems where demand meets supply – IT delivers products and services that business users don’t understand, did not really want, or did want but do not know how to extract the business value.  It is generally seen that IT’s job is to “deliver” the solution, but not to ensure it is working to full effect.

So, What is IT Demand Management?

According to Wikipedia:

Demand management is a planning methodology used to manage and forecast the demand of products and services. In business, the term is used to describe the proactive management of work initiatives (demand) with business constraints (supply).” (Bold font added for emphasis)

I like to think of IT demand management as:

A set of disciplines, tools, and governance mechanisms designed to surface, stimulate and shape business demand for IT products and services in balance with supply constraints.”

In other words, given that IT supply is always limited, how do we surface and shape demand to get optimum business value from limited IT supply?

Key Elements of IT Demand Management

Getting demand management working effectively requires an orchestration of several techniques and processes – and ultimately, a moderate to high level of Business-IT Maturity (earned through the focus on supply management mentioned above).

The key elements include:

  • Portfolio Management is an important demand management technique and tool (and, if implemented properly, a governance mechanism).  Portfolio Management can help balance IT demand across time horizons (short versus long term), across risk/reward profiles (high risk/high potential return, low risk/low potential return), across business units or business processes, and across IT investment categories, such as IT projects and programs versus IT infrastructure.  Portfolio Management can make these balancing acts explicit so that they become strategic choices (Portfolio Planning) rather than the result of natural “drift.”
  • Product and Service Life Cycle Management.  In the world of IT, creating a solution is a fraction of the cost – maintaining and evolving it, keeping up with changing business needs and shifting technologies is costly.  Traditional accounting practices add to the load as depreciation of capital expenditures creates an ongoing drag on funding sources.  So, ensuring that life cycle costs are taken into account with the initial investment, and managing product life cycles to ensure that necessary investments are made, and unnecessary products and services are retired in a timely fashion is a key Product and Service Management function.  Also, maximizing ‘reuse’ of products and services – “why bring in yet another Customer Relationship Management system when we already have three” is a common refrain that often goes unanswered.  Finally, understanding cost drivers, and influencing business behavior towards ‘responsible’ consumption of IT products and services is an important part of the demand management equation.
  • The role of the Business Relationship Manager (BRM) – the key interface between business and IT.  The BRM is an important demand management channel.
  • My reader’s question asked about what Project Management has to do with IT Demand Management.  Project Management is mostly a supply management technique.  However, poor project management can negatively impact demand.  For example, I’ve seen business behavior that essentially says, “I will ask for more than I need because I know IT will screw it up!”  Or, “I will ask for as much as I can get because I know nobody is keeping count on the results!”)
  • Though not mentioned in my reader’s question, Program Management embodies an important set of both Demand and Supply Management disciplines, tools and governance mechanisms.  Program Management is a critical linkage between Portfolio Management and Project Management.
  • Effective demand management also requires agile supply capabilities.  This is one of the best reasons for techniques such as selective outsourcing and cloud computing – being able to flex up as demand increases and scale back when it wanes.

The COBIT and ITIL Trap

I’m generally supportive of frameworks such as COBIT and ITIL – there’s no really good reason to reinvent these wheels – they embody ‘good practice’ for IT governance and service management respectively.  However, they have to be customized to fit your environment, and many companies short-change this activity and end up with processes-in-theory, but not in practice.  In other words, the processes, control objectives, and so on that they think they have are not what people actually do!

Another problem these frameworks can induce is deluding their proponents into thinking that tools and processes solve the problems of demand management.  Yes – you need clear, transparent demand (and supply) management processes, and these can certainly benefit from good frameworks and tools.

However, effective demand management hinges on strong business understanding and buy-in, highly skilled Business Relationship Mangers (or whatever you call people in that role) and robust business-IT governance.  In particular, governance must address how demand is justified, funded, and how benefits are tracked and accountability held for them.

 

Graphic courtesy of Vendeka

Related articles
Enhanced by Zemanta
About these ads

To Whom Should Business Relationship Managers Report?


I recently received this question from a reader:

We are evaluating a strategy to centralize IT and implement Business Relationship Management (BRM) roles as part of the centralization. Where do you typically see the BRM’s reporting into in a centralized IT organization? Should they report directly in to the CIO, or can they be effective a level or two below the CIO?”

Rule #1 – Reporting Lines Are Weak Determinants of Success for the BRM Role

I have found reporting relationships to be a very weak determinant of success for the Business Relationship Manager (BRM) role. Far more important are the competencies (especially business knowledge and relationship skills) of the BRM and the maturity of the business executives they partner with.

Rule #2 – Heft Matters!

Notwithstanding Rule #1, the “heft” of the BRM role – the weight and implied authority it carries does matter.  There’s a couple of reasons for this:

  1. BRM’s are often on a CIO succession path (either explicitly or implicitly) – i.e., have the skills and wherewithal to be a CIO down the road, and the BRM role may be seen as a developmental step.  This has implications for who you chose to fill BRM roles, and for their career paths.
  2. The story a CIO tells the business executives when establishing the BRM role is along the lines of, “I am giving you one of my senior staff members to help surface, shape and manage IT demand so that you get the highest possible value from IT investments and assets. In return for this ‘gift’ I expect you to treat this BRM as a member of your management team.”

As a result, the most common reporting relationship for successful BRM’s is directly to the CIO.  In some cases, the BRM has a dotted line relationship to the senior business executive for the unit they represent.  In other cases, the BRM role is solid line to the senior business executive and dotted line to the CIO.

Rule #3 – Context Matters!

There are many other contextual factors to consider here, including:

  • What is the scope of the BRM role – is it primarily demand management (shaping, surfacing and managing business demand for IT)?  Or does the role include supply management, service management or other responsibilities?
  • Do the BRM’s act as Project or Program Managers for major initiatives?
  • Do the BRM’s sit on any governance bodies, such as Portfolio Management or Service Management?
  • How do BRM’s engage with the supply side?  How do they engage with Enterprise Architects?
  • How mature is IT supply?
  • Howe mature is business demand?

BRM’s Can Be ‘Game Changers’!

The BRM role is a tough one to get right, but from my experience, well worth the effort!  An effective BRM can:

  1. Elevate business maturity
  2. Ensure that IT resources are being focused on the highest potential value activities and initiatives
  3. Ensure that those initiatives capture the highest possible value

 

Graphic courtesy of Linda Galindo

Related articles
Enhanced by Zemanta

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

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

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!