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.

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 Inter-relation of Project Management and Change Management

In my previous post here, regarding skills necessary for next generation project managers, I referred to an article on I also posted a question to multiple groups within LinkedIn (including but not limited to CIO magazine, Change Consulting, Leaders & Thinkers, Philadelphia Technology Group, Business Improvement, Change Management, and Turnaround, etc.) and the response has been overwhelming.

Many of you have agreed that there is a close link between project and change management. I decided to pull some of the better excerpts here.

  • I do believe that if you want to make important changes in an organization, a complete turn-around or a transformation, then it easily gets diluted if you do not run it as a project. Considering people’s adversity to change they will find every opportunity to avoid changes or go back to their former way of working. A project creates a solid framework, with measureable milestones, progress reports, focus on areas where change does not happen according to the objective, and subsequent corrective measures.
  • A project by definition is a special endeavour that is different from routine work. Anything which is new and people are not used to, will require change management for its effective implementation or delivery of its intended results. However, the scope of the project and its impact will determine the change management required. On the other hand Change Management is again by definition is something special and hence can be considered a project and needs to be run like a project even though some of the outcomes of a change management initiative are qualitative and difficult to quantify. More visionary leadership is required for a change management initiative.
  • Any change program of a certain magnitude must be managed as a project.
  • I totally agree that to change the mindset of the people really need people who have influence or leadership qualities ,who can drive the ideologies in such a way that people start accepting those ideas.The success of any Project lies on the shoulder of leader as to how influential or diplomatic he or she is to drive people for change without much resistance I agree that individuals need to have willingness to change but my experience is that Strong leaders first create strong team then show the positive aspect of the desired changes to people,influence people to accept changed environment,motivate people in such a way that they are willing to accept any change and then establish informal communication channel with grass root level people and then simply put across the formal roadmap of any Project.
  • Both Project Management and Change Management are disciplines. Both are managing a transformation from current reality to a desired future state. Any initiative that is responsible for the development and/or delivery of something significant will require a Project Manager to drive planning and execution. The question that most people struggle with is “when is a change management track required along with a dedicated Change Manager?” The answer lies with “behavior”. The more that the project’s deliverables require a change in human behavior, the greater the need for Change Management. (Ex. The delivery of new spreadsheet software to people who use spreadsheets, simply requires some user training. However, an initiative that changes business process and the roles, responsibilities and procedures expected of people is expecting new behaviors and requires more than training classes.)
  • Most projects are initiated to change something and therefore, change management should an integral part of what is done to ensure success.
  • The ultimate value of any project rests with how well the change is absorbed in the organization. All successful projects I have seen tend to have incorporated some level of awareness that the transition from the ‘as is’ state to the ‘to be’ state will involve change and have – to some degree – proactively planned for the need to understand and manage that change throughout the project.They should be joined by the hip. I can’t recall any project that I have run where the organisation I was delivering the project for wasn’t prepared for the implementation in terms of communication, training etc.
  • …it is hard to imagine any kind of significant change that would not benefit from being managed as a project.
  • Change is constant, project is the boundary we draw to manage it in a phased approach.
  • Project management is a discipline that is about delivering change. Organisational change management is a closely related discipline that is also about delivering change.
  • They are related inasmuch as you have many Project Managers who have been involved in “change” initiatives and many Change Managers who have been required to “project manage”. That said my view is that they should not be related but complimentary. Why? A Project Manager is the owner of a plan that is milestone driven whilst a Change Manager has the unenviable task of winning hearts and minds and changing culture which cannot be milestone driven. Ideally the PM and CM should compliment each other in the context of a project. First and foremost I am a Change Manager and my Project Management skills are secondary to what I do.
  • Change management is also studying the impact of any change. It is also about continuous re-inventing.
  • Formal plans and statements contribute to this process. But these consistently fail to address crucial aspects of real-world organisations that managers experience every day. Other, ever-present features of organisational life – such as the impact of power and politics, the importance of informal processes, and the implications of paradox – tend to be dealt with superficially or ignored altogether.

And, I am only through about half of the feedback! This is clearly a topic of interest across a broad group of individuals.

I believe the two modes of thinking are related, and probably best described as “co-dependent”. While some comments focused on technical change management, most folks articulated the concept of project management providing a “blocking and tackling” approach to driving incremental organizational movement in a direction that is different from where an entity is today.

I prefer to think of project management as one important technique to enable change. In itself, it is not sufficient. Project Management is effective as breaking up a large problem into smaller digestable pieces. My team and I have a saying to refer to this phenomenon “How do you eat an elephant? One bite at a time.” Some methodologies I have been exposed to encourage “a series of small successes.” These are all project thinking models that help us digest large scale changes.

Change Management (in the cultural / transformation sense) becomes necessary based on the magnitude of the change the project is driving. Sizing the amount of change, can be a challenge. I use the framework from this blog entry to contextually appreciate the change at the enterprise and project level. When more of the domains are involved, more change management is required.

In closing, I would like to share a final word on management vs enablement. In our transformation approach, we have implemented and built out a project management system (processes and tools) to manage the business and IT related projects. We are driving large scale change into a company using project management as one technique. We also realize that project management, while important, is not sufficient in isolation to drive a business transformation. A broader framework is required. We view Change Management as a broad all-encompassing concept with multiple capabilities required to conduct a successful transformation. Along side of program & project management, we are building out a “change enablement” capability as well. I am not convinced that one can manage change like one manages projects. In textbooks and theory, we can definitely defend an approach to managing change like managing a project. However, in reality, its not that “black and white”.

We are breaking down our business transformation into a series of measure outcomes using project / program management techniques and dealing with the softer aspects of change via change enablement. When the size of the change impacts are broader than the business capability and technical enabler domains, (ref. this model) a much more entrepreneurial model is being applied to address the strategy, cultural, competencies, and structural domains. Our enablement serves as the “grease on the corporate gears” and facilitates the highest level transformational direction which can then be programatically broken down into a series of small successes so that we are able to eat the entire elephant!