GovernIT

PMO Series: Change Management

9CQMG4TUUK3Q

We started off the PMO series with a basic introduction about the PMO – terminologies, the different types of PMO and some of its typical functions.

Let’s talk about one very important part of a PMO function – Change Management. Change is the only constant in life – cliched? Of course, but true nevertheless. It is also one of the biggest causes of “project death” – those projects which go on indefinitely, but always overdue and a cost sink (read an extreme example of how change in scope resulted in a 12-year project that was also a massive failure!).

In a large project/program, change management becomes very important to ensure that something remains stable or atleast manageable.

Change Management has become the norm in the industry today and there are dedicated “Change Managers” too sometimes, but there is enough change mismanagement too. One of the biggest reasons for this mismanagement is because it is used synonymously with managing Requirements Change.

Managing change does not only mean managing changes to scope (“scope creep”, as it is called, but that is a creepy term). Architecture/Design decisions, standards and tools also must be controlled to prevent chaos. This is where most change management processes fail.

Let us look at some change management mechanisms and then we will revisit how change management can be applied.

Change Control Board (CCB):

One of the most common responses/techniques, but often under utilized. The CCB need not be a single, all-powerful entity, but there can be more distributed ones at different levels. For example, for large architectural changes, there can be a high-level CCB, but smaller design decisions can be changed by a lower level CCB. It is usually good to organize such mini-CCBs by the amount of control they have rather than by phase – this will create cross-functional teams at all levels, rather than more silos by function

Change Request Creation and Tracking processes:

Having a formal Change processes itself is a barrier to most spur-of-the-moment change decisions. At the minimum, change request processes should describe how a change request is created, who reviews it, criteria for escalation, stakeholders to be involved and change closure. It also needs to tie in Configuration Control for effectiveness.

Incorporating change (and its consequences) into planning:

Usually this is a fatality in most change processes. Changes to non-scope areas of the project are considered to be immune to schedule or cost effects, which is rather unlikely. Sometimes, the development team is asked to absorb the effect as the price for not understanding or doing it right the first time. Managers in charge of change control must resist this thought process or risk losing much more at a later stage in the project.

Stricter controls as Project progresses

At the start, change is more likely, since everyone is feeling around in the dark, establishing sign-posts and installing lights, figuratively, but as you progress in the project, it is important to ensure that every change request is asked “why” several times. Any change later in the lifecycle, especially with respect to decisions, is likely to affect work products already produced and accepted. A common victim of this syndrome in an application development project is the User Interface, which is thought to be like a skin – easily replaced, but is it? In services, Change is more tightly connect to configuration than with Application development, but the principle still holds true.

Having looked at some mechanisms for managing change, let us go back on how and where to apply change management. Change Management in an application development scenario can be used at:

• Scope management
• Technology stacks
• Architecture
• Design
• Standards to be followed, such as branding, user interface etc
• Third-party components
• Development environments

In a services environment, change needs to be managed for

• Hardware
• System Software (OS, standard application software etc)
• Communication equipment
• Services and their endpoints
• Processes and
• knowledge databases

Note: In IT Service Management circles, the CCB is termed as CAB, shortened for Change Advisory Board (though why it just “advises” stumps me).

That’s alright, I know this stuff, but where does the PMO fit in, you ask? PMO must be the oversight for managing change. The PMO establishes the procedures for change control and provides necessary direction to the Program on the levels of CCB (scope of change control, escalation criteria etc). It is also the final arbiter for changes to Project scope, schedule or cost.

In fact, for rescuing troubled projects, one of the first things a PMO should do is to take a hard look at the project for change leaks and based on the amount of leakage, institute an appropriate level of change control. I say “take a hard look” since it is almost guaranteed that a typical derailed project has issues managing change.

What are you experiences in managing change in your projects or services? Is there something else? Think and let me know about it.

Tags: Change Management, PMO, Program Management, Project Management

Alistair on Collaboration

Alistair Cockburn on collaboration aka teamwork

Collaboration is a dance of contribution, requiring that people alternately step forward to contribute and step back to let others contribute.

Old, on the Internet timeline, but timeless on the timeline of human endeavours.

I cannot possibly write anything on this that is better than what Alistair has already said. Maybe, some experiences/observations, but that is for a later date, when I have really understood in depth his thoughts. Read the complete post “Collaboration is the dance of contribution“

Tags: Alistair Cockburn, Collaboration

Series: Project, Program and Enterprise PMO

Over the years, the management of IT projects has evolved considerably. Project Managers managed and delivered projects, regardless of size. However, with increasing complexity of IT projects, it was becoming difficult to deliver projects on time, within budget and with acceptable quality levels.

Project Management began to be studied as a separate discipline and project management activities and skills were codified as Frameworks. Some well-known Project Management frameworks currently in use are the Project Management Institute’s PM Body of Knowledge (PMBOK) and PRINCE2.

With IT receiving more attention (much negative too), standards, planning and tracking became important to organizations. Setting up standard project management practices, oversight of plans, tracking and reporting became a priority. Thus was born the Project Management Office (PMO).

Programs got their own Program Management Office and now there is the EPMO – the Enterprise Program Management Office, a corporate level PMO that sets standards for Programs across the organization.

The role of a PMO has grown so important that it is listed as one of the roles in the RACI matrix in COBIT 4.1, the commonly used framework for IT Governance.

But the basic activities/responsibilities of the PMO remain consistent in principle, if not in scale. Some of the typical PMO activities include:

• Program and Project Planning
• Tracking
• Risk Management
• Financial Management and Reporting
• Change Management
• Staffing andTraining
• Quality Management

Based on the organization, the functions of a PMO may include other activities not listed above.  It is becoming increasingly clear that using a PMO can improve the project delivery performance, provided we know where and how to use it.

In an entry at CIO.com, Jim Vaughan discusses this issue in “Developing Your Project Management Office (PMO)”

We will look at some of the activities of the PMO in more detail in the next few posts. If you have some links of blogs, articles or whitepapers that document any of these aspects or you have some links to some templates, please share them with the community. You will receive an attribution with your name and website.

Before you leave, here is a good link for you. Download TenStep’s white paper (pdf) on building a PMO

Merry Christmas

Tags: EPMO, PMO, Program Management, Program Office, Project Management

Forrester research on what CIOs want in 2010

A long title, but that is because I couldn’t find a shorter and apt one.

In this blog by forrester research (posted on CIO.com, by the way), CIOs have identified a few things they would like to see in their organizations in 2010.

I’ll summarize the basic points here, while you can read the rest of the article(rather small, actually) here – CIOs spoke, We listened. The basic idea is to improve Business-IT relationship, which as we know is being tried since IT was considered an industry.

How do we get closer to the Business? Lets try some of these:

1. Future trends in IT:  How the next generation of technologies can change the way people interact in and with our business using technology. The Cloud (that sounds like a horror movie), social media, knowledge management etc are the areas which can rock the boat – the boat being Enterprise Architecture in this case.

2. Talent Management – Every industry is grappling with this question – How to find the best people and keep them. Of course, it is heartening to note that IT is slowly realizing that IT is still about people and not about technology.

3. Where do we stand on the scale – Like it or not, humans have reference frames which they use to judge things around them. Corporations are no different. Every senior manager wants to know how he is doing vis-a-vis the competition. This could be in terms of people, services, products etc.

4. IT Governance – Phew! I was afraid this would not be listed. Nothing need be said here, except to note that IT Governance is still considered IT’s headache. Let me reiterate, IT Governance is the Business’ Governance of IT. IT Management is what CIOs do.

5. Communicate value – Everyone needs to market their contributions and value-adds or risk being outsourced. IT still has to do better job in communicating business value, which will come only when IT is one way of doing business, which will come when business realizes the true value and potential of IT and… You get the point.

Tags: Business-IT Alignment, IT Governance, Strategic IT

Towards a uniform Service Catalog definition

Major product and service companies in the ITSM space have announced a collaborative effort to define standards for service portfolios and catalogs.

ITIL v3 introduced service portfolio, catalog, and request processes, which are the bedrock of the ITIL framework. However, there are no standard definitions of what constitutes a service, how to define and measure a service catalog etc.

The SPACL (The Service Portfolio and Catalog Language) Standards Consortium (www.spacl.info)  is a consortium formed by BMC Software Inc, Frontrange, IBM, NewScale, and Planview to formally develop a standard that is implementation-independent, open and interoperable.

The SPACL publications are still in early draft stage and open for feedback. You can download them here

IT Governance simplified

I was witnessing an interesting discussion today on what IT Governance is all about. There were a lot of quotes, including definitions from ITGI and CIOs of large corporations.

I had an “aha” moment when I heard a wonderful definition – IT Management is within the IT function, whereas IT Governance is outside it.

In other words, IT Governance is better termed as Business governing of IT to ensure IT is an enabling partner for meeting organizational goals.

Do you have a different take on it?

Tags: IT Governance

Business-IT Alignment (Yet Again)

There have been quite a few papers over the years stressing that IT has to move beyond providing services and become a business partner.

In this context, a new paper “Transformation or travails” (pdf) approaches it from a slightly different context, arguing that being a solid support to the business no longer protects IT from being outsourced – it needs to be a strategic partner in achieving business objectives.

Additionally, the topic of the IT-Business alignment has been a fixture of IT and business periodicals for over 20 years, suggesting there is significant opportunity for improvement.

In most cases, it does not even do the supporting very well, lament the authors.  IT is fixated on providing technical services, clamors for new toys, points blame on the business, lacks essential business skills and at the end wonders why they don’t have a seat at the CxO table.

In short, IT acts like a child but expects to be treated like an adult.

The paper puts forward some effective ways in which IT can become a value-focussed strategic asset and draws upon some good cases where Business used IT strategically to derive significant benefits.
An interesting approach is taken by the paper on what to expect when IT is strategically aligned – the characteristics and behaviors exhibited can be observed instead of looking at an audit-based approach. This approach is less threatening for everyone and moves away from the compliance mindset, when the organization use “standards” based frameworks.

However, in my opinion, the jury is still not on one point: do all organizations should think about IT as a business partner? In many organizations, especially those that rely less on IT for delivering products or services beyond a web site, business wants IT to remain as a solid, reliable support system. Forrester, in 2006, had a report on the three types of IT organizations currently in the world and makes the point that IT need not always be a partner. (See Three Archetypes of IT – Solid Utilities, Trusted Suppliers, Partner Players)(for purchase).

The multi-billion dollar question in this context becomes – “when should IT aspire to be a business partner?” There are a few cases where it makes sense:

1. IT contributes significantly and directly to Earnings: When products or services are sold on the company’s IT systems directly and does not involve the traditional sales channels. Of course, “traditional sales channels” themselves are becoming online channels, but in this case, I am talking about brick and mortar sales channels.

2. When there are products or services delivered only through IT: For example, a new savings account that is online only, e-books etc

3. When IT provides a level of cost savings that goes much beyond what traditional methods do: For example, just-in-time ordering systems or IT-based tracking systems.

To really drive Business-IT Alignment, every business objective must be evaluated by a cross-functional team that has an IT-aware person on board. The IT-aware person can suggest how IT can contribute towards achieving that objective. Once agreed, the ROI will be measured through standard business KPIs and hence understandable by business. All Business-IT Alignment strategies come down to this – if IT is seen as a channel for business, then you get the alignment.

To quote Andy Kyte, vice president and Gartner fellow, “None of you are in IT; all of you are in business.”

Tags: Alignment, Business-IT Alignment, Strategic IT