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.