Tag Archives: program management

You’ve Got Information Technology Questions? We Have Answers…


athinaAs an IT professional or IT leader, do you find yourself with questions or issues you’d like to get opinions about?  Of course you do.  As a consultant, researcher, educator and author, I get questions all the time.  For me they are my oxygen.  If the questions ever stopped, well, I frankly don’t know what I’d do!

At the risk of coming across as arrogant, after 15 months of blogging and 166 posts, I sometimes find myself opening up my blog and entering a search term in which I’m interested in the search box in the banner, and using my own blog to remind myself what I’ve written about, or that others have commented on regarding that topic.  Often, the search comes up with some useful information – sometimes with some helpful link or insight.

So, here’s a suggestion – next time you have a question, or a topic of interest related to IT organization, governance, value realization, architecture, ITIL, CMMI, or emerging leading practices, give my blog a chance.  See how it holds up as a repository of useful nuggets.  Let me know – if it works for you, or if it let’s you down.  Let me know how to make this blog a more useful resource for you.

About these ads

How Many “Top Priorities” Does Your IT Organization Have?


flowersA recent client experience reminded me how IT leaders in lower maturity shops love to show off their extensive project lists – it’s almost like a badge of courage!  The bigger the list, the better!  It’s as if, “The busier we are, the more we are doing for the business.”  I’ve found over the years that the busier the IT shop seems to be based on the size of the project queue, the less satisfied tend to be IT’s business partners.  While IT leaders tout their extensive project lists, the business partners complain that “IT costs too much and delivers too little!”  How can this be?

There’s several things wrong with the picture characterized by long project lists:

  1. First, long project lists typically reflect an IT organizational tendency to think in terms of “projects” rather than “programs.”   Projects reflect an IT-centric view, focused on work effort, budgets and schedules. Programs, on the other hand, at their best represent packages of interdependent projects that collectively deliver business outcomes of importance – programs represent a business view, one that is more oriented to value delivered rather than the typical project orientation work effort, budget and schedule.
  2. Long project lists typically do not lend themselves the to clear alignment with business strategy and strategic intents.  Programs stand a far greater chance of achieving that.
  3. I’m always suspicious of huge lists (often hundreds) of projects as a representation of the work of the IT organization.   They often reflect a “everything is top priority” mindset, and from my experience over years of consulting, are symptomatic of a confused management agenda.

Hopefully, one of the by-products of the current recession is that IT organizations will have every reason to get focused on “the few really big things.”  How does your project list look?  Would your business partners recognize how it aligns with top business priorities?  Does it make your organization simply feel busy?  Or, does it make it feel valuable?

The “Unwritten Rules” of Project, Program and Portfolio Management


thumbsup4.jpg

Among the most popular posts on this blog is that of October 15 on Project vs. Program vs. Portfolio Management.   Less popular (but give it time…) have been my posts of the last couple of days on Unwritten Rules of Business-IT Maturity.  I want to use the latter to illustrate the former, and some of the dysfunctionalities common to Level 1 and Level 2 Business-IT Maturity. 

I’ve argued before that Project Managementis a ‘foundation discipline’ primarily concerned with producing agreed deliverables, according to an agreed time-frame and within an agreed budget.  (I know this is an extreme simplification, but bear with me – there are more important points to make than nitpicking the details of project management practices.)   I’ve further argued that Program Managementbuilds on this foundation discipline that is primarily concerned with managing groups of inter-dependent projects in order to deliver agreed business outcomes.  As such, program management is outcomes focused, rather than deliverable focused, and is concerned with project inter-dependencies.

So, here’s an example of Unwritten Rules that drive Project Management behavior, but not Program Management behavior:

  • “Whatever you do, make sure you deliver on-time and within budget, and you will do well.”
  • “You’ve got to balance scope, time, resources and quality – to be successful in this organization, never let time or resources exceed budget, and don’t drop quality.  If something is going to give, let it be scope!  You can always fill in missing scope in a later release.”
  • “Installing the software is our job – keep focused on that – anything else is a distraction, and is beyond your control.”
  • “Never let a project fail – it will be the end of your career here!”

Let’s compare these rules with the kind of unwritten rules that drive behavior in an organization with a strong focus on program management:

  • “The business outcomes determine scope and define success – if you partner with the business folk, and work towards achievement of those outcomes, you will be successful and will be recognized for it!”
  • “If you believe that the program you are leading is not set up for success – i.e., is not going to deliver on its business outcomes within the available budget and resources, you have to speak up and confront the program sponsor.  Silence is not an acceptable behavior.  Meeting deliverables deadlines and budgets is worthless if we are not realizing the business outcomes!  Killing a program that is not going to deliver on its outcomes is a valued behavior here!”
  • “Everyone understands that project estimating is an uncertain activity.  Don’t take shortcuts to meet unrealistic deadlines.  The business outcomes are everything, and if the program is sponsored properly, and you have frank and open dialog with the sponsor and the team, and raise issues as soon as they are recognized, then estimates can be legitimately revised in the light of experience.”

For all of the Project Management training, certification, investment in sophisticated tools and Project Management methodologies, the Unwritten Rules first listed above are the ones I see most frequently, leading to poor project performance, low realized value from IT investments, and a generally weak relationship between IT and the business it serves.  Where I’ve seen the second set of Unwritten Rules – those more commonly associated with Program Management behavior, I’ve seen an organization that is either at, or is heading towards Level 3 Business-IT maturity, and enjoying high realized value, and a mutually productive and satisfying business relationship.

Take a moment – talk to some of your more experienced project leads, have them read this post, then ask them candidly (anonymously, if necessary) to describe the “Unwritten Rules that drive project behavior.”   Are they what you would want?  Are they what your CEO would hope for?  Would they delight your CFO?

I’ll take a similar look at IT Portfolio Management in my next post.

From ‘Supply Constrained’ to ‘Value Constrained’ Business-IT Model


One of the difficult paradigm shifts that tends to trap IT organizations in Level 2 Business-IT Maturity is the notion that business demand must be constrained by IT supply.  Demand always exceeds supply for IT capacity, so the idea (part of the Level 1 experience) is to set a limit on IT supply, then figure out some way of prioritizing demand against that supply capacity.  Sometimes the the constraining mechanism is IT budget, other times it is IT headcount – either way, the net effect is the same – a bunch of work that the business wants won’t get done, and we hope the prioritization mechanism works sufficiently well that the “right” demand is flowing through and getting address, and the “wrong” demand (low business value) is not.  I’ve rarely seen this work well.

If there is a single line of business, at least demand can be prioritized across the business line, and the mechanisms to achieve this are not too hard to implement.  Typically, however, there are multiple lines of business, and while the mechanisms in each business line may work ok, there are rarely effective mechanisms across lines of business.  This leads to all sorts of dysfunctionality, especially as the enterprise matures and shifts towards more of an integrated business, with common and shared process, compared with the more functional and stove-piped model typical at Level 1.

For example, IT resources get “walled off” against business units – sometimes actually being embedded in the unit.  There’s nothing inherently wrong with the embedding – certainly some IT capabilities (such as Relationship Management) work most effectively when they are really close to the business).  However, when analysts, designers, developers, testers, etc. get “walled off” for given business units, they are no longer available to be shared across the enterprise – they creates all sorts of inefficiencies.  And, from my experience, with the best will in the world, and with competent, well meaning people both in IT and the business, demand will fill that available “walled off” supply no matter what.  A result is that lots of relatively low value and non-essential demand gets filled, while high value demand, both within the business unit with the walled off resources, and in the other business units sits in a backlog (at best) or, more typically, just does not get surfaced because people know there is no hope of getting it filled.  A symptom of this is an IT organization with literally thousands of active projects, mostly small, and with a general sense that IT costs a lot of money and delivers little value.  Such an environment presents all sorts of challenges to real business-IT strategic alignment.

The big breakthrough comes somewhere in Level 2 where there is a shift from this supply constrained model to one that is value constrained.  Let me first describe the theoretical end state of the value constrained model – we will explore the practical realities of moving to this model later on.  At the theoretical end point, IT supply is treated as an infinite resource that can flex its capacity on demand – ramp up to meet high value demand, ramp down when that demand goes away.

The key enablers to move to this model (once the paradigm shift is understood and desired) are to:

  • Prioritize demand based upon business value (which has all sorts of implications for business cases, cost and value accountability, value measurement, portfolio management, etc.)
  • Create an agile and flexible supply capability (which typically means there is a robust global sourcing strategy and management model, key partnerships with global sourcing entities are in place, and the IT organization has become focused exclusively on “core” IT capabilities – usually encompassing relationship management, demand management, value realization, business process improvement, innovation, program management, portfolio management and global talent sourcing.)
  • Add an IT Program Management layer over IT Project Management
  • Add an IT Enterprise Portfolio Management layer over IT Program Management
  • Elevate IT Architecture to Enterprise Architecture
  • Implement an effective business-IT governance model to facilitate cross enterprise and cross business-IT decision making.

I will explore each of these enablers in subsequent posts.

Project vs. Program vs. Portfolio Management


I mentioned in the last post the shift from project management to program management as one of the many important shifts in business-IT maturity that typically take place around the middle of Level 2 (in a simplified 3-level model).  I want to explore that in greater detail in this post, and connect it to Portfolio Management which I see as a key discipline in getting to Level 3, and to extracting high, visible business value from IT investments.

A recent post, Programs are More than Just Big Projects, by colleague and friend Roy Yougman in his blog http://www.ryoungman.net/ inspried me to discuss Program Management as a critical link between Project and Portfolio Management.  In a simplified sense, project management deals with a single project (be it small or large) with a focus on producing agreed deliverables, to an agreed schedule and budget.  Program management deals with multiple projects that collectively produce an agreed business outcome – i.e., they have inter-dependencies (e.g., impact the same group of stakeholders, each contribute to achieving a business outcome, and depend upon each other to do so).  It is the management of these inter-dependencies against the delivery of the agreed outcomes that distinguishes program from project management.  I have to acknowledge that the terminology here, though well defined in the project management literature and sources such as Wikipedia, is not universal or used consistently.  In the aerospace/defense industry, for example, programs have a different connotation more related to funding.

If projects can be thought of as the bottom of a hierarchy, programs sit above them in the middle of the hierarchy and address a related set of projects, then things get to be most interesting at the top of the hierarchy – the portfolio management level.

My favorite source on IT Portfolio Management are Prof. Peter Weill and his co-author, Marianne Broadbent.  Their first book that addressed this topic was Leveraging the New Infrastructure: How Market Leaders Capitalize on Information Technology.  There are various IT portfolio models around – the reasons I like Weill’s are:

1. It differentiates the IT investment in common, shared infrastructure (broadly defined).

2. Weill has years of benchmark data showing how portfolio allocation varies by industry, and how it reflects business performance.

As I get personally closer to retirement, like many boomers, I give increasing attention to my (meagre!) personal investment portfolio, which makes personal investments and portfolio theory a great analogy for IT investments.  My portfolio goals have changed over time as my circumstances have changed (e.g., putting a kid through college, getting closer to retirement).  Whatever those circumstances, I’ve had the discipline (thanks to an investment advisor) to annually re-think my portfolio strategy, to be explicit about it, and to monitor the performance of my portfolio against that strategy, and adjust periodically.

In the IT portfolio domain, the same is necessary.  How much of our IT spend should be leveraged across the firm?  (By the way, a common challenge is the funding mechanisms for common infrastructure are often weak – another Level 2 trap is that funding in Level 1 and early Level 2 tends to be by the project, and for given business units – nobody likes to fund cross-business unit initiatives!)  How much should we be spending on “risky” but potentially high value initiatives?  How much on informational (business analytics/decision support)? 

Another Level 2 trap is that a firm’s earliest entree into IT portfolio management is typically limited to new spend.  However, the reality for most enterprises is that new IT spend represents less than 30% of total spend, so there is bigger value in applying IT portfolio management to the steady state services (bringing us back to Service Management mentioned in an earlier post)

My key points through all this are to get through Level 2 to Level 3:

1. You need great project management as a fundamental discipline.

2. You need great program management as a bridge to portfolio management.  You can’t easily go from project to portfolio – there are just too many projects, and projects are focused on deliverables, whereas program focus on business outcomes – which is what portfolio management needs to focus on.

3.  The biggest impact in terms of advanced IT practices comes from portfolio management (the IT investment strategy), and if you are weak in project or program management, you will never get the full potential of portfolio management.

More on the Sticking Point


As I get ready for a week’s vacation in Aruba (lots of Scuba diving and time with my family!) I want to explore a couple of more aspects of the “sticking point” that I see IT shops bogging down in as they mature from Level 1 business-IT maturity towards Level 3.  The sticking point is at the inflection point in the middle of Level 2.

I talked in the last post of the shift in Enterprise Architecture from an IT-out, bottom up perspective, to a business-in, top down perspective.  This is the type of shift that does not work by just “working harder at EA” or by throwing more resources at it – it takes a significant shift in approach.

Getting out of Level 1 into Level 2 is mostly about rigor and process discipline.  Process Management, CMMI and ITIL are the types of formal disciplines that bring order to the chaos of Level 1.  These all make sense – in fact, are essential (these, or similar process methods) especially given that much of the work of maturing from Level 1 is about cleaning up the IT infrastructure (“getting the trains to run on time” or “keeping the lights on” as the metaphors go) and implementing enterprise solutions (ERP, for example).

The trick in getting through Level 2 and to Level 3 is not so much to throw out the disciplines that got you out of Level 1, but to apply it in a much more selective and gentle handed way.  The types of business problems and solutions that are common in the higher reaches of Level 2 and dominate Level 3 are more about business experimentation, and less about rigorous formal specifications and requirements management.  While project management continues to be a foundation skill, program management and IT portfolio management become key in Level 2 and the Scientific method becomes an important alternative to requirements management.