Leadership Skills: A Never Ending Quest

We never really arrive at the end of the road in our quest to become leaders. We may achieve leadership status in some way but it is always a moving target.

Indeed, I believe it is our own movement on a continuous basis that can enable us to maintain ourselves as a leader. One way that we can do this is by continuously evaluating our own leadership capabilities.

I have run across an interesting way to do this regular evaluation of ourselves and would like to share it along with a couple of thoughts about it. I found this simple evaluation in a “Leadership in Project Management 2007” publication of the PMI.


Here is the evaluation:

Rate yourself by selecting one of the choices “never”, “sometimes”, or “consistently” for the following six statements:

1. I verbally communicate with team members in a manner that gets my message across while grasping the message of the other person.

2. I coach and motivate my team.

3. I am able to identify different personalities on my team and respond accordingly.

4. I am able to resolve project conflict with various stake holders.

5. When crisis such as a death or natural disaster strikes a team member, I have resources and strategies to help them return to optimal levels of performance.

6. I use stress management tools to allow me to stay calm and maintain a high level of performance.

In my own experience, using these simple evaluation points is pretty to easy to do on a regular basis. I think that “regular basis” is something that we can each define for ourselves. For me, I simply do it “periodically”. And I find that it keeps my awareness of where I stand high and does influence my behavior in positive ways.

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.

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?

Meshing Technological and Organizational Change?

Programs are structured groupings of projects designed to produce clearly identified business results or other end benefits. The program focus is on all steps required to deliver business results. It is the effectively managed, blended business investment program that delivers the benefits to the organization. The program view is more powerful than many managers expect when they first see it. It has proven its worth to clients who have used it, for example to mesh organizational change with the introduction of new technologies.

Consider the example of Client A, which wanted to use new software to help in its effort to decentralize some of its human resource (HR) activities. The department wanted to reduce the long chain of handoffs for many HR operations, typically beginning with HR associates from different departments moving to HR managers and then the central recruiting department and then back to the associate. It believed a new HR software package would provide the solution. At first, it looked like a vision of technology-driven change.

The new system would drive a radical decentralization of responsibility to various HR departments handling everything from approvals, compensation packages to processing of payroll and online forms for vacation approvals. This would be inline with pressure to streamline the department and reduce HR operating costs, all while improving the level of HR service to employees. Changes would be required at the individual, department and organization level.

It did not take long for the department heads to realize instinctively what the Benefits Realization Approach makes explicit. The benefits being targeted were not inside the new package. And there was a big difference between a new technology that drives organizational change and one that enables change - along with many other elements of the business system. These were questions, in particular about people and organizational issues. Would people feel threatened by the software project? Would employees perceive the decentralization as extra work for them?

Department leaders diagnosed the problem early. They realized this was a business transformation initiative with broad scope and impact. A Benefits Realization approach was used to expand a potential silver bullet project into a well-rounded change program. The program manager included not only steps to introduce the new software smoothly, with appropriate coaching, but also these key projects: preparing a detailed communications plan for all stakeholders groups, holding department vision workshops, developing transition plan with well-definef accountabilities and organizing discussions and feedback sessions.

Today this is one of the most successful programs at Client A. Meshing the Technological Change with Organizational Change lead to the success. Managers and Leaders need to take a large mental leap to understand the program view. They need to embrace the benefits mind-set that sees investments in IT as part of blended business investment programs rather than stand-alone IT projects.

How to Lead Change?

The amount of change has grown tremendously over the past two decades. The nature of the economies forces organizations to reduce costs, improve quality of products & services, locate new opportunities for growth, and increase productivity.

Change is the inevitable truth of our lives and whenever human communities are forced to adjust to shifting conditions, pain is ever present. However, most organizations struggle with this change and loose out If however, a careful change management plan is devised and executed successfully, a lot of pain and failures can be avoided.

Here are a few steps/guidelines to be established before you run a successful program within an organization:

1. Establishing a sense of urgency

• Examing the Market and competitive realities


• Identifying and discussing crises, potential crises or major opportunities

2. Creating a Change Team with Change Agents

• Putting together a group with enough power to lead change


• Getting the group to work together like a team

3. Developing a Vision & Strategy

• Creating a vision to help direct the change effort


• Developing strategies for achieving that vision

4. Communicating the Change Vision

• Using every vehicle possible to constantly communicate the new vision and strategies


• Having the Change team role model the behavior expected of employees

5. Empowering broad-based action

• Getting rid of obstacles


• Changing processes or structures that undermine the change vision


• Encouraging risk taking and nontraditional ideas, activities, and actions

6. Generating short-term wins

• Planning for visible improvements in performance or "wins"


• Creating those wins


• Visibly recognizing and rewarding people who made the wins possible

7. Consolidating gains and producing more change

• Using increased credibility to change all systems, structures, and policies that don't fit together and don't fit the transformation vision


• Hiring, promoting & developing people who can implement the change vision


• Reinvigorating the process with new projects, themes and change agents

8. Rewarding, recognizing & championing the benefits to the organization from the change

• Creating better performance through customer and productivity oriented behavior, more and better leadership and more effective management


• Articulating the connections between new behaviors and organizational success

Value of IT and Program Management

It is very unfortunate that most IT systems are built on the principle of "Build it, and the benefits will come". It is assumed that the desired business outcome will happen automatically through faith.

I have seen this more that once. "Hey lets build a portal, and customers will come and use it". Sometimes I seriously start thinking about the "Value of IT" or it has just become cost of doing business rather than adding strategic value. Very often we see that IT departments are so deep buried in the tactical things that they forget why they exist? IT exists to support business and if it cannot add value to the business, then is IT required?

Anyways, from a project management standpoint... this has made me realize that "Projects deliver capability & Programs deliver benefits". The concept of program goes way beyond technology. Most often we would see thatorganizations think that the role of a program manager is the one who oversees multiple related projects/project managers. There may be some truth in this statement, but program management looks at the following things:

1. Business Need
2. Technology/ies required
3. Organizational Structure
4. People
5. Process

The combination of the above-mentioned elements defines a lifecycle of a program. From concept to "Benefits Realization". Any business initiative generally involves 20% of work around technology but the remainder 80% is around Change Management. If effort is put in all aspects, the chances of success are way higher and not just blaming the technology later that it did not work out.

Improving the odds of delivering business benefits requires more than just better project management. We have to take off the blinkers and look at the full program of activities involved in changing the business system, and then manage the investment program as a whole, with full knowledge of the linkage between initiatives, reach, people and process related issues involved.

In summary, a program is the meshing of technological and organizational change. If this perspective is not maintained, I am afraid.. IT will soon loose its strategic value.