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.

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?

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

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.

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.

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.