Why you need a change management strategy?

A "one-size-fits-all" approach is not effective for change management.

For a moment, think about these changes:

• Acquiring a company of near equal size
• Getting suppliers to use a new web-based form and process
• Relocating office spaces within an existing building
• Implementing an Enterprise Resource Planning solution
• Reorienting around processes instead of functions
• Releasing a new product
  

These are all distinctly different changes, but each requires change management to be successful. Each impacts people and how they do their job. Each can suffer from slower adoption and lower utilization. Each has risks associated with people not becoming engaged or resisting the change.

While each of the initiatives needs change management to be successful, the right amount and approach for change management will be different. The change management strategy defines the approach needed to manage change given the unique situation of the project or initiative.

Three key elements form a change management strategy

1. Situational Awareness - understand the change and who is impacted
2. Supporting Structures - team and sponsor structures
3. Strategy Analysis - risks, resistance and special tactics

In my next article, I will talk more about each of these elements and will present that with a help of an example from one of my current client engagements. Hope that will be useful for anyone managing/leading an initiative that requires fundamental organizational change.

Presenting at the upcoming PMI SAC Conference

I am quite excited about the opportunity of speaking at the upcoming PMI conference in Calgary on November 23rd.

Here is the link to the event and my presentation abstract:

http://www.pmisacconference.com/dnn/Program/MondaySessionsandWorkshops/tabid/156/Default.aspx

My topic is:

"Aligning & prioritizing Projects/Initiatives with the corporate strategy using Balanced Scorecards".

Specifically, I will be addressing:

'Doing the right projects or performing projects right! What is more important?’

Every organization has to decide at regular intervals which projects/initiatives they should execute and which ones they can delay. Also, are these projects aligned with the corporate strategy?

More specifically, do you need to answer any of the following questions?

1. What prioritized projects, services and products to concentrate on for the next 3-5 years to achieve maximum business success with resource and budget constraints?

2. How do I balance different stakeholder opinions before I build a roadmap?

3. How do I know that my roadmap/strategy is best aligned with corporate goals and is offering minimum risk for realization?

To answer the questions above, I will present an intelligent approach as well as a software toolset which uses Balanced Scorecards and Mathematical Optimization to rank and select projects for the PMO to balance various stakeholder needs, satisfy resource constraints and align with the corporate strategy.

I have successfully implemented this approach at 2 clients and elements of this work have been published in a paper at the International Conference on Software Engineering (ICSE 2006, Shanghai, China).

I will be highly honored if you can make it to the session on Monday, November 23rd from 1-2 PM.

The Difference between Project and Program Management

I see many of my clients struggle with this on a regular basis and there is a general mixup between a project manager, program manager and a system/process operations manager.

Here are some quick observations:

From juggling balls to juggling jugglers with balls!

I think you can liken Project Management to juggling a set of balls (projects) and ensuring your hands and brain is acting quick enough to keep them all in the air, whereas Program Management feels like you’re co-coordinating several jugglers, who all have lots of balls in the air, and you need to manage the jugglers passing balls to each other on a very regular basis!

You really do need to look at and take in the bigger picture and overall strategy, without this larger view and forward planning; the ongoing projects won’t be aligned strategically for both the business and IT.

More strategy, less dirty hands

This doesn’t necessarily mean you don’t EVER get your hands dirty again in the joys of managing projects on a daily basis, as you do have to do this as well! It just means that you tend to have to step back a bit more and let other specific project managers or business team members run the daily stuff, while you just ensure strategy and alignment of overall goals is still on course.

Negotiation and High Level Support

You’re here to manage and deliver a program of work, which may involve 50 projects, all intrinsically linked (or not) and all with their risks, issues andinternal/external problems. I’ve found my leading change, resolving, negotiation, peace-keeping, support skills being put to the test on an almost daily basis.

A communication conduit

In Project Management, you need to be able to communicate effectively between the project team you’re working with, the client and any teams you are supporting, and finally the project board.

With Program Management, your communication channels are much more diverse and far reaching, you basically have to communicate right up tothe top levels for Concept, Benefits, Progress, Delivery and Review. While working with the ranging projects that are under the program umbrella, ensuring all teams are clear on goals, direction and status.

Finally you have to ensure that there are clear communication channels between any projects that are linked into your program projects, and be a conduit for information, strategy and knowledge.

Change

The project manager tries to keep change to a minimum, and controls change requests and scope creeps with an iron fist. Of course thanks to Agile Methods that project management is more open to changing environment.

Program management on the other hand is about expecting change, even embracing it at some levels, and being adaptable and flexible enough to run with it without jeopardizing the projects under your umbrella.

Conclusion

Project deliver a certain capability, whereas Programs deliver business benefits!

I think Program Management is far more then managing a group of related Projects. Program Management starts with a clear definition of business need and goals at a high strategic level and from there develops into a roadmap, or Program, as to how best satisfy the business needs. Of course aligning it with company strategies is key.

The roadmap should articulate how each Program and the Projects within each Program connect, the relationships, dependencies and data / information management. The roadmap should also be visited periodically to embrace the changing conditions.

Would love to get some more thoughts on this...

We Need to Change?

The process by which we decide “it is necessary to change” doesn’t change much from one person to another. While that might sound like an outrageous claim, it really doesn’t do more than state the obvious.

For the purpose of this article we’ll restrict the discussion to the Change motivated by a desire to avoid an unpleasant outcome. That covers a wide range of scenarios ranging from implementing a new accounting system, acquiring some level of quality certification, or merging with another company.

At the beginning, the need to change is perceived by a small circle of individuals, possibly just one person. How this happens is important, as it serves as the seed from which we cultivate organizational commitment to change. Here’s our built in, instinctual process;

1) we become aware of something(1),

2) we ask ourselves, “If I ignore this… what happens? (2)

3) we evaluate our prediction(3) , “Is this good or bad for me?”

4) if we determine it is “good for us”, then we don’t do anything differently, we go about our merry way. More to the point, we will resist any imposed response because we’ve determined for ourselves that no action is necessary.

5) if we determine it is “bad for us”, then we will have arrived at the conclusion that a change is necessary. We’re not necessarily certain at this point what needs be done, but we’ve determined that something needs doing.

6) we now determine what we could do(4) , we create a list of possible responses.

7) we sift through these choices, to the best of our analytical ability(5) , with the intent of zeroing in on a single response to the perceived threat.

8) we move ahead to implement(6) our response to the threat, the thing we became aware of in #1 above.

It is an interesting journey when you analyze it carefully. More on this in the next post......

Rational Change Management

Organizational Change Management

There is no other subject more filled with hype and myth than that of Change Management.

• People state that we resist change.............and yet we get married.
• People state that resistance is bad.......... and yet it's what protects us from bad ideas.
• People consider the question "Why should I change? " almost as a form of insubordination... and yet it's what enables us to decide when change is necessary.
• People state that we must "change or die" ..... and ignore the equally true statement, "change or die!"

Here's the challenge:

We are faced with two conflicting situations

1. We must implement all change that is necessary and,
2. We must resist all change that isn't.

These are both obviously true and therefore pose a paradox and a serious challenge;

1. How can we get people to embrace the change that is necessary?
2. How can we create an environment that allows rational resistance?

PMI-SAC Award Winner - Humbled and Honored

I am very excited and humbled to receive the "Project Management Excellence as an Individual - Business & Information Technology" Award from the Project Management Institute, Southern Alberta Chapter (PMI-SAC).

I feel deeply honored as this award recognizes Project Management Excellence of an individual throughout his/her career and accomplishments in the various areas of Project Management ranging from Project Management, Program Management, Portfolio Management, Strategic planning, Change Management and so on.

It was a great night of celebration and I would like to thank all my guests who came out and attended the dinner and cheered me up. Many many thanks to the PMI-SAC chapter for recognizing all of us nominees as professionals who continue to work with a lot of passion and excel in delivering projects for their clients

Leadership Styles

Which Leadership style do you follow?

Program Strike Zone

Program Managers have two primary roles - managing the business associated with the program, and leading the program team to success. The program strike zone is a key tool for managing the business aspects of a program. It is utilized to identify the critical business success factors of a program, to help the organization track progress toward achievement of the key business results, and to set the boundaries within which a program team can successfully operate without direct management involvement.

As shown in the figure above, elements of the program strike zone include the critical business success factors for the program, target and control (threshold) limits, and high-level status indicator. The thresholds serve as the dividing lines between program team empowerment and executive management intervention. A green indication signifies progress is as planned, yellow indicates a heads up to management of a potential problem, and red requires senior management intervention to proceed.

Managing a program is like having a rocket strapped to your back with roller skates on your feet; there is no mechanism for stopping when you're in trouble. The program strike zone is such a mechanism that is designed to to stop a program, either temporarily or permanently, if the business success criteria for a program are compromised.

The program strike zone is also a powerful tool for senior managers, They can set the boundary conditions for a specific program tighter for an inexperienced team or a program characterized by a considerable degree of risk. On the other hand if, if senior managers have confidence in an inexperienced program manager and team that possesses a consistent track record of success, they may set the boundary conditions with a wider margin in order to provide the team a greater degree of flexibility to move more rapidly to improve time to market.

Continuing on Program Management: What is a Program Roadmap?

The Program road map is an information display that visually shows the time phasing of the programs within the portfolio. Most company's development appetites exceed their available human and non-human resources to convurrently develop all products, services or infrastructure solutions. The purpose of the program roadmap is to balance the anticipated market timing of programs under consideration with the available resources of the firm. The road map appropriately reflects what is possible and practical over time. The figure above shows an example of program road map for a software development organization.

The Program road map is a dynamic tool in that it should be updated regularly to reflect the current market and customer environmental conditions, along with the current availability of resources within the firm. It provides information for program managers on the high-level timing expectations by senior managers for their program.

Program Managers must work within the time constraints as specified by senior management in order to plan and utilize the company's resources most efficiently. The road map also becomes a primary communication device between program managers and the functional department managers to whom company's resources normally directly report. In this context, the program road map is primary planning tool during the early stages of the program lifecycle.

What is a portfolio MAP?

Portfolio Maps are information displays that visually show key parameters associated with balancing and managing portfolio of programs. They provide senior managers with the information needed to decide how to distribute their investment in the programs as they pertain to the parameters represented on the program map axes as shown in the diagram above.

These discretionary business investments are based upon their unique standing in the overall portfolio. Each new opportunity is evaluated as to its potential net present value and its associated probability of success.

Program Managers can gain insight into where and how their program fits with the overall portfolio of programs by referencing an organization's portfolio map. Senior management decisions concerning the programs (such as budget and resource allocation) will vary depending upon where a program sits within the portfolio in accordance with its projected return vs. risk. The portfolio map helps put these decisions in context of the overall business strategy for program managers.

Portfolio maps also provide program managers power to influence senior manager's decisions if their program sits in a positive position within the portfolio, such as the "Pearls" quadrant in figure above, where programs are providing high financial value at relatively low risk of failure.

PMI-SAC Award Nominations

A great opportunity to nominate project managers who deserve recognition for the fantastic work they have done. Also, check out the keynote speaker. I definitely look forward to this event!

For more information, please visit: http://www.pmisac.com/

Recovering from Service Failure

As IT service providers we often come across service failures, some of which happen consistently. This isn't necessarily a disaster for the CIO or the IT service provider. If the service recovery - the actions taken in response to the failure - is handled well, then customer/user satisfaction, trust and loyalty can actually increase. I have actually seen it quite a few times and even though proactiveness is always preached and feels good to say in theory, but reactive actions are almost always rewarded.

Service failures are always occurring - but what matters more are the actions taken to recover from the failure, which have multi-dimensional impacts on the IT department. Indeed, service recovery is the acid test for customer orientation: if an IT shop or the CIO does not excel in this, then it is not customer oriented.

Good service recovery can build commitment and trust between the IT department and the users, which increases user satisfaction and loyalty. More importantly, business starts to feel that IT is delivering what business wants, whereas at a lot of companies in Calgary I hear that IT and business work in their own silos.

Even though it may seem like a paradox, the whole experience can generate more goodwill for the IT shop that if nothing had gone wrong in the first place.

In contrast, service recovery failure - even for a relatively minor incident - can increase customer dissatisfaction and frustration. This makes them more likely to say negative things about the IT's ability to deliver.

So the question is whether recovery is proactive?