GovernIT

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.

   Send article as PDF   

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“

   Send article as PDF   

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

   Send article as PDF   

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.

   Send article as PDF   

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

   Send article as PDF