IT Governance Rule #3 of 3 – Deliver Value to the Business

In this last installment on IT Governance (for now), let’s discuss the need for a “closed loop” system for IT Governance. So, far in rule #1 (make sure we are doing the right things) and rule #2 (make sure we are doing things right), we have set up business and IT to deliver successfully on the key needs for their respective company. But, how do we know that the results were actually achieved? It takes more than “earned value” or “customer satisfaction”. As change leaders, I suggest that we need an audit level of detail and proof that the business value was delivered and change was achieved.

I recently heard a statement like “51% of statisticians can convince their audience of a conclusion because they make numbers mean anything they want them to mean”. While this may be humorous to most, there is a thread of truth there. Business cases can contain assumptions, constraints, and goals of all types that are true with rose-colored glasses based on a point-in-time perspective. As projects unfold over time, how do you or your company verify that the results were actually achieved based on a new reality (not-so-rose colored glasses and a new points-in-time). Put your CFO hat on and apply the simple construct of budget, actuals, variance, and forecast across not only costs, but on benefits of a project as well. Try auditing the business case to see if the costs AND benefits (sales, revenue, cost reduction, etc.) were actually achieved, and when. And, don’t do this in a vacuum. Consistent with my previous entry regarding agile change management, get the business involved in proving the results. After all, who better then to ensure you are delivering value to the business, than the business leaders themselves.

IT Governance Rule #2 of 3 – Make sure you are doing things right

In article 2 of a 3 part series on IT Governance, if you have a capability to make sure you are doing the right things (article 1), you need to make sure you are doing them right. With this entry, lets assume you or your organization know what matters most, and your focus is  in determining how to make sure your team delivers.

What matters more, an excellent strategy or excellent execution? If you had to pick one, which would you pick? In Making Strategy Work (2005 Wharton School Publishing – Amazon link here) Lawrence Hrebinak argues that execution of strategy is the key, not strategy definition itself. I concur and this means that this second rule is more important than rule #1, and my experience across multiple industries, countries, and economies suggest the same. It is amazing how delivery of solutions or eliminating problems “takes the noise out of the system”. In my consulting days, I was thrust into many troubled situations. In these situations my clients consistently said “if you can’t deliver on what I have already contracted to you, why do you think I would give you anything else?” Makes sense to me!

So, how do you make sure you are doing things right? Some considerations (in no particular order):

  • Project Management
    • How many projects are active? Is it easy to determine the answer? If not, you have an issue.
    • For each project, what are you delivering, when will you be finished, and how much will it cost?
  • People, Process, Technology
    • Do you have the right people in the right roles (as I type this the 2010 NFL Draft is on my TV in the background)?
    • Do you have the right delivery system or processes?
    • Do you have the right technical capabilities, architectures, platforms?
  • Relationships
    • How do the business and IT relate to each other at the enterprise, project and operational levels?
    • What does the business say about IT? What are the 10 adjectives that the business would use to describe IT?
    • What does IT say about the business? What are the 10 adjectives that IT uses to describe the business?
    • What is working well?
    • What would you change if you were King for a day?

To make sure you are doing things right, it doesn’t take a PhD. It’s really more about the basics. And, what is more basic, better said – universal, than a traffic light? Red, yellow or green? English, Spanish, German, French, Chinese, Japanese, or Australian we all understand the basics of red, yellow and green. Use these universal icons to determine if you are doing things right. With this vernacular in place, manage by exception. Be hard on the red items. Watch the yellow items. And, most importantly, determine which green activities are really yellow, and which yellow activities are really red and you will stay 5 steps ahead of your changes.

IT Governance Rule #1 of 3 – Make sure you are doing the right things

In part 1 of a 3 part series, this article describes an approach with applying IT governance concepts. You can find a quick and relevant global survey on IT governance that provides additional views here

How do you know you are delivering the processes & systems that the business wants and needs? At one end of the spectrum you may rely on your intuition or the “squeaky wheel with the corner office” and at the other end you may have a mature balanced scorecard capability. How well you answer this question may mean the difference between your company’s arrival at their destination of choice or perhaps being “out in left field”.

How do you chart the waters in front of you? Having a keen line of sight for your market combined with a business model to turn a profit within it, is a good start. Some decisions will be easy. Some decisions will be hard. How do you make the decisions to ensure that you are doing the right things. In a series of bullets, make sure that you have some degree of capability to address the following:

  • Define your business strategy. The back of a napkin is on OK place to start.
  • Establish one or more roadmaps to deliver the strategy. Allow flexibility and agility within your delivery models to change your roadmap.
  • Evaluate and manage the risk associated with delivering your roadmaps.
  • Establish financial traceability of your project approval process and the ensuing delivery of your roadmaps.
  • Win fast and fail fast. Don’t be afraid to make fast decisions or change decisions.

Making sure that you are doing the right things is more important now than ever. Resources, including funds and people, are more precious now than a year ago. Building a system where “no” or “not now” is an acceptable answer requires all the bullets above at a minimum.

CIO Perspectives on Business Change

I attended a CIO Perspectives conference in Philadelphia this morning. It was a great session with a lot of relevant content. Definitely worth the investment in time.

The keynote speaker was a CIO who is leading a business transformation for a pharmaceutical distribution company using an ERP implementation as the technology driver. His discussion focused on three key elements critical for transformation, and I want to share that I emphatically agree. While there are certainly other factors in a business transformation, these three are most applicable to the CIO:

1) IT Strategy – providing multiple views of the architecture, platforms, tools, and technologies that are needed to support the business strategy.
2) IT Governance – prioritizing projects, making decisions and living with the consequences of the decisions.
3) Relationships – trust, candor, and discussing the “undiscussables”.

He emphasized relationships as a fundamental component of a transformation because it enables the the first two elements to be effective.

Here is my summary of other key concepts for your consideration in your own change efforts:

  • If you struggle to get a busines strategy to feed the IT strategy, create one yourself. IT has a great perspective of your company.
  • Commit to the integrity of the IT governance process. Don’t make side deals.
  • In order to have any transparency, you need to be able to define what everyone does on a daily basis. Put a time reporting system in. Without it, you are stuck in emotions and hallway sound bytes.
  • Trust is critical. Do you have it? Do you want it? Do you want it like you have never wanted anything else? You need to.
  • Listen without judgement.
  • Decide to make relationships important. Start with your most troubled relationship, turn it around, and then move on to others.
    Change fails because of relationships.
  • I would rather have an average strategy with flawless execution, than a flawless strategy with average execution. You can and will always modify your strategy in our current environments.

Defining Agile Change Management

UPDATE – Please be sure to check out the Change Management Manifesto as well.

How much process is too much process? How can you implement enough process so that you get the benefits (e.g. efficiency, repeatability, scale, etc.) but not too much so as to slow down your agility? The Change Management discipline / industry would be wise to reflect on the concept of “agile” from the software development industry to address these questions.

If you are a change leader, I encourage you to learn more about “agile” concepts in software development. You can easily search on the term “agile” and get a plethora of sites with information. In summary, the agile approach embraces

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Don’t take my word for it. These bullets originated in “The Agile Manifesto” at

Personally, I find agile principles serve as a helpful guideline when trying to balance the need for process. However, many people incorrectly define agile as “without process”. This is not true, and in some ways, agile techniques require more personal discipline than a classic SDLC approach (e.g. waterfall). Agile processes exist, but they live within the context of the four bullets listed above.

Processes are definitely needed, in particular for companies that have reached a certain scale. I have come to experience that “with complexity comes a need for increased discipline.” Processes are proven and worthy tools to deal with complexity in scale, speed to delivery, geographic distance, business risk (e.g. SOX), language barriers, technical barriers, human resource management (e.g. hiring & firing), financial planning (e.g. establishing and managing budgets), software development, etc.

So, in our current environment of a shrinking economy, is complexity going up or down? I say, up. Companies are forced to deal with challenges that they previously may have avoided due to success. Said another way, “success covers up many ills”. To deal with these new complexities, companies may look to leverage processes for increased productivity, efficiency, and most importantly transparency into their business. It is my assertion that, with process comes the law of diminishing returns. There comes a point where process gets in the way, and inhibits a business if process is not actively managed. How do most large entities (companies, governments, institutions) deal with the complexities listed above? They implement processes to manage risk and maintain a level of homogeneous execution across a diverse operations model. This will work, and many companies are proving their success with large scale process deployments today (e.g. look to the Business Process Outsourcing models of any big consulting firm and the existence of ERP software).

The challenge I want to address here is the need to balance process with innovation, delivery, and growth as a change leader. I am not sure there is an answer to “how much process is enough process?” but I am certain that the agile manifesto and the principles it aspires to are helpful to begin addressing the question.

The Shrinking Gap of the Back Office and Front Office

CIOs: Put Business Technology Leadership Maturity In Your 2010 Strategic Plan | CIO – Blogs and Discussion

The back office and front office of business is collapsing. Businesses everywhere are experiencing tremendous shifts in their IT usage. 40 years ago, IT was a pure back office function buried in the bowels of corporations under the head of finance and used almost exclusively for accounting and book keeping.

Now, thanks to technology revolutions including but not limited to Web 2.0, the businesses ability to engage IT services has broadened. External service providers are selling their capabilities into the business at an increasing pace. The business is purchasing simple services from external “no name” providers in order to bring speed to their operations. The “land grab” aka “gold rush” is picking up speed, popularity, and credibility.

However, it is still early. These disparate services and the increasing ability to buy into a “cloud” of computing are in their infancy stages. If you are a small company (e.g. $500M or less in annual revenue), you are most likely buying into a cloud of some form to address your economic pressures and maintain your quality of service. If you are a mid-sized company (e.g. $500 – $1B in revenue), you need to start  experimenting and probably will, soon. If you are a large company (e.g. >$1B in annual revenue), you should start experimenting, and probably need to start winding up the corporate engines to warm up to this “experiment”. Your business customer is probably already doing it, so “resistance is futile”.

I expect that concepts like enterprise architecture, standards, governance, security, privacy, and integration will remain important and only increase in significance as more and more companies buy into the cloud.

IT needs to be a better partner to the business, but that message is not new. However, the compelling reason to do so, is more real now than ever. One of the best aspects about working in technology, is the requirement for eternal learning. Those who focus on learning, thrive. Pay attention, learn, embrace the change and increase your value to the business. Business technology will help you achieve these goals, should you choose so.

Posted using ShareThis

How can you get started with I.T. resource/project allocation and management?

We addressed this exact challenge in the past year. I would encourage anyone facing this challenge to consider building a solution around two key questions to start:

1) Are we doing the right things?
2) Are we doing things right?

The first bullet is about the common notion of IT governance and prioritizing the highest value work for the company. Moving from a “squeeky wheel gets the oil” to a true business case / business value based prioritization of work makes a difference. The best part is that you don’t need fancy tools to make this happen. A basic business case approach for each project combined with a list of key enterprise class projects and organizational accountability for the mission to answer question #1 is a great place to start. Get yourself a sponsor at the top of the organization and begin building out this capability.

Second, once you have established a prioritization approach, and focused activities around the key projects, you need the ability to log time against these projects. This can be done using paper and pencil at first. I have seen 400 person programs use paper and pencil. It can be done.!The key is scale. The larger the project the more important the tool you select needs to scale. Large teams and distributed geographies present real hurdles, but the process of allocating / charging time to a project is PM101.

I highly recommend implementing a process first, and a tool second. You can always add a tool later. Tools bring costs and complexity.

Build and implement a governance, prioritization, and time tracking capability, then focus on making the capability more mature over time. If you lead with a tool, you will most likely end up selecting a tool that may or may not fit a process fit for your organization. This could torpedo your entire goal. It has happened more than once before.