What’s the *real* difference between Program and Project management?

One of my colleagues was in your PMO roundtable earlier this month and suggested that you might be able to provide some insight. I’m getting pressured to move from Project to Program Management, but I don’t really understand the difference. I already manage multiple projects and it doesn’t seem like our Program Managers do anything different. I know that we don’t always have the same view of job roles and titles that the rest of the world does. What should a Program Manager do and how are they different?

Name withheld – via email

There’s a lot of confusion around Project, Program, Project Portfolio and IT Portfolio management. The terms get tossed around loosely and they’re often (incorrectly) thrown together as part of a single career path. This leads to a lot of confusion as people get “promoted” into jobs that they aren’t equipped to handle. This leads to frustration, ineffective PMOs and a bad rep for the various disciplines.

Let’s start at the beginning. Bear with me. You probably know a lot of this already, but it helps to build this from the bottom up.

A “Project”, according to PMI, is “a temporary endeavor undertaken to create a unique product or service.”  This definition leads to a lot of work efforts being called “projects” when they really don’t warrant formal project management oversight or aren’t defined well enough to treat them as projects. I prefer my own definition:

“A Project is a scoped work effort with clearly defined acceptance/exit criteria, budget and schedule.”

This gives you the holy trinity of Quality, Cost and Time and prevents the expectation that a PM should manage undefined and unscoped work as a project. If you don’t have a clear idea of what your deliverables/goals are, you simply don’t have a project. This doesn’t mean that you have to know the minute details up-front. But, you do need a clear agreement of what your customer expects and what success looks like. The requirements, budget and schedule may evolve as the project progresses. But, you need some sort of starting point to manage the work as a project. The difference in the definition of “Project” doesn’t really impact the rest of these definitions, but it’s a bit of a pet peeve of mine.

PMI’s definition of a “Program” is “a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually”. This is a good theoretical definition, but can be a bit vague for people looking for practical guidance. The most common use of Program Management is to manage projects that have dependencies between them. Shared deliverables, risks, predecessor/successor tasks or even shared resources or assets need to be coordinated between interdependent projects. It’s the responsibility of the Program Manager to ensure that projects supporting common or related business goals are kept in sync and don’t end up in conflict. Individual Projects have a responsibility to their stakeholders. Program Management ensures that those stakeholder needs are balanced with realizing the common business benefits. A program may be temporary or may be perpetual (eg: a Program may be formed to address a new regulatory issue or an acquisition. In these cases, the Program would likely close out when the goal was acheived. A Program may also be formed around an ongoing function like Marketing or supporting a specific customer. In these examples, the component projects would be temporary, but the program would be continually updated with new demand or projects.)

For our final PMI reference, a “Project Portfolio” is “a collection of projects and/or programs and other work that are grouped together to facilitate the effective management of that work to meet strategic business objectives”. These objectives may be the support of a particular business unit or function, a common budget or a specific pool of talent or resources. More simply stated, a ‘Portfolio’ is the collection of all demand that needs to be balanced against limited resources. The “management” of the work is usually limited to grouping, organizing and prioritizing your demand to ensure that you get the optimal value out of finite resources. This includes a certain amount of project and program oversight  (not management) to identify risk, potential benefits realization and resource issues in order to continually reassess and optimize the Portfolio.

The “IT Portfolio” is the collection of projects, infrastructure, people, applications and knowledge assets (including data and processes) of the IT organization. IT Portfolio Management usually includes the IT Project Portfolio Management function, but it also encompasses all of the assets that may be impacted by or created as a part of these projects. Due to the nature of IT projects, the infrastructure and asset management of IT is closely tied to IT projects through the IT and Project Change Control and Change Management functions. I’m not going to go into any depth on IT Portfolio management. I only bring it up because there’s often confusion around “IT Porfolio Management” and “Project Portfolio Management” in IT groups. For more detailed discussion, check out ITIL (the IT Infrastructure Library) and ISACA’s CobIT (Control Objectives for IT)

With those basic definitions out of the way, I’ll move on to the roles. For each role, I’ve indicated where they fit into the *enterprise* view. Keep in mind that this view changes as the perspective changes. What may be an “Operational” function from the Enterprise perspective becomes “Strategic” to the person responsible for that function.

Task/Work managers
Operational
Key Phrase: “Get the job done”

The primary job skill here is an intimate knowledge of the technology, business or area where the work is being performed. The Work Manager needs to have the ability to manage time, estimate work and react to changing situations is key. In many cases, the people managing the work are also the ones performing it.  A “lead” can mentor other people in the team and develop or supply these skills where they’re lacking in other team members. The focus is on simply performing the work. When a project is poorly scoped or defined, “Project Managers” can easily fall into the reactive mode of functioning as “Work Managers”. Instead of managing the project, they end up managing the people and the work.

Staff Managers
Tactical
Key Phrase: “Develop Talent”

The primary job skill is managing people. The Staff Manager needs to have the ability to manage conflict, identify individual strengths and weaknesses and to get the maximum value out of each staff member. The focus is developing existing resources and ensuring that their staff is able to address current and future needs. They’re an escalation point for issues with work management, but their primary focus in on ensuring that the relationship between the company and the individual provides the maximum mutual benefit.

Project Managers
Operational 
Key Phrase: “Deliver the project”

The primary job skills are change control and risk management. The Project Manager needs to evaluate proposed changes to determine the impact/value to the overall project, appropriate course of action, escalation and renegotiation. The Project Manager needs to have the ability to perceive and mitigate risk, intelligently apply and manage defined project management processes and to maintain the alignment of team members to deliver on commitments. These commitments include the specified deliverables with the appropriate level of quality using the agreed-to schedule and budget. The primary focus and responsibility of the project manager is to the health and success of the project. All other skills and responsibilities are in support of this focus.

Program Manager
Tactical 
Key Phrase: “Deliver Business Outcomes”

The primary job skills of a Program Manager are change management, communication and negotiation. The Program Manager needs to ensure that related and interdependent projects are coordinated to deliver the expected business outcomes. Changes in individual projects need to be understood and the expectations and needs of the related projects may need to be renegotiated. The primary focus is not on the specific deliverables of the component projects, but on the overall delivery of value to the business. Project Managers are accountable to the individual Project Sponsors and are focused on delivering the optimal value for that sponsor. A Program Manager is responsible for maintaining balance between the projects within the program to deliver value for the Program sponsor or the business as a whole.

Project Portfolio Manager
Strategic
Key Phrase: “Maximize Strategic Value”

The primary job skills of a Portfolio Manager are Strategic Planning and Benefits Realization. The Portfolio Manager needs to optimize scarce resources (financial resources, people, skillsets, assets, etc.) to optimize the value of the project portfolio to the business. Existing projects and new demand need to be continually balanced to ensure the highest possible benefit realization. The Portfolio Manager needs to negotiate and renegotiate the prioritization of projects and resources in the context of the overall business strategy. Challenges to Programs and Projects need to be considered in the context of the overall portfolio and resources may need to be reallocated across programs/projects to maximize business value. The focus and responsibility of the Portfolio manager is to get the maximum strategic business value out of a constrained pool of resources.

As you can see, these are very different functions and skillsets. While there’s considerable benefit in having experience in the connected disciplines, they aren’t part of a continuous career path. A Project Manager may develop the skills to be a good Program or Portfolio Manager, but that’s not a given. An Engineer may develop strong finance skills and become a CFO. Those engineering skills may provide insight and understanding that would be complementary to controlling the finances of an Engineering organization. But, CFO is not a logical progression from Engineer. Similarly, being a good Project Manager will provide insight that’s valuable to a Program or Portfolio manager, but it’s not a requirement or an indicator of future success in the role.

With all of that said, Project Managers in most organizations end up developing a broad range of skills in order to survive. We end up working as analysts, change managers, financial reporting staff, HR, strategic planners, trainers, etc. If you’ve exercised your Change Control, Risk Management and Negotiation skills, you may be in a position to be a strong Program Manager. That has very little to do with your formal Project Management career path and everything to do with your own personal experiences. I know some excellent PMs that simply aren’t wired for Program management. I also know some people that are phenomenal Program Managers who’ve never managed a project.

I hope that this helps.

The  Community Roundtable that I was asked to run at Symposium ended up “Going Stealth” this year due to approval issues and sign-offs from legal (the usual corporate BS). However, we did end up having the session in an unadvertised back corner of the Yacht & Beach club. I’d like to thank everyone who participated. Hopefully we can be a little more “above board” next year.

Here are some of the takeaways:

Roundtable Theme

Companies spend millions of dollars implementing project, program and portfolio management practices and systems. However, these systems often result in significantly more overhead and cost than planned and don’t deliver the anticipated business results. The business blames IT. IT blames the business and both often blame the tools and vendors. Where are the disconnects?

Flawed assumptions:
PPM tools will fix a broken process – Broken processes means a broken deployment
An executive-focused deployment will provide value and informed decision making – If the people on the floor aren’t using the tool to actually manage time and work, then the data is inherently flawed
Executives want to be able to see every little detail of a project – Executives want a 30,000 foot view and a platform to help establish trust. The average time for a CxO to make a go/no-go project decision is less than 2 minutes. (Gartner) Most of these decisions are based on the level of trust placed in the person requesting the project and not any objective metrics.
A tool will force conformity and good business practices – If based on a flawed process, or if insufficient training/value is communicated, it simply teaches people to find ways to work around the tool. Also provides the illusion of control since people learn how to “game the system”
PPM tools replace PMs – PPM tools increase the need for disciplined PMs with an understanding of the tools and business implications of the collected data. Increased visibility translates to increased need for business and financial skills in the PMs.
Project, Program and Portfolio management are part of a single career path – Project Management is an operational/People management discipline. Program management is a tactical/organizational management discipline and Portfolio Management is a strategic/financial/political discipline. There’s overlap, but it’s not an evolutionary ladder.  Forcing PMs into Portfolio Management roles is a recipe for disaster. Some will go willingly and successfully, but most will be getting set up for failure.
Executive sponsorship is essential – Many groups have been very successful in managing their own portfolio without direct executive sponsorship. Apocryphal evidence that bottom-up approaches may actually be more successful. (Less overall cultural impact?)

Things to do to be successful:
Essential that any tools are designed to meet the needs of the people doing the work.
-Collaborative project management and task/time tracking that EVERYBODY uses
-Make it easy for the project team to track their work and see how it fits into the “big picture”
-Managed and maintained document repositories
-“One view of the truth” – Big mistake to track the same data in different places
-Kill attachments. Force people to link to live documents

Train everybody. Repeat
-Create a training and information program to continually refresh knowledge of the system and to make sure that everyone understands how the tools are to be used and why. Informed decisions about the processes can’t be made without understanding how the data will be used.

PPM is doomed to failure if there aren’t mature processes in place BEFORE the tool is selected/deployed. Fix the processes and get buy-in from all levels before even thinking about a tool.

Implement “Just enough process”. Large cumbersome roadmaps, methodologies and inflexible frameworks provide little or no value to the people doing the work. Implement checklists and conditional frameworks (eg: If less than $100K, manage with a spreadsheet and checklist. If >$1M, full EVM with a predefined project model).

One large services company has extremely mature processes all based around Excel spreadsheets and Sharepoint. They’re managing a multi-billion dollar portfolio successfully and just starting to look at formal PPM tools. Evidence that the processes are more important than the tools. Good processes make up for bad tools, but the reverse is not true.

Don’t use the tool to promote consolidating into “Mega Projects”. Failure rates increase as project size and complexity are compounded. Segment projects into small (less than 3 months) components with quick measurable gains and manage each as “mini projects” with touchpoints.

Convert IT from a “technology value” mentality to a “business value” mentality. Portfolio management doesn’t work as long as that disconnect in viewpoints exists.
-“Business Value” doesn’t mean “Reduced Costs”. It usually means improved agility and an ability to respond to changing business needs. Cost is secondary to value.
-“Managed and Secure” doesn’t mean “Restrictive and policed”. Reasonable control of the environment and ensuring that we meet legal and regulatory obligations. Sometimes  it’s cheaper to pay a fine than it is to build an infrastructure to avoid it.
-IT needs to be an enabler with a “can do” attitude instead of an inhibitor locking down the environment and imposing controls that provide no business value.

Tool needs to be used in real-time
-Tool failed when used primarily as an annual planning tool. Successful when the process supported a real-time planning and approval process. Projects are entered as they’re envisioned and they dynamically develop through proposal, approval and scheduling. Annual planning is just an exercise in reconciling the budget needs for the next year rather than a mad scramble to create and justify the entire portfolio.

PPM Successes and high ROI
Engage the customer
-Don’t allow the customer to throw projects over the wall. Any PPM tools or processes need to fully engage the customer. If the customer disengages, there needs to be a mechanism to stop the project or at least throw up a red flag. PPM tools can help.

Be religious about requirements
-Set gates and project “drop dead” points for requirements. If the project is broken up into small enough phases or chunks, IT can stay agile while still saying “That will have to be shelved until the next phase”. The tool can lock down requirements, code and test cases.

Strict Change Management
-When a requirement changes, it needs to be documented and the PMO needs to have the authority to force a review of the schedule, budget and resources. Reports can be generated to show where requirements have changed and when the reviews didn’t occur.

Resource management and planning
-Mapping out projects as they become visible (rather than as approved) has allowed the organization to plan career development, develop staffing plans and to develop long-term communications strategies for any organizational changes. Resources feel more engaged as they’re trained for upcoming trends and projects instead of hiring external consultants at the last minute.

Align resources
-Skills inventories and the ability to see when resources are scheduled to become available allows easier scheduling and prioritizing of projects. Only works if the PPM system is real-time and the data is actually accurate.

Prune dead projects
-PMs know when projects are doomed, but are often forced to continue anyways. The tool provides visibility and forces stakeholders to be more objective.  Quarterly review and pruning of project occurs to make way for new projects and changing business needs.

Biggest single issue
Organization Change.  This is compounded if the organization isn’t prepared for the structure and visibility that PPM requires. Develop Processes first, then information sharing/visibility, then a tool. Get over the organizational issues and challenges before even considering a tool.

What’s the best way to powerfully engage attendees during a leadership seminar?

Hi. I used to teach leadership & psychology at West Point…and have been asked to teach/present a leadership seminar. The workshop on leadership (areas of focus in include physical/emotional rituals, behaviors that derail leaders, human performance engineering & a leadership vision for themselves & their organization). This content meets the needs of the client who’s paying for my work…so the issue of WHAT to pitch is set.

My question is this: what techniques or approaches have you seen (or used) that get the attendees’ attention, reactions and engagement?

For example, am thinking about starting with (1) having several people talk about their current role/responsibilities and (2) then suggesting that “what skills abilities got them HERE may not take them to the next level in their career. Later, will walk them through designing/writing their own vision statement.

Many thanks! Jack

Jack Cage

President, Cage Talent

One recommendation that I would make to anyone that leads these types of sessions would be to pick up a copy of “Aha! 10 Ways to Free Your Creative Spirit and Find Your Great Ideas” by Jordan Ayan. About 10 years ago, I had the pleasure of being in a workshop that he was brought in to moderate and it made me think about meetings and training in a completely different way. Even for something as simple as a project planning meeting or something as complex as corporate strategy development, the ideas and techniques for brainstorming and engagement still apply.

On a more immediate note, here are a few tricks that I use (some are pretty basic, but worth repeating):

1. Start the meeting on-time.
This sounds like a trivial item. But being late for a meeting is a subconcious statement that says “My time is more important than yours”. By starting on time, you’re immediately setting that stage for playing by the rules. I have a little trick to keep the upper hand and still allow for people playing this game. I put an agenda up on the projector that shows “Meeting room seating & setup – 10:00am, Meeting Start – 10:05”. Beleive it or not, it actually throws people to find out that they’re on-time. If someone is still actually late, make a point of dragging them in, getting the introduction and opening feedback, etc. DON’T let them sneak in to the meeting and skulk in the shadows.

2. Lay out the groundrules up-front.
-In the meeting everyone is equal. No levels or reporting structure
-Respect all opinions
-Agree to disagree. Make your point and move on
-Personality clashes and history need to get left at the door. All discussions need to be in the context of moving forward and not getting mired in history.

3. Have another person with you moderating or presenting. As a solo speaker, you may miss things going on in the room and the two of you can keep each other on track. Also, the occassional switching back and forth between speakers will often be enough to refocus your attendees (“Did the topic change? Are they asking a question?”)

4. At the beginning of the session, ask for introductions, but also ask what each person expects to get out of the meeting. Having a second person taking notes during this exercise is incredibly valuable. If you notice someone fading, try to tie a point back to what the individual said. eg: “And in this next slide we can see how we might address Jack’s goals of engaging his staff…” Nothing snaps a person back more than hearing their own name and having the room temporarily focus on them. Followup and ask if they see the connection or can think of ways to apply what has been said.

5. Don’t just ask for volunteers, get into the habit of polling around the entire room for feedback on key points. Start early to avoid embarassing anyone. Later on, find opportunities to poll the room whenever attention starts to waver.

6. Reward and encourage questions. A lot of people like to ask questions as a way to demonstrate their own insight and intelligence or, in some cases, to try to trip up the speaker. Try and use questions as an opportunity to get feedback from your attendees rather than as a platform for lecturing. eg: “How many other people have this issue? Can anyone offer suggestions on the best way to address this? Has anyone been successful in working through this issue? How?”. Once you have the feedback, you can add your own spin and answers. Use a lot of positive feedback like “That’s a great question.”, “I like that answer”, “I haven’t heard that approach before, That’s a really innovative solution”

7. Find opportunities to break the room up into small groups for problem solving, list building, etc. Mix up the groups throughout the day.

8. Force the group to have lunch together. Again, this sounds like a trivial thing, but you’ll get an additional level of comfort and openness that comes out of casual lunch time interaction.

John Benfield also suggests this expert on this topic:

• Jordan Ayan

In our federated model, we have almost no “hard” way (financially or in terms of people’s annual goals, etc.) of incenting people to participate and/or cooperate with new PMO governance, standards or processes. What tactics and/or techniques have you used to generate change and cooperations with the PMO?

Question from the Gartner Symposium Forums

Bear with me, this is a bit of a round-about answer.

In the most successful implementation that I was part of, we came at it a bit backwards from the “normal” way of doing things. Our PMO was viewed as a hindrance and as unnecessary administrative overhead. Part of that was because of ridiculous requirements like managing all projects (regardless of size or type) using EVM, preparing huge complex financial models for tiny operational initiatives, religious adherence to gate processes for projects that spanned only a few weeks or a handful of resources, etc.

My team originally came in to help the Applications team move to CMM level 2 and 3. However, shortly after starting the initiative, we realized that we were going to have to take a more holistic approach. We pulled together the PMO, Service Delivery, Finance and Quality teams and started to look at where the overlaps were and how we could combine CoBIT, SOX, ITIL, CMM and ISO initiatives. We didn’t take them over or try to replace them. We just worked with them to understand where we could tie them together with what we were doing.

We started by getting out into the field and explaining to the line workers why we needed to have processes, controls and measurements and how they would benefit them personally. At the same time, we found out where the problems were and why people resisted the PMO (and other initiatives). Since the PMO was a common element to all of the work that was being done, we ended up aligning most closely with them (and ultimately becoming part of the PMO).

We continued down the CMM path and trained analysts in process engineering and documentation (using UML) as part of our Requirements and Change Management KPAs. This eventually lined up with CoBIT and the same people that were building process docs for new IT projects ended up working with the business to document their processes. A lot of technical and business analysts ended up hopping the fence between the two disciplines.

We dismantled the existing “culture of punishment” and shifted to an advocacy culture where the PMO became a mediator to make sure that the business and IT both had a voice. We clearly delineated requirements into Business, Functional and Technical and made sure that ownership was clearly enforced (this also led to a level of requirements traceability that had been lacking. It also GREATLY helped with scope creep since the Business couldn’t change functionality without a business reason and IT couldn’t add or change features that weren’t supported by the functional requirements)

With the empowerment that came with this delineation, both the Business and IT started to view the PMO as being “their” ally against the “other side”. All of the processes and artifacts were presented in a way that demonstrated their value (the WIIFM perspective) and a lot of the “crap” got thrown away. The executives fought a little bit when we did away with a lot of the EVM reporting. But they were really just trying to make sure that the projects were under control. Once we explained the simplified mechanisms and increased visibility, communication and resolution of issues (rather than numbers that were being manipulated by the PMs anyways) the comfort level increased and people focused on getting the work done rather than generating status reports. PMs were positioned as taking the administrative burden off of the engineers, developers and analysts rather than as the “Khan of the Project”. Again, the explicit shifting of control and responsibility made for a better working relationship. PMs became mediators rather than enforcers and provided the people doing the work with a way to be heard.

I apologize if this is a bit disjointed, but it was an evolution that occurred over a 2+ year period and it’s difficult to encapsulate all of the cultural and behavioral changes that occurred. The CMM team and PMO were in a continual state of flux as we incorporated each new piece of feedback into subsequent training sessions and process definition. It really generated a domino effect when a team empowered by the CIO started listening to every level of worker and negotiating “just enough process” to meet everyone’s needs. Before that, it was executive edicts that were often poorly communicated, difficult to execute and that added value to only a very small audience. Once the real dialog began, the PMO became a true agent of transformation.

Don’t get me wrong, we still tracked schedules and costs directly from the Project artifacts. But the focus was on “why” targets were in jeopardy and how to get back on track rather than focusing on whose fault it was or how it could be covered up. If a project went red, the PMO response was “What can we do to help?” not “Whose fault was it?”. We still had the underlying PMBOK type of activities and processes, they were just set in a context of practical communication and mediation instead of adherence to theory, policing and punishment.

It wasn’t perfect, but it was remarkably successful.