Project Management Institute

A pragmatic approach to program management

Dan Manescu, Program Manager, EDS

The awareness of Project Management increased dramatically in the 90s. For many organizations Project Management is one of the main delivery tools. By contrast, Program Management is less mature. Various frameworks for Program Management do exist. However, simple and pragmatic practices and tools are not readily available. In addition the differences between Line Management and Program Management practices can be quite blurred from a practical standpoint.

With these in mind, we have defined a pragmatic Program Management approach that was used for over a year to run a program of infrastructure services in a finance environment.

The paper describes this Program Management approach through examples and detailed explanations. It then presents critically the results from the key stakeholders’ viewpoint: customers, project managers, and senior management.

The paper proposes tools and discusses findings that are readily applicable by other teams/businesses and are not dependent on any specific Program/Project Management methodology. However the approach may need to be adapted to suit particular circumstances.

The Focus

Let's get started by looking at what you can expect from investing the time into reading this paper. First of all—what this text is not about:

• The paper is not about Project Management. We take it for granted that a Program must be built on solid Project Management practices. Like anything in life, we need to get the basics right first.

• We are not going to look at the Program Management methodology heavyweights. These methodologies do exist. They are usually valuable frameworks that need to be heavily customized to actually become meaningful to the people on the ground.

• By the same token, the paper does not cover Program Management heavyweight products that medium to large organizations can deploy widely to increase the quality of the delivery. The value of using these products is dependent on the deployment effort and the preexistence of mature program management practices.

• Finally, we are not going to talk about basic tools such as the Microsoft Office family. They represent the foundation of our toolbox and we believe “dexterity” with and knowledge of these kinds of tools are prerequisites for IT professionals in supervisory and management roles.

This paper is about a real-life program that is pretty typical in many respects despite its own peculiarities. The actual names and details were removed since they did not add value to the lessons learnt. Here is what you will get out of this discussion:

• We will cover a number of simple and pragmatic Program Management practices that turned a continuous stream of projects into successful and predictable deliveries to their customers.

• Then we will focuses on the business information that Program Managers deal with. This is made up of a set of characteristics and indicators that describe all projects across the Program.

• Our experience is that behind most professional outcomes there is a set of simple and pragmatic tools, i.e., a Program Management toolbox.

• There will be examples to take home and you will be exposed to the lessons we learnt during the implementation of this approach.

We will help you understand how to start small and be a successful Program Manager, what sort of information is relevant to a Program Manager and what a Program Manager does with this information. You will not hear about revolutionary and magical new techniques. However we do hope this text builds up your insight into Program Management. After all, one “A-ha!” is all it takes to truly get you to the next level.

The Context

To feel our way into the subject let's look at the characteristics of the business context that these practices and tools were used in:

• Multivendor environment with major IT players, some of them in direct competition

• Complex platform that includes midrange and NT servers, Lotus Notes Servers, communications infrastructure, mainframe feeds etc.

• Delivery of multimillion-dollar outsourcing contracts over several years

• Matrix organizations with many delivery groups that are specialized narrowly

• Well-established relationship between customer and service providers.

A critical factor to building successful Programs is the attitude and cultural shift the Program Manager brings to the place. We found that practices and tools, however good and suitable they are, become fully effective only if they are used under the umbrella of the following delivery principles:

• Bottom-lines first

“Start with the end in mind” says Steven Covey in the “7 Habits of Highly Effective People.” Perception is important, but perception follows reality in the long run. In final analysis customers know Program Management is about delivery. Never lose sight of this.

• Cushion the Client

A business relationship with a matrix organization can be quite alienating for many customers, especially in long-term contracts (10+ years). Typically complex IT (infrastructure) environments may become even more complex when matrix organizations are involved.

Organizational behavior symptoms such as a continuous stream of new faces who do not know their customer and the IT environment, lack of ownership and the likes may indicate that people do not take sufficient responsibility for end-to-end delivery. This is where the Program Manager must step in and isolate the Customer from the complexities behind the services being offered.

• Ownership Shield

It follows from the above that the service provider's staff must shield Customers by taking ownership of the requests or issues raised by them. In a sense everyone in contact with the Customer becomes either an owner or a communication channel to the owner of the problem to be dealt with.

• Teamwork: “It's our problem!” vs. “Us & them attitude”

“Finger-pointing” is not unusual in a multivendor outsourcing environment and it is often exacerbated by a lack of proper project planning on all sides. A good Program Manager takes a holistic attitude in problem solving—if there is a deep-rooted problem you are bound to be affected by it sooner or later. Therefore your help in diagnosing and fixing a problem is a must and it comes to your advantage.

• Communication, communication, communication

I cannot stress enough how important this is. It would take another paper to scratch the surface of this aspect. Communication is a critical success factor to Program Management. You cannot overdo it. Emails, meetings, one-on-ones, formal, informal, presentations, papers, verbal and written—it is all part of it. The blend, efficiency and audit trails are important.

• The Program Manager is the Glue

You may find it useful to see yourself as glue to the entire program effort. If someone drops the ball, you pick it up. But remember—you are not the doer though, have those responsible deal with the issue.

The above principles are not that difficult to use in practice if you keep in mind they are merely facets of a positive customer service attitude.

Just try out these principles! Be patient, keep your ear to the ground and you will be amazed with the results.

The Program Management Practices

We've discussed the business context and the shift in attitude that Program Managers should bring to the place. We are now ready to tackle the Program Management practices. Let's start by looking at the big picture first.

Project Managers project manage their projects. Let me say that again—Project Managers project manage their projects, they have full responsibility for their projects. It is only then that Program Managers can add value to the place. Why? Because the Program Manager builds on Project Managers’ key process outputs:

• Project Scope, Scope Changes, and Re-work Requests

• Project Milestones

• Issues and Complaints

• Risks

• Costs

So, what Program Management practices make a Program Manager effective? Here they are:

• Work Baseline

An effectual Program Manager can give you a straight and quick answer to the following questions: What projects are you working on? Where are your projects in the process life cycle? What are the main Work Packages that your Program delivers?

It may sound amazing but there are situations when people run their business life and meetings based on Issue Registers and Risk Registers. And yet they do not have a Work Request Register that gives clear answers to the questions above.

• Reporting

Reporting is not something that we do because it is “part of the process.” Reporting helps Project Managers and Program Managers alike find answers to other equally important questions such as: are we getting anywhere? Are we cruising toward the Program targets? Are our short-term goals and activities lined up with the big picture?

Program Status Reports should build on the Project Status Reports in a seamless manner: the information from the latter flows into the former in a distilled way.

• Issues, Risks, Escalations, Customer Complaints

A Program is not meant to be simple. Smooth sailing is unusual no matter how good our planning skills are. So, how do you handle difficulties? Do you record them systematically? Do you apply techniques such as Root Cause Analysis or you reckon this is an academic technique?

I challenge you to think this one out: Project Managers handle all these events routinely, as part of their job. What is the value that you, Mr. or Mrs. Program Manager, add to these activities?

• Communicating, communicating, communicating…

It is worth repeating the above line. Communication is an attitude, a practice and a tool in the same time…

• House rules and Quality Plans

Too many times we take it for granted that people working on our projects know what they are supposed to be doing. Or do they? Of course they do. Except that our Program is unique. Otherwise it would be an operations workshop not a Program.

Just imagine I am a new Project Manager who works on your Program. I know the Project Management process, I‘ve been in the business for a while but, still, may I ask—what do you expect of me, in this environment?

“I am glad you asked!” you say with a smile. “Here it is, the <Project Manager's Handbook> and the <Quality Plan>. They tell you how we do the things around here. Please read them before our first one-on-one meeting. I am looking forward to your feedback.”

• Metrics

If you want to know whether you are right or not, you need program metrics. No, it is not daunting. Just think about it, all you need is an easy-to-use tool. But more on this later! For now get used to it—you will need to use program metrics.

Take a deep breath and tell me—you are disappointed because you did not hear anything new. You are right, the practices are not new. They are powerful not because they are new but because you now feel how they can help you, the Program Manager, add value to your program and to the delivery of its projects in general.

If you still do not have a feel for it—perhaps reading again this section helps. If it does not, mull over it. It will come to you. Just set time aside and mull over it.

Uniform Characteristics and Indicators of Projects

Let's move on and discuss a set of uniform characteristics and indicators that describes your projects.

Why are they important? Well, that's because Program Management practices are as good as the tools that support them. In turn, the tools themselves are only useful if they handle standard pieces of information across all projects.

There are two types of project characteristics and indicators:

1. Program Metrics

2. Project Complexity Metrics

The Program Metrics tell you how well your projects perform and where your Program “hot spots” are, i.e., the things that are consistently late or under par when compared to the rest of your Program. Here is a sample of the items that you can keep track of:

• Status of Program or Project Milestones

All project milestones, project tasks, and actions are time bound. At least they should be. That means it is fairly easy to tell whether they are on time or late, and, if late, by how many days.

Define your own rules and use colors. For example, a task is Green if on target, Yellow if late by up to five days, Red if late by more than five days.

Then churn your Project Schedules through a tool (read a “macro”) and use a chart to display the results. You will have some interesting stats to look at, I can reassure you.

If you had a gut feeling that something was wrong with that project, now you know what it is. I found out that intuitive hunches are more often than not supported by such metrics. Sounds simple? Well, it is. But do not forget the prerequisite: these metrics are possible and meaningful only if the Project Schedules are maintained on a weekly basis as a minimum. This is one of the many reasons I have said before, and I repeat it here, the foundation of solid Program Management is a simple rule— “Project Managers project manage their projects.” This goes without saying. Fix this first if it does not.

• Program Statistics

Other characteristics that a Program Manager will be interested in are statistics such as the number of issues, change requests, problem reports/rework requests, and complaints. They can be analyzed by project and by delivery group.

These metrics are not intended to support a witch-hunt or finding scapegoats. Genuinely they tell you where to focus your attention in problem solving and it gives the project staff short-term goals to aim for.

The Project Complexity Metrics, as the name suggests, give you a good indication of how complex the individual projects are. One needs to measure things such as number of hardware boxes, number of software packages, number of end-users, number of deliverables etc each project must handle.

You will find that Complexity Metrics assist (force?) you to define a very solid Scope Definition process. This is an area, I discovered, many Project Managers have difficulties with.

A quiz for you: in many cases the cost of a project is a very simple high-level complexity indicator. So why look at the Complexity Metrics? I leave this to you to figure it out…

The Program vs. Project Toolboxes

We can now pull it all together. Professional Program Managers start with the right attitude, feel how the appropriate practices help them achieve their goals, and know what the available business information tells them about their projects. All the above— I cannot emphasize enough—must be supported by adequate tools that are a breeze to use under pressure and fit in with your approach.

“Where do you find such tools?” I hear you say.

The parallel between heavyweight Program Management methodologies and the pragmatic approach suggested above applies to tools as well. It is not one or the other; it is both.

There is room for an enterprise-wide Program Management tool, most likely a Web-based one. These enterprise tools are not yet mature enough to serve the other end of town—the individual. In addition there are companies that cannot afford such tools for a variety of reasons.

Coming from this end, the Program Managers’ information toolbox is key to their effectiveness and professionalism. The simpler the toolbox the better it is. Take a look at Exhibit 1. What you can notice is that the old spreadsheet, the old-fashioned work-processing document, a database and, of course, the project management package will do.

Exhibit 1. Program vs. Project Toolboxes

Program vs.Project Toolboxes

Here are a few comments on the recommended Program Management tools that you may want to think about:

• What you can do with a tool such as Microsoft Project

I have been using a heavily customized Microsoft Project version for more than four years. I can walk away with a “Global.mdt” and build solid project plans for medium to largish projects.

With three or four custom toolbars you have everything you need for your project plan: a scope statement, list of equipment/software, risk/issue/change management registers, business milestones and implementation milestones, views that support short term (1–2 days) and medium term (1–4 weeks) planning, status reporting etc.

You can view the registers for one project at a time or for all Projects in the same view. You can click on a button and get all the tasks for a staff member across all projects. You can automatically generate action lists for all staff on all projects if you need to.

The outputs do not look flashy, but this tool is about getting things done. It is not about catering for perceptions management.

• How do you build your Program Management Information Toolbox?

I recommend a product suite like Microsoft Office because you need to heavily link the outputs. Use the most adequate tool for the job while making the information available to other tools. For example if you need to display the information graphically do use a spreadsheet. But avoid re-entering the same data in your Program Management database—link the spreadsheet to the database.

Record macros and access them from custom toolbars. For example, I find it useful to take short notes of everything that happens during the day. If you are responsible for several projects at anyone time you need to record and summarize the contents of phone calls, emails, meeting discussions, even hallway conversations effortlessly. Just click on a toolbar button, paste the automatic text in the Task Notes (e.g.,“23/3/01 (email):”) and add your commentary.

Do you think these detailed notes would help you resolve your issues faster?

• One key observation: be pragmatic!

Do not record information that you will not act upon. And especially do not ask your Project Managers to record information that you do not need on a regular basis.

The opposite is also true. Make sure that key outputs are maintained consistently. If not the information supplied to the Program is not representative and meaningful. Both observations have very important people skills implications, but more on this later.

• Some of your tools must be very practical, others must be very presentable as well.

I find that a well-crafted and aesthetic Program Status Report serves you better than a basic one, especially on large Programs. The use of color is very important, but do keep the “artistic” design simple.

At the end of the day make sure that you spend minimum time on maintaining these aesthetic aspects.

• Project Management vs. Program Management toolboxes.

We said that the foundation of Program Management is the professional work of its Project Managers. This applies to tools as well. It is possible for Program Managers to use their toolbox somewhat in isolation. However, for maximum benefit, Project Managers should use similar tools to manage their projects.

• Keep the information in spreadsheet or table format.

I found that word processing documents do not help build a toolbox because text information is less reusable and it is harder to summarize automatically.

This is just a sample of what you can do if you have good tools to manage your Program information. It would take me more than a paper to explain all these in detail.

I know some of these sound too good to be true but believe me they are true. So what's the catch? Well, we will talk about the lessons learned further below…

Where to From Here?

Just before we get into intangibles, I want to mention where you could go from here:

• Project Office

Sometimes the boundaries between a Program and a Project Office are quite blurred. Project Office Managers and Program Managers have requirements that are very similar in many respects.

Here is a tip—I suggest you can mentally “Find and Replace” the word “Program” with “Program Office” and “Program Manager” with “Program Office Manager.” Then read again the article. You will be amazed…

• Project Maturity

This is one of the most difficult areas to tackle and it takes more than a paragraph to explain you how you can build on what we discussed in order to incorporate Project Maturity practices on your Program. I only want to make one point—I do not believe you can achieve this unless your toolbox is sophisticated enough.

Lessons Learned

By now you should have a good understanding of the mechanics of this approach. Let's further strengthen your insight and look at the lessons we learnt in the process of putting these things in practice:

• Expect high quality outcomes and excellence

Professional delivery is not an accident. It starts with your internal desire and your expectations. They will shape what you do and what others will do when they come to work on your Program.

• Attention to detail

Do I need to mention this? Project Management is all about attention to detail. So is Program Management. Except the details you focus on are different.

• Persistence

Persistence is the foundation of success. While it is conceivable you can persist in being mediocre, the ideal is to harness your persistence to becoming the best Program Manager you can be.

• Internalization

I covered this above, it is so important—I need to repeat myself. Reflect on anything that you want to change on your Program and on the feedback reality gives you. There is absolutely no substitute.

• Disciplined data entry and documenting skills

This is the nitty-gritty. You know that good Project Management relies on adequate project documentation. So does Program Management. If you are going to be a professional Program Manager who uses real-time information to drive his/her program, then you have no choice—record live information about your projects.

Finally a few points about the feedback I received from the main stakeholders:

• You will notice that after awhile the people take for granted what they do: there is no whinging, no debate, and no questions. They just do it! You may be the only person who knows that what they do today is the result of your program set-up efforts. This is the first sign of success.

• Customers and Senior Management—well, do not worry about them, they are going to be delighted. You know why? Because your program is not on their issue list. They have enough issues of their own.

• The feedback received from the Project Managers seems to be more dependent on their project management maturity than on anything else. Therefore your leadership style needs to be flexible and suited to the team mix.

Here we are, at the end of our short journey. Here are the Program Management ingredients that we covered:

• Attitude and Cultural Shift

• Program Management Philosophy

• Program Practices

• Uniform project characteristics and indicators

• Program vs. Project Toolboxes

• Lessons learned.

One last point before we go—some things in life are deceivingly simple and they look straightforward in hindsight. But not when you take a leap forward.

If you need any help, just ask for it and you will get it. As one saying goes: when the student is ready, the teacher will show up.

And keep in mind: life is beautiful. Reach out!

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA



Related Content