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.