Key IT Roles for Driving Business Value

Contract-to-Hire-BlogI’ve posted at length about the Business Relationship Manager (BRM) role as being key to driving business value from IT. But what other roles—typically under-served—work with the BRM in the pursuit of business value from IT?
In this post, I am going to introduce three dimensions of value realization than are important to driving business value. Along with those dimensions, I will discuss three roles that are associated with those disciplines.

Note: This post refers to roles. A role is not the same thing as a job. Think of a role as a ‘hat’ you wear if you meet certain qualifications (possess certain competencies). When you are qualified to wear a given hat, you have certain responsibilities and accountabilities. Roles, the competencies they demand, the processes in which they participate, and the ways they engage with other roles are all characteristics that are defined in an IT Operating Model. Some people will fill multiple roles, depending upon circumstances and needs.

Three Dimensions of Value Realization

So, how does IT increase its impact on Business Value Realization? There are three major value sources that the IT organization can impact:

Screen Shot 2014-06-26 at 1.21.31 PMLet’s examine each of these dimensions.

Shaping Business Demand

At low maturity, an IT organization is often referred to as “order takers” for business requests. One the face of it, this sounds customer-centric and responsive. However, the reality is that at low maturity, much  business demand yields relatively little business value. It’s also the case than when the business client has already figured out what they need before the engage IT (or if the business client has depended upon external consultants and vendors to tell them what they need) then the IT organization’s opportunities to add value are very limited.

If an IT organization is able to engage with their business partners earlier—to be proactive, not simply responsive, they can stimulate, surface and shape demand towards higher value opportunities. And these high value opportunities tend to suppress demand for low value activities, so more people are working on high value opportunities.

Shaping business demand is an important discipline for increasing IT maturity, and with it, driving more value from IT. Associated with this discipline is the role of Business Relationship Manager (BRM)—a role that sits between an IT organization and its business clients. In leading practice organizations, the BRM role (or whatever label it goes by) is focused on demand management, with an eye to elevating business value of IT.

Leveraging IT Assets and Information

At low IT maturity, much effort goes towards establishing a supportive, reliable and predictable infrastructure and the business applications that depend upon that infrastructure. Typically, these business applications go significantly under-leveraged. The cost, effort and business disruption associated with their deployment tends to lead to a mentality of “declare success and move on!” The business users need time to get back their breath. They also need to be shown new ways to leverage the platforms and the mountains of information they generate. Also, while IT organizations typically do a good job maintaining these business applications, there is no single role focused on managing their total lifetime value.

In order to increase maturity, architectural and asset management disciplines must be established around business applications, so as to create business platforms and products that enable business process improvement and innovation. Platforms are inherently extensible and readily leveraged—think about the iPhone as a platform, with open, published Application Programming Interfaces (API), the Apple Store and thousands of apps available to run on that platform.

The role responsible for these architectural and asset management disciplines is referred to as Product Management, and is an important aspect of reaching higher maturity and driving business value—ensuring that the full potential value of Business Platforms and Products is exploited and harvested. The BRM role works closely with Product Managers to help create the business appetite for new business capability that leverages the underlying business platforms and products.

Optimizing Business Use

While low maturity IT organizations focus on building, implementing and maintaining business solutions, as maturity increases the focus expands to help optimize the business value realized though using these solutions. This depends upon the discipline of Value Management, which in turn leverages competencies in Business Change Management and Portfolio Management.

There are several roles that are involved in Value Management—that of the Business Sponsor for a given initiative, Portfolio Manager, Business Change Consultant and, again, the BRM with their focus on demand management and business value realization.

In future posts, I will explore each of these disciplines and roles, and how these can be established as part of your IT Operating Model.

Note: My next on-line BRMP Certification courses are being held across 3 Mondays—July 7, 14 and 21, 2014 and 3 Tuesdays—September 2, 9 and 16 . For details, please click here.

Image provided courtesy of



How Good are your IT Capabilities and How Good do they Need to Be? – Part 2

This is the 2nd in a multi-part post on assessing IT Capabilities.  (See Part 1)

A Quick Recap

Part 1 introduced some assessment principles I’ve found to be important.

  1. The Process is more important than the results.  I’ve found facilitated self-assessments to be the most effective.
  2. The results must be actionable. An assessment must give you insight into what needs to be improved, with what urgency and in what sequence.
  3. The results must be multi-dimensional. For example, address performance, value delivered and health of a given capability.
  4. Process-based assessments only go so far – and may in fact be misleading! Not all IT Capabilities are process-based.  Some depend more on standardization of deliverables or the outputs produced by a capability, and some depend more on special skills and training. Concluding that a given Capability might be highly mature or highly immature might have nothing to do with its ability to deliver excellent results!

Capability Defined

There are several aspects to defining Capabilities:

  1. What is meant by “IT Capability”?
  2. What is the potential landscape of IT Capabilities?
  3. How do you know what IT Capabilities you need?

Let’s examine these in turn.

What is Meant by “Capability”?

Wikipedia defines Capability as:

The ability to perform actions. As it applies to human capital, capability is the sum of expertise and capacity.”

A couple of things to note about IT Capabilities:

  1. While Capability Maturity Models such as CMMI put processes as the central construct of a capability (and the key to capability maturity assessment), in practice not all IT Capabilities are inherently process-centric.  Some depend more on people’s skills and competencies (think Business Relationship Manager, for example) while others depend more on deliverables than they do on specific processes.  (For a more detailed treatment of this distinction, see Part 1 in this series or my earlier posts on Henry Mintzberg‘s seminal work on organizational constructs.)
  2. You don’t need to “own” any given IT Capability – you can “rent” it as in outsourcing or contracting, for example.
  3. Not all IT Capabilities exist in an IT (or IS) organization.  Some are embedded in business units or other organizations.  For example, the capability to chose, procure and maintain personal computing devices may belong to the business – think “Bring Your Own Device” or “BYOD” as this rapidly growing movement is often referred to.

What is the Potential Landscape of IT Capabilities?

I’ve covered this topic in some depth previously in my posts on IT Organizational Clarity, but as a quick recap, below is a normative, high-level IT Capability Model.

Normative IT Capability Model

One can debate the specific labels for each of these capabilities, but essentially, any enterprise that depends upon Information Technology to any degree needs each of these IT Capabilities.  Of course, the devil, as they say, is in the detail, and the detail exists in the drill-down decompositions for each of these high-level IT Capabilities.  We will get more into this in Part 3 of this series.

How do You Know What IT Capabilities You Need?

There must be a clear and explicit linkage from Business Strategy to needed IT Capabilities.  There are many methods for achieving and expressing this linkage, and this is the realm of strategy formulation.  At its simplest, a given Business Strategy will require a set of Business Capabilities.  In turn, most, if not all Business Capabilities will depend upon one or more IT Capabilities.  Common techniques for achieving this linkage include:

But, IT Must Not Only Satisfy Business Demand – It Must Stimulate and Shape Demand!

The big danger with most strategic alignment methods are that they are inherently reactive.  i.e., To enable “x” business capability or strategy, we need “y” IT capability.  But how do you know that the business strategy is properly informed by IT possibilities?  This is where the first in the Value Chain Capabilities (see graphic above) comes into play – Discovering Business-IT Potential – and where the role of the Business Relationship Manager is so key.  So, you don’t just need the IT Capabilities the business thinks it needs – you also need IT Capabilities that create IT “savvy” and equip the business to understand and fully exploit IT potential.

Coming Up Next…

In Part 3 of this series we will examine assessment dimensions and methods.

Graphic courtesy of LipheLongLurnERrdok

Enhanced by Zemanta

You Know You’re Process Centric When…

As a management consultant, I’ve come to believe over many years of experience that poor process discipline is at the heart of many performance issues.  More to the point, I find an incredible amount of misunderstanding about the nature of process thinking and process management, and outright denial that process management is in any way lacking when it clearly is!

I’ve written before that listening to how clients talk about things can be illuminating, so allow me to share with you some of the things I hear people say about process discipline, what it reveals about their biases and how these misconceptions get in the way of good performance – and, more importantly – get in the way of performance improvement.

A Bias for Continuous Improvement

First, let me state my own biases.  I was trained as an electrical engineer, and started my career in computer hardware design.  A training in engineering disciplines forges a strong and deeply held worldview about the way things work.  On top of this, by the random chance of meeting and being influenced by certain people, I came to be a believer in the Total Quality movement, and in the teachings of Deming, Juran, Shewhart, et al.  For a period in my career I was a judge for a Malcolm Baldrige type quality award for the software industry.  So, I do see the world through a lens of process discipline and continuous improvement.

I later came to work with Professor Tom Davenport, a brilliant colleague who exposed me to the world of business process re-engineering.  This approach has brought enormous benefit to the world, but I do regret the fact that along the way, it somehow trumped the quality movement.  “Don’t improve it – blow it up!” became the mantra.  While in many cases, this was the right thing to do, unfortunately, the “Don’t improve it!” part rose to prominence.

“We Do Have Process Management – Our Process are Documented!”

This is one of the first clues to listen for as an indicator of process mis-perception.  There’s a couple of traps here:

  1. If we’ve documented the process we are using process management discipline.  Wrong!  The fact that it’s documented does not mean that it’s being followed!  That would be akin to claiming, “All our citizens follow the laws of the land because those laws are documented!”
  2. A central tenet of process management discipline is continuous (and, sometimes, discontinuous) process improvement.  Having a process documented does not mean it is continuously improved – and may in fact be an inhibitor to improvement!

“Process Creates Bureaucracy!”

Another clue to process cluelessness!  Yes, if the process management approach is disproportional to the nature of the work being performed (e.g., a highly detailed process model for an activity that is either trivially simple, or is essentially skill-based) then it does become bureaucratic and unhelpful at best, or even dangerous.  (Imagine someone who is not a brain surgeon being handed a process model for brain surgery and being expected to remove a small growth from their spouses brain!)

“We Want Our People to Be Creative, and Process Stifles Innovation!”

A couple of years I posted on the distinctions and interrelationships between Improvement and Innovation.  Process management, intelligently applied, as one of the core management disciplines is an enabler of innovation, not a stifler!  My former colleague Tom Davenport used to say, “Process sets you free!”  And he was right – and he had the right perspective within which to apply process thinking.

“We Are Masters of Escalation!”

Escalation – the final clue!  I find that organizations that don’t have good process management typically have great escalation capability!  They have to – in some respects, great escalation is almost a sign that process management is weak.

How about your organization – are you really good at process management?  Or are you simply good at process documentation and escalation?


Cartoon courtesy of Savage Chickens

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

Do You Have IT Organizational Clarity?

This is the first in a series of posts on the subject of IT Organizational Clarity.  The general concept of  Organizational Clarity is clearly laid out in Patrick Lencioni‘s wonderful leadership fable, The Four Obsessions of an Extraordinary Executive.

I believe that Organizational Clarity is particularly important for IT leaders today as IT management and operational roles are increasingly dispersing throughout the business rather than being performed within a homogeneous IT organization.

There are a zillion analogies for illuminating what is meant by, and the importance of Organizational Clarity.  One that resonates for me is rowing boat racing. I attribute that to growing up in the UK and getting excited about the annual Oxford and Cambridge Boat Race (I lived on Oxford Gardens in London, so it was always clear which team I was supporting!)  The sight of a rowing boat, with 8 rowers and a coxswain sitting at the rear, steering and uttering commands to help the crew keep the cadence and stroke rating, is a compelling image.  When all the rowers are in perfect harmony and staying on course, there is enormous power in the boat.  If the coxswain screws up, or any of the rowers don’t follow the instructions, havoc reins and the boat slows way down or goes way off course.  I think of IT organizations that lack organizational clarity as the slow boat, or even worse, the fast boat heading in the wrong direction!

Common Symptoms Reveal Lack of Organizational Clarity

From my consulting and research work, I will assert that the symptoms of the lack of Organizational Clarity are common and prevalent.  How often do you or your colleagues say or hear:

We Don’t Communicate Well!”

Not only has virtually every client I’ve worked with raised this complaint, but I don’t think I’ve ever seen an IT organization that claims, “We communicate really well!”

This is a non-trivial symptom.  It leads to redundant work, leakage of business value (i.e., value that should have been captured, could have been captured, but is not captured) and a general sense of confusion and disorientation.  For the beneficiaries of IT work, it contributes to a poor customer experience – “The left hand doesn’t know what the right hand is doing!”

We don’t have clear accountability!”

This is another common symptom – failure to be clear on who is accountable for what, and, more to the point, what happens when something goes wrong.  This is often (and unfortunately) referred to as, “Not knowing who’s throat to choke!” but is probably more constructively thought of as, “Not knowing what actions to take to ensure that this error is never repeated!”

This symptom also means that managers and individual performers often do not understand how their work contributes to the overall mission and vision for the IT organization, and, more importantly, how it contributes to the success of their internal and external customers.

We exist to support the business!”

This common misunderstanding leads to the ‘order taker’ mentality, and an IT organization that is always extremely busy (to the point of rampant overwork!) and yet is seen by the business as adding little to no value.

Don’t Attempt to Address the Symptoms Directly!

It is essential to recognize that these are symptoms and not root causes in of themselves.  You cannot solve the communications issue by mandating or even organizing for better communications.  I’ve lost count of the number of IT leadership teams I’ve worked with who talk about putting a marketing/communications specialist on their staff “to address the communications problems.”  I’m not saying this is necessarily a bad idea – I’ve posted before about the importance of bringing marketing skills and disciplines to IT management.  But adding such a role with the purpose of ‘fixing communications’ rarely, if ever, works.  Communications problems are symptomatic of a lack of Organizational Clarity – not just for the IT organization as a whole, but for its ‘moving parts’ such as IT Infrastructure, Enterprise Architecture, Solutions Delivery, and so on.

Similarly, you cannot address the accountability issue by simply trying to mandate accountability.  Unless a given IT Capability has clear goals, service definition and guiding principles, and the appropriate processes, roles, competencies, tools and technologies are in place, it’s little use trying to tie accountability to anything!

Two Dimensions of Organizational Clarity

Improving organizational clarity – and in turn increasing focus and effectiveness – must be tackled along two dimensions:

  1. Bounding scope appropriately, or defining the ‘unit of analysis.’  An appropriate unit of analysis is commonly referred to as “an IT Capability.”  Typical IT organizations can be described through 7-9 Capabilities, such as IT Infrastructure, Enterprise Architecture, Opportunity Discovery, Solution Delivery, Portfolio Management and so on.
  2. Defining Capability Characteristics, including Purpose, Commitment, Ability and Accountability.

In the next couple of posts, I will drill into these two dimensions as a means of describing IT Organizational Clarity and how to measure and achieve it.

Image courtesy of What’s Running You

Enhanced by Zemanta

Unsure of Yourself? – Debate the Trivial!

Thanks to my colleague Roy Youngman for suggesting the theme of this (very short) post when we were comparing notes on past consulting clients.  Our discussion was about why some are so satisfying to work with while others can be so frustrating.  By the way, as I write this I am well aware of the tendency for consultants to sometimes engage in “client bashing.”  I became aware of this early in my consulting career, and was mentored early on by a very seasoned consultant who was always quick to recognize this behavior, and came down on it quickly and forcefully.

This client has shown trust in us and has engaged us to help them.  Complaining about them behind their backs is not helpful and can be potentially disruptive.  Any time you say “The client just doesn’t get it!” you are pointing to your own inadequacy in helping the client to ‘get it.’  So stop bitching and figure out how to help the client!”

A Caricature of Frustrating Client Behavior

This is a caricature of the kinds of discussion and debate we sometimes witness in our less mature clients.  The specifics are fictional – the general tone is real!

Consultant: “This is the role interaction model we are suggesting for the points of engagement between business demand and IT supply – where your Relationship Managers, Business Architects, and Solution Managers interact with their business executives to surface or explore new opportunities.”

Client Executive #1:  “I think the arrowheads should be larger!”

Client Executive #2:  “I’m not so sure about that – I was thinking they should be smaller!”

The meeting continues and becomes increasingly heated, often veering way off track.  The meeting (which started late) never produces any clarity around this important issue.  The 40 minutes of actual time we can wring out of a scheduled 1-hour meeting surfaces no light – just heat, as trivial and largely irrelevant issues get debated, while the important questions are dodged or swept under the table.  The meeting wraps up with an acknowledgment of the need to schedule more time to get into this important topic.  Unfortunately, the ‘important topic’ in question is the size of the arrow heads!

Of course, this is a caricature, and in some respects an exaggeration of the specifics.  And you could fault the consultant in this case for allowing the dialog to go so far off track.  But in many ways, it is real.  We have found time and time again, that clients who are unsure of themselves around a given topic will sometimes be quick to debate trivial points, sometimes ad nauseum, rather than wrestle with the real issue.  Over the weeks we are working with this type of client, significant chunks of otherwise productive time are wasted on trivial debates as a means of deflection and obfuscation.

Are You Debating the Trivial?

What proportion of your management discussions are around issues of significance rather than the trivial?  How does this tendency impact overall IT performance?  What can you do to change the behaviors underlying this dysfunctionality?

Image courtesy of Amrit Williams Blog

Portland’s Street People and Well-Managed IT Organizations

Yes – I can connect the unlikely subjects in this blog’s title.  But bear with me a few sentences to set the context.

I recently posted on my time in Portland, Oregon, and my love for the city.  I also mentioned the anomalous ‘street people’ scene.  Portland is so squeaky clean and seemingly well-run, and yet it seems to tolerate a thriving street person scene – some bordering on aggressive pan handling.  I personally never felt threatened by this, but it was strange that these misfits are so tolerated.

From Portand’s Streets…

A recent Portland Tribune front page article asked, “Would Rudy Giuliani Put Up With This?” under a picture of a lavishly tattooed street person sitting in front of a rather blunt epithet I won’t quote on this blog.  The article recounted the history behind the remarkable street and crime clean-up that took place under Rudy’s watch.  The article said:

Then, in 1994, Police Chief William Bratton and Mayor Rudy Giuliani, within a matter of months instituted Draconian measures that changed the (New York) street culture in ways that remain in place today.”

The article goes on to recount:

Bratton, who initially led the transit police, first cracked down on subway turnstile jumpers and panhandlers – arresting them.  In the process, they found that many of those arrested had outstanding warrants for more serious crimes.  Making quality-of-life arrests on the subway reversed the momentum of declining ridership… and created a momentum that allowed law-abiding New Yorkers to reclaim public transportation.”

…to IT Meetings

So, what’s the connection to well-managed IT organizations?  I’ve noticed over years of consulting that well-run IT organizations pay attention to the apparently small things – such as the discipline around scheduling and running meetings.  Meetings start and end on time, have pre-published agendas, published results, with action items and assignments.  They make sure meetings are necessary and productive, and that the right people (and only, the right people) are there.

Yes, I know we all tend to complain about “too many meetings.”  But the reality is, for knowledge workers (yes, that’s us) meetings are an important part of our work.

IT Leaders Model the Culture They Want

IT cultures are set from the top.  When the CIO and the IT leadership team pay attention to meeting discipline – modeling excellent behaviors, and calling out sloppy meeting behaviors – just like turnstile jumping, people pay attention, discipline increases, and everyone benefits.  On the other hand, when turnstile jumpers are tolerated – i.e., sloppy meetings are taken as ok, then discipline around all sorts of behaviors degrades, and IT performance drops.  I guess there’s an analogy with ‘quality of life crime.’  Being late for a meeting is not a ‘crime’.  But in terms of its impact on organizational cohesion and performance, it’s a ‘quality of organizational life crime.’  So is a lack of clear roles and accountabilities.  So is an ‘entitlement culture’ where poor performers are tolerated.

Like a well-run ship (sorry, too many analogies here!) a well run IT organization is disciplined at the most fundamental level.  It’s a manifestation of mutual respect and collective accountability.  When I turn up late for a meeting at which I’m needed and expected, I am disrespecting my colleagues.  The ones that show up at the appointed time sit there twiddling their thumbs.  It’s as if the message I want to send is, “My time is so valuable I couldn’t be here on time – and all your time is so worthless, it’s no problem if y’all sit there waiting for me.”

And, of course, late meetings beget late meetings – these things escalate.  I’m always bemused and angered when a plane is late “Due to a late arrival of the inbound flight” like that’s a valid excuse.  As an Atlantan, most of my flying over the years has been on Delta.  Each time they announce this excuse, it’s as if they are denying any culpability in the late flight.  “It wasn’t our fault – it was the damn inbound flight you should blame!”  Or, “The ground crew is not all here yet!”  So, I wonder, who was responsible for the late inbound flight?  Yep – Delta!

Enough ranting.  You get the point.  If you want to do a ‘quick and dirty’ IT Capability Maturity assessment, look no further than at how well you run IT meetings – including starting and ending on time.  As goes the meeting discipline, so goes the IT capability performance – and the credibility you have with and value perceived by your business partners!

Enhanced by Zemanta