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!
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”:
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]](http://img.zemanta.com/reblog_e.png?x-id=2060a1ad-3041-4b55-ab44-91707d8f0f7a)
I’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.
It is useful to carve IT spending into 3 broad categories:
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.
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!
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.
(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:
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:
|
| 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. |
I’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.
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.
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:
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:
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.
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.
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.
A key role for IT leaders, especially during recessionary times, is Demand Shaping. A perennial reality in the business-IT world is that demand seems to exceed supply.
When I entered the field of IT back in the 1960′s, the term “backlog” was pervasive – that huge list of requests we could not get to until supply resources freed up. Around the same time, and partially as a result of these huge backlogs (often measured in months or even years!) time-sharing and service bureau’s were the rage. Often they would install terminals for you for free, provide access to so-called Fourth Generation Languages, data analytics, simulation and modeling tools, and let you “pay by the drink.”
Long term, this may not have been the most cost effective approach, but it let “end users” (as we called them back then) get access to the tools and computing power they may not have otherwise had access too. I remember doing some work for a large enterprise that ran movie theaters. I needed to model the economics of dividing up cinemas from single screen (which was the only model in the UK back then) into mutli-screen theaters – an approach called ‘multiplexing’ today. I used a financial modeling tool called PROSPER through a service bureau. I was learning the tool while I was building the model, so it took me a while to get it all working. I remember getting to my 30th iteration of the model before I saw the first service bureau invoice, and on seeing all the zeroes following the pound sign, realizing that, “I had some splainin’ to do” as Ricky Ricardo would have said at the time!
But the results were important to the company, and they were happy to pay the invoice without complaint as it validated a major strategic shift for them, and they became one of the pioneers of the new movie theater model in the UK, capturing significant market share from competitors, and driving great profits for many years. Had I responded to their request for the analysis with, “IT does not have the capacity just now, we’ll get to it in 18 months,” at best, I’d have had an unhappy customer. At worst, we’d have watched a competitor beat them to the punch! On-demand, cloud computing (in its earliest form) provided me the flexibility to satisfy demand without capital investment or undue delays.
Perhaps the more interesting story behind the cinema multiplexing modeling story above is how it came about. I was at the time a Systems Engineer for ICL – then the leading British computer company. I was working with a Sales Engineer. The movie theater enterprise (actually, this was just one business in a broad range of consumer businesses) was his key account, and he was working hard to convince them to buy a larger computer. He came up with the strategy of multiplexing (I think he’d been to the US and had first seen it there) and took the idea to his customer with the offer to find a free resource (yours truly!) and do the necessary modeling to analyze the financial implications. (Note the irony here that we both worked for Britain’s largest computer company and that I had to go to a service bureau to get access to the computer cycles!)
The point is, that sales executive was shaping demand for his customer – bringing ideas to create demand.
In the example above, demand shaping was through the relationship manager bringing ideas to his customer. This is a technique familiar to all of us (at least, in the US) used by pharmaceutical companies to let us know about medical conditions we may not even be aware of and for which they have a potential remedy – even if we can’t go out any by those remedies. We have to ask our doctors whether the treatment is appropriate for us.
The second method those in relationship management roles use demand shaping is when the customer tells us their ‘demand’ and we deflect it by suggesting a solution that might be of higher value, or, at least, pointing out that the requested ‘demand’ may not deliver value sufficient to justify the need. This is the more common opportunity for demand shaping, and typically the trickier role to successfully pull off. If we are not careful, it can be seen as being unresponsive or uncooperative. It might mean elevating a one-off and/or siloed need to a more enterprise-wide solution.
Anne, that’s an interesting request, but perhaps we can kill several birds with one stone if we provide a solution that addresses more than the needs of your department?”
To the customer, that might mean delays as we work through enterprise-wide governance processes, or work the politics to enroll other departments in the solution. In these cases, pushing back by the relationship manager requires intestinal fortitude, skills in the art of persuasion, and political savvy. But such is the lot of relationship manager – shifting from ‘order taker’ to ‘valued business partner’, from ‘account executive’ to ‘agent of enterprise solutions and business value.’
How often are you simply in the role of order taker? What could you do differently to position IT capability for value realization?
Over many years of preaching and teaching IT portfolio management, I’ve been frequently frustrated and disappointed by seeing IT organizations screw up portfolio management, and as a result, miss out on the significant and important benefits this discipline holds. They do so by buying into the concepts, then jumping to a tool choice, implementation, declaring success, then moving on to the next IT management challenge.
This is sad, to say the least. It typically means that not only do they not get the real benefits of portfolio management, but also they’ve spent money on a tool and implementation effort that they can ill afford, and next time when the perils associated with a lack of effective portfolio management surface, they will assume that it can’t have anything to do with portfolio management because they’ve already fixed that. So they look elsewhere, tweaking and probing, trying to figure out how to improve business-IT alignment. It might take them several years (or a change of CIO, whichever comes first) to figure out that at root, they still have a portfolio management problem. And its much harder to fix something you already think you’ve fixed!
To illustrate the point, let me describe a typical IT capability assessment engagement (I’m involved in these several times a year). The first day usually comprises interviews with the executive leadership team followed by a lengthy meeting with the CIO. In addition to describing their hopes for IT, each of the business leaders describes how and where they see the IT organization falling short. This typically includes descriptions of various symptoms of portfolio management dysfunctionality:
My unit constantly gets short-changed by IT.
I’m not a demanding kind of guy, but I get punished because IT only supports the people who always make the greatest demands – I keep getting squeezed to the back of the line!
The costs of IT are spread across the business units, but only some of them are getting real value.
IT is not sufficiently service oriented!
When I meet with the CIO, I probe around these issues. Frequently, at this point I’m told with great pride about the sophisticated IT portfolio management tool they’d implemented in the last year or so. The CIO will often grab a spiral bound report and display page after page of glossy, colorful pie charts of portfolio data. “See! Portfolio management is now a real strength of the IT organization. And we drill into all sorts of resource allocation and time tracking data in the very same tool. It’s really helped us!”
What he may as well have said was, “We took a powerful portfolio management tool and use it really well to do resource tracking and allocation!” When I ask, “How do you know that the portfolio allocation model is consistent with business strategic intent?” I get a blank look as he processes the question, followed by, “Oh, well they get all these reports! And, in fact, they can get at this data on line if they’d like – it’s all totally transparent!”
Let me explain what’s going on here through the imperfect analogy of managing one’s personal investment portfolio (I know – not a very popular thing to be reminded of just now!) It’s as if my financial planner took my savings, then sent me (or gave me access to) all sorts of fancy data about my personal investment portfolio, but had never educated me and taken me through the crucial decision-making (and regular review) of my financial goals, needs and ambitions (these are not the same thing!) and my risk tolerance, financial situation, time to retirement, and so on. Then one day I call him up and say, “Fred, I’m retiring tomorrow but see that all my savings have vanished! What happened?” And he says, well, you were in and extremely aggressive portfolio of very high risk investments, and unfortunately the market tanked. Weren’t you tracking the portfolio reports I sent you every month?” In other words, this would indicate that I never sat down with my financial planner and figured out my family’s financial strategy – made informed decisions about the right portfolio mix for my circumstances, how that mix changes over time and how I will monitor the portfolio performance. If he had taken me and my family through this process, several important things would have happened:
Translate this into the process of IT investment portfolio strategy and planning, and how this process can align the business leadership team and CIO. You begin to see the dangerous trap of confusing the implementation of an IT portfolio management tool with the process of IT portfolio strategy and management. Does you organization really have IT portfolio strategy and management? Or is it simply going through the motions of tracking spending and resources? If the latter, and not the former, what dysfunctionalities might it be causing? What will you do about it?
Back in mid-December, I posted “You Know You’ve Reached Level 3 When…“ As the BSG Alliance multi-company research project that has been examining Reaching Level 3 Business-IT Maturity shifts gears from its research to its reporting phase, I want to revisit that headline. Here are some ‘one-liners’ that are being discussed in today’s WebEx session for the participating companies:
You know you’ve reached Level 3 Business-IT Maturity when…
How do those statements feel to you? Are you already there with any of them? All of them? If you reached those conditions, how would things be different around IT decision making and value extraction?
I was with a client recently as their CIO was leading one of their regular “town hall” meetings (live meeting for those in HQ, videoconference for those elsewhere). He was talking (eloquently!) about Next Generation Enterprises, Web 2.0 technologies and the implications for their company and for their IT / shared services organization.
A question from the floor asked if ITIL (Information Technology Infrastructure Library)was incompatible with the move towards becoming a Next Generation Enterprise (NGE). It’s an interesting question. It is easy to perceive NGE’s as chaotic, emergent, free-for-alls - characteristics that seem to be at odds with the rigor and process discipline inherent in approaches such as ITIL, CMMI, 6 Sigma, and so on. There can seem to be all sorts of inconsistencies and ambiguities in the idea that, on the one hand, we are implementing all this process discipline, while on the other, we are moving to a world of rapid experiments, open networking, emergent teams, and all sorts of loose collaborations, both within the enterprise, and with customers, suppliers and the outside world.
As is often the case, I find the Business-IT Maturity lens helpful in sorting out this apparent dichotomy. In this case, I want to add another model that I find helpful in thinking through these issues, and then combine the models. First, as a reminder, below is a version of the basic Business-IT Maturity Model that has been central to many posts on this blog.
Business-IT Maturity Model
Next, I want to consider an IT portfolio model. The model below comes from Professor Peter Weill at the MIT Sloan School. It is a very useful portfolio view that classifies IT spend (or investment) into infrastructure (common and shared IT capability), transactional, informational and strategic.
IT Portfolio Model
This model divides IT spend (or investment, depending upon how it is being used) into 4 classifications. To a degree, Level 1 Business-IT Maturity is all about getting the right IT infrastructure capability. Level 2 is about getting the right transaction processing capabilities in place. And Level 3 is about the strategic and informational IT capabilities. Again, I realize this is a crude approximation, but it helps us to realize what types of IT investments we should expect to focus on as we move through business-IT maturity, and how the shape of the IT portfolio might change with that maturity journey. Putting the portfolio model on top of the maturity model creates the following picture.
IT Portfolio Mapped Against Business-IT Maturity
So, the IT portfolio can be something of a proxy for business-IT maturity. Compared against ‘average’ infrastructure spend, a Level 1 organization will be higher than average. Compared against ‘average’ transactional spend, a Level 2 organization will be higher. And compared against ‘average’ informational and strategic spend, a Level 3 organization will be higher. Now there are many issues that can distort this simple view. If your transaction processing systems are a mess of dozens of different instances of disparate systems, you are probably at Level 1, but will have inordinately high transactional spend because of all the complexity in your transactional systems. So, higher than average transaction spend may be more a symptom of lack of Level 2 attention, than a byproduct of Level 2 investment.
Finally, back to the opening question – are ITIL and NGE approaches incompatible? No, not all all – they are focused on very different capabilities. ITIL will help improve Level 1 and Level 2 IT capabilities, but do little to nothing for Level 3. If you are moving into Level 3, you need strong Level 1 and Level 2 capabilities, which leverages techniques such as ITIL and CMMI. But these same techniques will not get you to Level 3.
