Tag Archives: program management

Driving Business-IT Convergence – The Evolving Role of the Business Relationship Manager (Part 2 of 2)


cloudIn Part 1 of this 2-part series I defined the BRM role – with the caveat that it is by no means standardized.  In fact, as far as IT Service Management standards such as ITIL® and ISO/IEC 20000 are formalizing the existence of the Business Relationship Manager (BRM) role and corresponding process as a new best practice, they are selling the role short in terms of its potential strategic impact to business.  I went on to describe the typical BRM in terms of their purposes, goals, responsibilities and accountabilities.  To the title of this post, I introduced the shift from business-IT Alignment to Convergence and why this is so important as every aspect of business strategy and operations is increasingly dependent upon information and IT.   Today, the BRM operates at the leading edge of the convergence movement – a movement being accelerated by the ‘consumerization of IT‘, digitization of everything, and by the “Internet of Things.”

In part 2 of this 2-part series, I’d like to discuss needed BRM competencies, how the BRM role changes over time with increasing maturity (of both the BRM and her business partner) and how the way that the BRM engages with the business partner shifts the nature of the relationship from one of order taker to that of strategic partner.

Typical Competencies Required of the BRM

Drives Value Realization

This might be the most important competency for a BRM.  It includes knowing how to surface, clarify and promote the best value-delivering opportunities for IT investments and assets, and how to ensure that these actually deliver on their promised value – delivered in ways that are felt and seen.  This requires skills in Program Management (with implied Project Management skills), Portfolio Management, influence, persuasion, communication, finance and organizational change.

Understands Business Environment

Driving value realization also requires a great understanding of the business, its ecosystem and its competitive landscape.  Successful BRMs have a keen sense of the top strategic business and IT issues – both short and long term, and how these issues relate to initiatives in their industry.  In short, they understand the “business of the business.”  They are viewed by business leaders as a proactive partner in finding the right solutions to business needs and not as a mere “order takers” for IT services.

Aligns IT with the Business

First, let me say that some readers will fume at the subheading.  “IT and the Business are one and the same!” they shout.  While this may reflect a laudable perspective (and one that will gradually materialize as IT-business convergence takes place) it is rarely, if ever, the case today.  Unless your business is information technology, then “business” is where profits are generated, and IT organizations work in support of that.

With that digression out of the way, alignment can be a tricky concept, and in some respects sounds inconsistent with my argument for business-IT convergence.  But alignment represents the necessary table stakes – business leaders and IT leaders need to be ‘on the same page’ in terms of mission, vision, values and goals for both IT and the business – and how these relate to each other.  Mismatches in any of these can spell disaster to the ability to build and sustain value-producing business-IT relationships, let alone converge business and IT capabilities.

Successful BRMs work closely with business leaders to predict demand for IT services and to manage that demand.  They take the lead in highlighting competing objectives.  They are effective at managing the flow of demand through negotiations and seek to iron out demand/supply disconnects between IT and business leaders.  Most important, they constantly seek ways to foster convergence – empowering business leaders – teaching them to fish, as it were, rather than always fish for them!

Manages Relationships

Any role with the word “relationship” in the title has to imply a high level of competence at creating, sustaining and developing strong relationships among stakeholders – especially between business units and the IT groups that support them.  Relationship skills do not come naturally, and are not easily developed in some people.  Effective BRMs are able to build and maintain relationships with senior IT and business leaders.  They are seen as a value-added participant in strategic business-level discussions (i.e., worthy of a “seat at the table”).  Successful BRMs are not shy in speaking up when the demand for IT services outpaces supply ability or capacity.

Manages Organizational Change

Another tough set of skills and behaviors to master!  This requires deep understanding of the organizational levers for making change (people, process, and technology) and how IT and business strategies translate into practical plans of action for change.

The successful facilitator of change engages in discussion with IT and business leaders on the intended and unintended consequences of change, and is willing to confront senior executive sponsors if they are not “walking the talk” and proactively leading the change themselves.  They understand the total cost – both technical and human – of end-to-end implementation.  They can surface the hidden costs and potential obstacles that could derail the change.

They have the ability to identify key stakeholders at the outset of a project, to assign decision-making roles, and ultimately hold leaders accountable for results.  They think and act in terms of outcomes, not deliverables.

Manages Projects and Programs

Successful BRMs typically have several years of project and, ideally, program management experience under their belts.  They have demonstrated competency in project management fundamentals and in the complexities of program management. They demonstrate the ability to get things done through others, even though they may lack ultimate authority.

Effective Communication

Successful BRMs are recognized for their ability to listen, speak, write and communicate clearly and effectively. They demonstrate the ability to negotiate win-win, or at least buy-in, in situations where there are opposing viewpoints.  They are effective at influencing those that they hold no real power over.  They have the ability to recognize and surface disconnects between IT and business leaders and are able to resolve problems through difficult confrontations.

Financial Savvy

Successful BRMs have good knowledge of finance and accounting – they know their ROIs from their NPVs and know how to build a business case that is compelling.  They understand Portfolio Management and have at least basic knowledge of Options theory.  They understand the financial drivers of the business and the drivers of the industry within which the company operates.

The BRM Maturity Journey

BRM Maturity - The Merlyn Group

The graphic above shows how the quality of the Business Partner experience grows and the BRMs maturity increases.

Ad Hoc Relationship

At the lowest maturity level, the BRM role has typically not been formalized.  As such it is being handled in an ad hoc way – the ‘squeaky wheel’ Business Partner gets the most attention.  Or, in some cases, the least demanding Business Partner, regardless of their potential to use IT for high value purposes get the most attention.

Order Taker Relationship

I see this most frequently. Typically, IT supply has been badly broken and the business-IT relationship is hostile, so the BRM role is introduced to “patch things up!”  The BRM, in her ignorance, believes the best way to improve the relationship is to say “yes” to any and all business demands.  This is nearly always a losing proposition.  IT can’t meet the demand, and if they did, there’s little to no business value to be gained.

Advisor

This is a more constructive and productive relationship, where the Business Partner sees the BRM as an advisor.  By this time, there has usually been some formalization of the BRM role and its rules of engagement.  There’s also been some level of training for the BRM – or at least some thought put into the selection of people for the role.

Strategic Partner

The ‘Holy Grail’ of BRM implementations.  This should be the clear ambition – one that is understood and shared by the BRM and her Business Partner – with the recognition that you aren’t a Strategic Partner because you say you are, or because you want to be.  You reach that elevated position because you’ve earned it – and because your Business Partner sees you that way.

IT Matures as the BRM Role Matures

At the risk of pointing out the obvious, the BRM role does not act in isolation.  It is inextricably linked to IT supply.  If IT supply is broken, the BRM role will be limited, and might not even make it to Order Taker.  This, from my experience, is a common situation.  Things are bad, so the BRM role is introduced.  Unless supply improves, the BRM is doomed to failure – and may actually make things worse.  Promises are made and expectations set that cannot be kept.  On top of lousy supply, the BRM is seen by the business partner as ‘overhead’ – yet more evidence that the IT team is clueless, always adding cost without demonstrating value!

To reach the Holy Grail of Strategic Partner, IT supply has to be excellent – both with steady state services (networks, email, help desk, etc.) and with solution delivery (projects and programs).  The “strategic” BRM needs IT supply to work flawlessly.  IT supply needs the BRM to suppress low value demand while stimulating demand that delivers real business value.  That way, everyone is happy and a virtuous cycle is sustained.

Image courtesy of TradeArabia

Related articles
Enhanced by Zemanta
About these ads

What’s Really Meant By Business-IT Engagement and How Do You Achieve It?


This is another post triggered by a reader’s question emailed to me.  Here’s his question (some details have been omitted to preserve anonymity).

I was searching for information around Business-IT engagement but have yet to really come across anything with substance.  I’m looking to better connect with the business unit managers to formulate an IT strategy. The unit managers have a track record of operating in their own silos, often making IT decisions without talking to IT which has ultimately cost the company money.  I was thinking about putting a plan together to engage. Structured via, face-to-face, email, social media, newsletter and even survey. Ultimately, from start to finish, I build the picture and connect and portray the message that IT is an enabler and there is benefit in engaging.  I wondered if you knew of anything which may help me?”

This is an interesting question and a common challenge.

What Do We Mean by Business-IT Engagement?

A little research into the term “Business-IT engagement” found a reference to “Employee Engagement“, which Wikipedia defines as:

An ‘engaged employee’ is one who is fully involved in, and enthusiastic about their work, and thus will act in a way that furthers their organization’s interests. According to Scarlett Surveys, ‘Employee Engagement is a measurable degree of an employee’s positive or negative emotional attachment to their job, colleagues and organization that profoundly influences their willingness to learn and perform at work’. Thus engagement is distinctively different from employee satisfaction, motivation and organisational culture.”

I don’t think it’s an unreasonable stretch to derive from this a definition of business-IT engagement:

Business-IT Engagement exists when business unit leaders are fully involved in, and enthusiastic about their IT capabilities, and thus will act in a way that furthers the business value of those capabilities.  Business-IT Engagement is a measurable degree of a business executive’s positive or negative emotional attachment to their IT capabilities, IT colleagues and IT organization that profoundly influences their willingness to participate in the use of IT for business value.”

IT Engagement Model

I also found an IT Engagement Model from our friends at the Center for Information Systems Research:

The IT engagement model is defined as the system of governance mechanisms that brings together key stakeholders to ensure that projects achieve both local and company-wide objectives. The model consists of three general components:

  • Company-wide IT Governance – decision rights and accountability of company level and business unit level stakeholders to define company-wide objectives and encourage desirable behavior in the use of IT
  • Project management – a formalized project management process, with clear deliverables and regular well-defined checkpoints, that encourages disciplined, predicatable behaviour for project teams.
  • Linking mechanisms – processes and decision-making bodies that connect project-level activities to the overall IT governance.

The Linking Mechanisms are further explained in the following graphic:

I find this to be a pretty comprehensive and easily understood way to define some of the major aspects of Business-IT engagement.

Key Business-IT Engagement Factors

The other key factors I pointed my reader to include:

  • The experience your unit managers have with IT – do they trust IT? Has IT served them reliably? Is there transparency into how IT charges?  Is the business value of IT recognized and celebrated?
  • How engaged are business and IT leadership with each other? Does the CIO sit on the Management Committee? Is there an effective business-IT governance board and related processes and structures?
  • The skills of those in the business-IT interface role (Business Relationship Managers, or BRM’s) – how well do they understand the business? Do they have good relationship skills? Are they co-located with the business unit leaders and sit in on business management meetings? Do they perform a business management role, or are they simply seen as technical people taking care of IT?  Are they primarily responsible for Demand Management?

To the balance of his question, I asked:

  • Are you really trying to formulate an IT strategy? Or is it going to be a business-IT strategy. (If I’m a business unit leader, why should I care about or want to be involved in an IT strategy – it sounds rather internal to IT to me, so I’d probably want to stay out of it – I’m busy enough as it is!)
  • Do you really understand the business problems and how IT can contribute to solving them? If you do, what’s the best way to “market” those ideas, and to whom should you be marketing them?
  • What are the cultural norms in the business – do ideas drift down from the top, or do they percolate up from the edges – the ‘front lines’?

Outside-in Versus Inside-out Thinking and Acting

Finally, I was troubled by an aspect of the language my reader used in his question:

I build the picture and connect and portray the message that IT is an enabler and there is benefit in engaging”

This is what I call Inside-out thinking – “We (IT) are good and can help you so you should engage with us!”  I think my reader might be on a better path to engagement if he can identify the specific business issues and needs and communicate how IT might contribute to addressing those issues and needs.

Don’t Engage – Empower!

Just as I was finalizing this post, Zemanta did its usual thing of suggesting links and related articles.  (I really like Zemanta – it’s been one of my little blogging secrets for a while!)  Among its suggestions for articles was Don’t Engage Employees, Empower Them!  I think that is an important dimension to Business-IT engagement – especially in this age of IT consumerization.   Too many IT leaders see there role as ‘protecting the business from the perils of IT.’  Empowering them – for example, Bring Your Own Device (BYOD) can be a powerful way of bringing the business into the business-IT dialog and engaging them in strategic and tactical dialog and decision making.

Graphic courtesy of The Social Workplace

Related articles
Enhanced by Zemanta

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

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

Are Your Processes Setting You Free? Or Holding You Back?


Early in this blog’s life, I posted quite a bit on ‘sticking points‘ that IT organizations find about mid-way through the journey to high Business-IT Maturity.  Process discipline can be one of the quintessential such sticking points.  Process management can get you out of the mess of Low business-IT maturity to a mid-level, but simply cranking up the degree of rigor and discipline will prevent you from getting to high maturity.

Three Ways to Abuse Process Discipline

  1. Forgetting that the heart and soul of process thinking is Process Improvement.
  2. Process becomes a substitute for thinking, rather than an aid to it.
  3. Not everything lends itself to detailed work processes.

Let’s examine these.

Come Back Deming – All Is Forgiven!

When the likes of Deming and Juran began spreading the gospel of Process Thinking, they weren’t talking about creating a process and freezing it in concrete!  The ‘Deming Cycle‘ – Plan, Do, Check, Out – was all about continuous (and sometimes, discontinuous, as in process re-engineering) process improvement.  And yet many IT organizations somehow leave this aspect behind as they institutionalize worksteps, activities, deliverables and milestones.  People are encouraged (forced”) to follow the project management methodology or systems development life cycle, and punished for violations.  For a while, things improve – some process is generally better than no process!

But then people begin to realize that the process seems to get in the way – inhibits agility.  Intelligent choices are held victim to the process, and bureaucracy reigns.  To get past this sticking point, people need to understand, believe in and be passionate about process improvement.  Be it incremental, stepwise improvement or breakthrough re-engineering, the missing ingredient of continuous improvement is essential to getting the intelligence back into the work and non-value-adding activities out of the work – especially if these inhibit speed, agility or quality.  The trick is to throw out the ‘bathwater’ of blind rigor without throwing out the ‘baby’ of process management discipline.

Three Ways to ‘Standardize’ for Repeatability and Predictability

Many years ago, my esteemed colleague Roy Youngman was co-authoring a book with me (Development Effectiveness: Strategies for IS Organizational Transition) and pointed me to this great work by Henry Mintzberg.  If a goal is to make work consistent, repeatable, predictable and of high quality, there are three ‘degrees of freedom‘ that can be tackled – the tasks, the deliverables, or the people.  The degree to which you ‘standardize’ within this mix is a function of the nature and complexity of the work you are trying to achieve.

For highly complex work (think brain surgery) the emphasis is on the people, which is why surgeons go through years of training, board certification, residencies, and so forth.  It’s no use handing them a detailed process to follow and expecting an untrained person to achieve a quality result.

For work such as bridge building, the emphasis will be on the deliverables – various types of blueprint, work breakdown structures and so on.

For routine, sequential work, the emphasis will be on defining the tasks to be followed and the sequence in which to follow them.  Ideally, the work can be so ‘routinized’ that it can be automated.  (Think data center operations and the shift over the years to ‘lights out’ data centers.)

The graphic below tries to capture this concept.  Detailed processes are great at helping manage work that is routine and sequential in nature (which is one of the reasons why ITIL has gained so much traction in the last few years.)  For work that is inherently collaborative, and may require more visual enablement, standardizing on deliverables may be more apparent (think discovery and solution delivery).  For work that is more complex and exploratory, think training and performance support.

Some Process Management Questions To Ponder

  • Are your IT processes holding you back – or setting you free?
  • Are they an aid to thinking, or a substitute for it?
  • Is it time to move past the blind discipline of mindless processes to a more context-sensitive and effective approach?
  • How often to your processes improve, and where is the impetus and insight for those improvements coming from?
  • How are process improvements recognized and rewarded?
  • Is it clear who owns ‘improvement’ for any given process?
  • Is it clear who owns the ‘services’ that are delivered by given processes?

Answers on a postcard, please!

Enhanced by Zemanta

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!

Why a Good Business Case or ROI Analysis Doesn’t Ensure Value Realization


business-case-mouseI find that most companies I work with nowadays are pretty good at insisting that business requests for IT solutions are accompanied by a robust business case that surfaces all the costs (including total life cycle costs), expected return on investment (ROI), risks, mitigation strategies, and so on.  They have good business case templates, and often associated tools to facilitate the development of effective business cases with a consistent ‘look and feel.’

Beyond the Business Case

These things are all necessary, but are woefully insufficient to drive value realization.  In fact, they can be a trap, creating a false sense of security.  “We’ve done a solid analysis of the business case, so now we can just blaze ahead with the system and the results will naturally and inevitably follow!”   Wrong!!! It’s quite likely that the results that do follow bear little, if any, relationship to the business case.

Seven Steps to Value Realization

There’s a level of analysis, engagement, measurement, control and accountability here that is essential to driving business value and that does not automatically come along with business case development.  So, here are some techniques I recommend to help ensure value realization, not just project approval.

  1. Be deliberate and explicit on the language of ‘business case’ versus ‘value realization.’  Whether you use those terms, or other terms, differentiate between things you do/artifacts you use to analyze a project’s or program’s merits and risks, versus those things you do to drive value realization.  They are both critical to success, and many more people do the business case well than do value realization effectively, which is a shame – leaves lots of money on the table!
  2. Get really clear on costs and value and accountabilities for each.  Each accountable party should be a party to the value realization plan, and sign up explicitly for their part.  See my earlier post, Lack of Accountability – Who’s Dirty Little Secret?
  3. Don’t limit value realization to financial return.  Get explicit about the “value system” at play in your organization.  ‘Time’ may be an important value (e.g., this will reduce new product time-to-market from 6 months to 4 months through…). Quality may be an important value (e.g., this will reduce defect rates from 1% to 0.25% within 12 months enabled by…)  Employee engagement may be an important value (e.g., this will increase overall employee engagement scores as tracked in our annual engagement survey from 85% to 95% within 12 months due to…)  As long as it is an important value, and can be quantified in terms of degree and time frame, and can be measured, it is meaningful to value realization.   Even if you can’t predict with accuracy or precision what a 10% increase in quality is worth, you can measure it and learn the relationships between intermediate outcomes and financial implications over time.
  4. Figuring out the value system and the outcomes and intermediate metrics and goals is not easy.  Therefore, it is a great opportunity to engage a broad audience of stakeholders in figuring the metrics out.  This not only ‘spreads the load’ but engages stakeholders in the value realization conversations.  Sometimes, it surfaces problems and opportunities early on, while there’s time to do something about them.  For more on this, see my earlier post on Measuring the Business Value of IT – Where You Can Win by Simply Trying.
  5. Once you’ve figured out the outcomes and intermediate metrics, create the measurement plan and document it as part of the program.  I don’t favor post-implementation audits as the primary vehicle for value realization assessment.  Audits are good for lessons learned, but value realization is so important, it is better if you can build the instrumentation into the implemented solution.  The difference is like designing cars where you have to get out every now and again and dip a stick into the fuel tank to figure out how much gas you have (bad), versus designing a fuel gauge into the car (better) versus designing a widget that tells you how many more miles you can travel and that sounds an alarm when you are 50 miles from empty (best).
  6. Implement the measurement plan, and take measurement seriously!  Get a senior executive sponsor who’s going to pay attention to this.
  7. Ideally, find ways to ‘close the loop’ between measured realized value and individual and/or group rewards and recognition.  This need not be money in someones back pocket – there’s tremendous power in an internal newsletter or collaboration hub celebrating the success of value realized through a system, and congratulating those associated with the program.

If all this sounds simplistic, it is – deliberately so.  I find people obsess over false precision and accuracy, rather than see this whole exercise as on of learning and growth – of driving the right conversations to increase understanding of and commitment to value realization.  Keep it as simple as you can, especially to get started.  Once you’ve got some momentum going, you can get more sophisticated if you feel the need (and the value!)