Compassion is not weakness, it is a mark of a true leader

Some people believe that compassion and especially compassion in the workplace is a form of weakness. Perhaps they think survival of the fittest in the corporate jungle leaves no room for something like concern for other people and their feelings. March ahead, take no prisoners!

Yet report after report shows that us that those who have a high degree of emotional intelligence come out ahead at work. Empathy is an important part of emotional intelligence. To relate to others, you need to be able to see things from their perspective. That means acknowledging that some of your actions could be causing them distress.

Consider active listening for a minute. To have successful communications with others we should employ active listening. This involves really understanding what the other person is telling you, again trying to put yourself in their shoes.

It is difficult to successfully show empathy and active listening without caring component, you the part where you truely care what this person is experiencing?

Of course compassion is more than just understanding or acknowledging the feelings of others. It is going beyond & wishing to alleviate their suffering. If you continue to interact with others and as a leader or influencer do not try to improve their situation(where possible & appropriate), then quite frankly - you suck as a leader.

It is easy to bury your head in the sand and ignore when others are having a difficult time, it is easier to make their difficulties their fault, to feel anger at them, to blame them for bringing difficulty onto themselves. It takes much more courage to step in and take action, to actively work to improve their situations.

Compassion in workplace and on your projects takes strength & courage. Bring that to your project management style and trust me, the results are phenomenal.

Communicate Expectations The Right Way

If you hold clear high expectations for your people they may automatically rise meet those expectations. However, I might add that when you urge your teams on to greater achievement, how you urge them is as important as what exactly you urge. Great expectations can easily go awry if they're not communicated the right way. Here are a few tips for doing it right.

Declare very high expectations. Sometimes seemingly impossible goals are the most likely to be met. Ordinary expectations can be self-defeating because people realize such goals won't be hard to accomplish, so they don't try very hard. Thus you should set goals that will at first provoke the response that they can never be attained. Be clear that you are expecting something truly out of the ordinary. As you declare and continually reinforce what you're hoping for, those from whom you're desiring it will start working toward it with such a focused effort that the ball should quickly start rolling toward the goal.

Communicate your expectations clearly. Make sure that there is no ambiguity about what is expected. Describe what you're aiming for fully and in a positive way. There should be no confusion in anyone's mind about what you're demanding. If your goals and priorities are clearly articulated those who will execute them will be able to focus all their effort on attaining them.

Make sure those expectations fit their recipients. A leader should make sure that he declares the right expectations to the right people. He should consider his audience's backgrounds, abilities and circumstances before setting expectations. There is no point in setting a goal that's far removed from what someone has any experience and expertise in. Only establish expectations that have a real, strong chance of succeeding--even if they do sound impossible at first.

Communicate your expectations at every level. A leader must reinforce his expectations consistently, in both personal and public settings, formally and informally, inside and outside the organization. Every moment you spend with a person should confirm your trust that he will grow to the level you expect. At the same time, you should also make sure your high expectations for that person are reinforced by being conveyed to others inside and outside his immediate milieu.

Reconfirm your expectations constantly. Do not be discouraged when someone doesn't immediately grow to fit your expectations. Rather, continue to encourage by being clear that those expectations persist.

I am the smartest guy in the room effect!

In Greek mythology Narcissus was a favorite of Apollo and considered one of the most handsome young men alive. His beauty has been compared to Adonis, whom Aphrodite the Greek goddess of love herself, loved.The story goes that Narcissus, having come to a pool of water to quench his thirst, saw his own reflection in the smooth surface of the pool and fell in love with it. Since he could not obtain the object of his love, he died of sorrow by the same pool. The nymphs grieved the loss of Narcissus, but when they prepared his funeral pyre, they could not find his body—only the flower that bears his name. Supposedly, Narcissus still gazes upon his own reflection in the waters of the river Styx, in the underworld.

Yesterday, CIOZone caught my eye with an article they titled, Sometimes IT Leaders Are Too Smart for Their Own Good, where they suggest that, "Even the smartest person in the room can benefit from listening to others, provided those people have been chosen wisely." The author, RD Lewis calls it "Social Cognition-driven Hierarchy Level Establishment and Positioning (SCHLEP)."

He suggests, "The subject isn't emotional intelligence. People who lack that can't effectively work with other people—a related but different affliction." He suggests that these people "...don't listen because they don't see the point."Lewis asserts, "It's the intellectual version of a well-known tendency among male, muscularly-advanced high-school students: looking at their social world as a pecking order, within which they seek their level—preferably, someplace near the top—but through intellectual rather than physical pushing and shoving."

I think most people who have been in the workforce for any length of time have had to contend with a narcissistic personality at one time or another. Sometimes they are called "the smart person in the room," Lewis calls them "SCHLEPers," I just call them "Narcissists."I once worked with a guy who thought that he was the only one with any brains. He wouldn't listen to anyone and his fingerprint needed to be indelibly stamped on every initiative. In fairness, he was very smart, but his organization couldn't grow beyond what he could personally control. I didn't stay there very long.

I don't think it matters whether you are the project manager, the CIO, or the CEO—surrounding yourself with people who know things that you don't know is smart, very smart. Having the self-control and trust to actually listen to them is brilliance—and critical to accomplishing things greater than oneself.Lewis suggests that, once you "[s]tart down this path you'll discover something wonderful: Many people who are far less intelligent than you know something important you'd be wise to learn from.

It has to be this way, because no matter how smart you are, and how little sleep you think you need, you only have 168 hours in a week to add to your fund of knowledge. Line up nine decently smart employees who each spend 20 hours a week learning more about their professions, and every week one of them will know something you don't.""Most people know something you'd benefit from hearing," he continues, "You just have to help them figure out what it is."Regardless of how you manage project-based work or your particular project management software, always being the smart guy in the room just isn't a good idea. It alienates both stakeholders and project teams—and ultimately inhibits project success.What do you do when you need to work with a narcissistic personality? Or, if you tend to be what Lewis calls a SHLEPer, what do you do to foster dialog and keep from always being the smart guy in the room?

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.

Are you an effective leader?

Does being a control freak make you an effective leader? Micromanagers take perfectly positive attributes - an attention to detail and a hands-on attribute to the extreme. Either because they are control-obsessed or because they feel driven to push everyone around them to success, micromanagers risk disempowering their teams. They ruin their teams' confidence, hurt their performance and frustrate them to a point where they quit.

Here are some traits...

• Resist delegating


• Immerse yourself in overseeing the projects of others


• Start by correcting tiny details instead of looking at the big picture


• Take back delegated work before it is finished if they find a mistake in it and


• Discourage others from making decisions without consulting them

Start by asking yourself, what is wrong with that. The diagram above attempts to explain how to create an environment of energy and innovation for successful outcomes.

What is Program Governance?

The process of developing, communicating, implementing, monitoring & assuring the policies, procedures, & org structures and practices associated with a program. Program governance is concerned with controlling the organization's investment.

So, let me give you some concrete examples as opposed to just theory. Program governance ensures the "Program" have:

The Right People

• Business managers whose problems the program is trying to address
• Senior leadership sponsorship & engagement means
• Identification of skills, needs and solutions
• Common roles (e.g. Project Director, Project Manager)
• Co-ordination of PM training and mentorship programs

The Right Projects

• Identification & selection of projects
• Alignment to strategic objectives
• Rank & priority assessment
• Risk management
• Capacity management
• Balanced allocation of resources

The Right Process

• Program management framework
• Co-ordination and facilitating the development and administration of common controls, methodology standards and tools
• Align corporate processes with group/divisional processes
• Regulation & compliance

The Right Tools

• Change & communications management techniques
• Central repository for programs & projects in the corporate portfolio
• Integration of tools to improve project management capability
• Research and communicate on latest global development in thoughts, techniques and tools

The Right Culture

• Sponsorship for initiatives
• Co-ordinate and facilitate enhancing project management capability & culture
• Sharing knowledge and experiences
• Forums for project managers
• Coaching & mentoring
• Performance recognition (awards)

This is how the word "Governance" needs to translated into actionable tasks for execution so that successful outcomes can be achieved.

Outcome Management Vs. Project Management

Outcome Management is a set of methods, processes, tools and techniques for planning, selecting, managing and realizing results of benefits. It addresses: What problem are we trying to solve? So begin with the end in mind..

However, very often it is confused with project management. The table below attempts to point out some differences between the two and hopefully broadens your perspective on outcome management.

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?

What is a Program MAP?

The purpose of a program map is to show the big-picture view of the critical cross-project dependencies and throughout the program lifecycle. In particular, the map shows the critical deliverables between project teams, and in effect defines the primary interfaces on the program as shown in the figure above.

The work of a program manager cuts across the project teams, therefore he or she predominantly manages in the horizontal dimension of the program. In order to create an integrated product, service, or infrastructure solution, program managers are responsible for three primary things:

1. Ensuring that the deliverables from the project teams form an integrated whole product solution;
2. Ensuring the highly complex network of project interdependencies is synchronized and coordinated throughout the program lifecycle; and
3. Ensuring the program business case remains viable.

The Program MAP is one of the most valuable to tools to help program managers accomplish the first two responsibilities - it forms a picture of the integration of deliverables, and it helps to synchronize the cross-project work over the life of the program.

Program Complexity Assessment Tool

As I think through explaining complexity of a program to a client, I came up with an interesting way to assess the complexity of a program. The program complexity tool shown above helps determine how a new program stands on multiple dimensions of complexity.

One of the elegant features of the complexity assessment tool is that it produces a complexity profile which helps to visually depict the overall program complexity. The level of program complexity may have a significant bearing on the level of funding, resource allocation, and approved timing and schedule targets of the delivery effort. Additionally, it contributes to sharpening the focus of attention on the elements of highest complexity in order to reduce risk and ensure that they are appropriately managed.

The value of the above tool is multifold. Senior Managers/Directors can use the tool to help balance a portfolio of programs with an appropriate mix of low-to high complexity programs. It also helps them determine the level of skill and experience needed for the program manager and other key roles on the team to successfully define and execute a program.

Program Managers can utilize the tool to identify key risk areas for a program - high complexity usually means higher risk. In the example above, any program element shown as a complexity level of 3 or 4 should be evaluated in terms of risk to the program. The complexity information contained in the tool can also be utilized by program managers to develop and justify the amount of schedule and budget contingency needed for the program in order to increase the probability of success.

EXECUTE.... OR BE EXECUTED!!!

"Strategy gets you on the playing field, but execution pays the bills"

- Gordon E. Eubanks, former President and CEO, Symantec Corporation

As I sip through coffee glazing over the Forbes magazing, I am surprised to read that:

"82% of Fortune 500 CEOs surveyed indicated that they feel their organization did an effective job of strategic planning. Only 14% of the same CEOs indicated that their organization did an effective job of implementing the strategy".

Corporate Strategies are intellectually simple; their execution is not. The question is, can you execute? That's what differentiates you. While most organizations have the strategy, they lack an actual strategy-execution process. Some organizations cannot articulate their strategy in a clear, simple, consistent voice - a requirement for enabling discussion and encouraging followership.

Sadly, many employees don't understand the corporate aims of their organization, let alone see themselves as an integral part of the solution. Harvard Business School findings suggest that 95% of employees do not understand their organization's strategy. Do your employees understand? or even if you are running a program or initiative, does your team understand... how this helps the organizations' strategy?

A group of U.S senators were visiting NASA at a time when funding was being threatened. One senator asked a man cleaning the floor, "So, what are you doing here?" The man answered, "I'm here putting a man on the moon"

Linking strategies to execution remains a key component of achieving business value. Last year I presented a method/technique for creating this link... and was well received, but the more projects I execute and more experience I gain, I understand the importance of this link more deeply.

In one of my recent engagements, I saw top leadership doing a great job of executing and more precisely they were able to close this gap between strategy and execution. Basically boils down to effective leadership.

So when folks say project/program managers are lateral thinking....and have an adminitrative focus... and not innovative focus, I tend to disagree. More and more execution of strategy happens with effective leadership, hence the project/program managers who consistently succeed show a relentless capability to innovate.

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

Measuring a Program's success

Kaplan and Norton say in The Balanced Scorecard: "An organization's measurement system strongly affects the behavior of people both inside and outside the organization. If companies are to survive and prosper in information age competition, they must use measurement and management systems derived from their strategies and capabilities."

Very often, I hear organizations say that their business is to pump oil or move airplanes and railcars, why should they worry about IT & Measurement and ScoreCard? Well, this is not about IT, this is about any programs and projects you do tie up with where your company is headed and your employees, investors, shareholders & speculators need to know that. The only way you can ever know yourself that you are headed in the right direction is by measurement.

Measurement information is a vital input to two backbone decision processes:

1. Progressive commitment of resources through the stage gate system to manage risks and rewards

2. Dynamic benefits path adjustment, to respond to changing environment.

Without a strong measurement system, the basis for well informed decisions will erode, and the quality of decisions will be, at best, suspect.

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.

Leadership and gut calls

During the last 2 months, I had a lot of personal change going on my life. I did get started on a book chapter on software release decisions which I am writing with Dr. Guenther Ruhe of the Software Engineering Decision Support Lab.

I have also been reading quite a bit, notably books as "Winning" by Jack Welch and "Personal Styles and Effective Performance" by David Merill. These books have so much value for a project manager. If you are interested in improving your leadership and soft skills, these books are definitely for you. Talking about Leaders, Jack discusses 8 basic rules of leadership. Out of that the most interesting one is: "Leaders have the courage to make unpopular decisions and gut calls".

As PMs, most of us face situations to make very unpleasant decisions. I have faced this a couple of times with stakeholders. But obviously, we think twice... and sometimes we have sleepless nights once we make such a call due to the simple fact that we don't like to huty anyone's future.

By nature, some people are consensus builders. Some people long to be loved by everyone. Those behaviours can really get you in the soup if you are a leader, because no matter where you work or what you do there are time you have to make hard decisions ... like let people go, cut funding and so on.. yeah... life's tough afterall.

Project Managers' Dilemma

"Project Authority..... You've got it only if you think you've got it."

How can a Project Manager be responsible for the outcome of a project if he/she has no authority over resources and decisions in the orgainzation? After all, there are very few people who report directly to the project manager, especially in a Matrix organization or for a consultant project manager like myself where we have to manage project for a client and the team members mostly belong to the client organization, other vendors or sub-contractors. To complicate matters further, none of the above players have a direct reporting relationship.

"They've given us all the responsibility for the project, but minimal authority over what we need for the project...... Responsibility without associated authority!" is the common lament of project managers. I guess this is always the case, we will never have the authority we wished we had but we will always have the full responsibility for the project.

In fact the very reason we are asked to be the project managers is usually because of our skills to manage this dilemma.

How do you get the work done as a PM?

When I was a novice project manager, I often wished that I could carry a baseball bat to the office, swing it and let people know about it's existence just in case they don't deliver on their commitments. Or, perhaps, settle such issues with a one-on-one confrontation in the parking lot. However, we all know that this not the way to gain people's commitments or to drive projects.

The only thing that you have at your disposal is the ability to effectively communicate with everyone including your clients, stakeholders, team members, executives and sub-contractors. Communication involves knowing when and how to use the different tools for communication including written, verbal and presentation skills.

In fact, the trick to getting work done is know first and foremost how to excel in communication skills. Outstanding project managers spend 70-80% of their project time and effort in some form of communication. They serve as nerve centres for projects by keeping communication channels open for collecting, analyzing, processing and disseminating needed information and decisions. They know how to delegate and provide the discipline, environment and motivation most importantly empower the team members to get the work done. I will soon write more on how we can empower our team members.

When to Release your Software?

A major problem for directors, managers, product managers and quality assurance personnel is to decide when the software is 'reliable enough' to be released to the market. Such decisions are primarily made subjectively or by probablistic methods rather than using quantitative means and decision theory to objectively measure and make informed release time decisions.

Last week, I was in Edmonton at the CIPS ICE Conference giving a talk on this topic and was surprised to find out how many organizations struggle with this decision.

(http://www.iceconference.com/program2007_Monday.aspx)

I presented a multi-dimensional defect prioritization and release model/methodology which sets priorities on defects based on project constraints, stakeholder opinions, risk of not fixing a defect and analysis of defect types, arrival patterns and collection mechanisms.

The methodology presents various release options based on target reliability levels, acceptable level of risk, effort spent on testing and time to market. I got a lot of feedback from the audience and a lot of questions about the case studies I presented.

One of the biggest challenges of implementing this teachnique in an organization is leadership perception and their buy-in. The technique also uses Rough Set Analysis to conduct root cause analysis and the audience was very interested in pattern generation.

I had especially struggled with this area when building this methodology. All the standard techniques for defect root cause analysis such as IBM's ODC, HP Defect Classification and IEEE Classification require complete and consistent data, but the data which I had to generate patterns from was incomplete and inconsistent. Rough Set Analysis is definitely best suited for such situations and led to eye-opening results.

Currently, I am working on a paper to get this work published, but will definitely push ahead aggressively to find situations where "when to release" decisions become tricky to make.

Aligning Projects with Corporate Strategy Presentation

First of all, I would like to apologize to all the readers of this blog for not being able to write something for a little while as I was traveling most of the time. At my PMI presentation last month about "Aligning project with corporate strategy using Balanced Score Cards", I got a lot of very interesting questions from the audience. Some of the questions were around stakeholder consensus, balancing of priorities, changing needs of business and actual implementation of Balanced Scorecards.

These questions definitely stimulate my mind in understanding the concerns other organizations may have in implementing Balanced Score Cards.

I would also like to thank Navneet Bhushan, a great mentor of mine for sharing an interesting WIPRO white paper on "Value of IT", where he has used AHP (Analytical Hierarchy Process) to obtain relative weights on criteria defined in an organization's Balanced Score Card. I will post more on this topic soon.... Here is the link to my presentation:

http://www.pmisac.com/data/uploads/Presentations/2007_10_25_AligningAndPrioritizing.ppt

Which Projects best align with my corporate strategy?

This month I will be presenting at the PMI dinner in the PMI Southern Alberta Chapter Dinner Meeting on October 25-th. It is a great topic and probably of interest to most PMOs and to executives who plan strategy.

The title is: "Aligning & prioritizing projects with the corporate strategy using Balanced ScoreCards".


I personally got very interested in this topic when I was reading the CIO Insight Research Study on Project Management, 2004. The study highlights some very interesting points as mentioned below:

1. 53% of the CIO's say that their project prioritization is politically driven;
2. Only 68% agree that all the necessary business and IT stakeholders are involved in setting IT project priorities;
3. Only 40% of the CIOs say that their companies use a portfolio management approach;

This is when time I started questioning myself on how best can you align your projects with corporate strategy so that the project portfolios can be driven and managed by the needs of the organization..... This was also the time when I actually understood how a true business case is created by using a company's real financial data like working cost of capital and market debt to equity ratio. There was definitely a need to measure projects and question if it was worth doing a project.

At that time, I had recently learned about Balanced Score Cards from an assignment at an Airlines company in Canada and also created some models using Mathematical Optimization under the guidance of my Master's thesis supervisor. The combination of these two led to the creation of the approach which I plan to present.

I was implementing this at Siemens last year and got a great opportunity to understand various types of businesses Siemens is involved in. I wish to share this experience with all of you.

I will post my presentation here on the blog as well and an the Excel Sheet where I built the model.

Maturity Model of an IT organization and outsourcing

The business-IT alignment challenge is moving into a new territory according to Mckinsey survey released in May 2007 entitled, The next frontier in IT strategy: A Mckinsey Survey.

According to Mckinsey, IT organizations naturally pass through three stages as they evolve toward reaching their full potential: Support, Business Collaboration and Innovation.

The first stage is to support the business via mastery of the basics of IT service delivery in a cost-effective and consistent manner. The next stage of the Mckinsey maturity model requires mastery of 'business collaboration'. Mckinsey states that 'collaboration' means that IT is pro-actively engaged in working with the business rather than responding reactively to events and crises as they occur.

Mckinsey reports that significant stage-two progress has been made in the past few years. 83% of of the 72 senior IT executives surveyed reported that they believe that they have mastered stage 2: business-IT collaboration.

The next Mckinsey stage is mastery of 'innovation' . That is, IT must help business identify new technologies that will help them drive corporate innovation to enable distinctive business processes to effectively compete.

It is very interesting find these results, but in my experience a lot of IT shops within organizations are stuck at stage 1 and just able to provide support and not business collaboration or innovation. Very often, we see re-orgs within the IT shops or the top management wanting to outsource all of IT because business looses faith in IT. Even though the goal maybe to reduce IT costs, but are they really reduced by outsourcing? Definitely not, but what these companies do obtain is more predictable and trustable IT shop (from a delivery standpoint).

'Innovation' is what some of the big outsourcing vendors are pitching. They claim to add strategic value through IT and a lot of organizations are buying into that. Does that mean that the inhouse IT shops have failed to do so? We will have to wait and see...

Customer Requirements - How do we understand them?

Project Managers and Leadership

The other day, I was sitting at Starbucks and reading a book by Ram Charan, the renowned CEO consultant on leadership. The more I ponder on it, the more I believe is the need for great leadership from project managers to get things done.

Failing to getting things executed can kill big innovations. I was reading the case study of Xerox and how the CEO Richard Thoman was fired for not being able to execute on some of the innovative ideas which he had brought to Xerox.

I do not mean to give a big leadership lecture here, but I was surprised to read that: the CEO complained that he was not allowed to select his own management. That happens a lot with us project managers too. Sometimes, we just have to work with whatever resources we have to get things done. Being able to work with people of different personalities creates diversity in team and promotes challenge and thought. Being able to consolidate the differences between the team members and creating a shared mental model is one of the biggest tasks of project managers.

Earning respect is another challenge, so you have to be knowledgeable enough to be able to help out the team members. The best approach is act as a service provider to your team rather than someone trying to manage them. By Service provider, I mean someone who provides umbrella to the team when its raining and clears stones and pebbles from the path when the team is moving forward. Empower the team! I would write another blog on strategies to empower the team.

These are some of the things which Ram Charan recommends for CEOs to do at a higher level. I am not saying that as project managers we are like CEOs or trying to act like one, but there are certainly leadership traits which we can learn. As project managers, I would recommend my fellow colleagues to be more of leaders rather than managers. By doing that, project management actually provides strategic advantage to the organization. Below is an interesting comparison between leaders and managers:

LEADER

1. Focusses on what and why

2. Innovates

3. Focusses on people

4. Inspires Trust

5. Has a long range view

6. Has eyes on horizon

7. Originates

8. Challenges Status quo

9. Does the Right thing

MANAGER

1. Focusses on when and how

2. Administrates

3. Focussess on systems and structures

4. Relies on Control

5. Has a short-range view

6. Has eyes on bottomline

7. Initiates

8. Accepts Status quo

9. Does things right

Is Project Management an Art?

The more project managers I meet, the more I find out that project management has a huge artistic side to it.

Despite having common body of knowledge such as PMBOK, are 2 project managers alike? Or the way in which they execute projects alike? Certainly not!

Like an artist leaves his distinct style on his work, I believe every project manager like an artist also has a distinct style in managing a project.

The human side is definitely very important, but is it just art? or let me reword it, is art just enough?

From my meagre experience, I have seen that there are two approaches to project management:

The Art of project management relies on human intuition, communication and capabilities to negotiate between conflicting objectives and priorities. These are critical skills for any project manager.

However, the artistic skills can be greatly enhanced by using science. The science of project management deeply complements the art side.

By science of project management, I mean usage of exisiting scientific, cognitive and mathematical techniques in an innovative fashion to improve decision making process, balancing priorities process, measurement and reporting process, conflict management process and so on for a project manager.

This is what the book I am writing is about. In any situation, how can a project manager leverage the science and combine it with his artistic style to excel as a project manager. This level of understanding helps a project manager to go beyond his typical role and add strategic value and advantage to the organization.

Beginning of the journey

With the beginning of this blog, I intend to make progress on my book on "Art and Science of Software Project Management". I intend to use this blog as a means to discuss and promote ideas with the readers.