[Note: This article was published in PM Network Sep 2012 “Peer to Peer” column as a dialogue between me and Cindy Lee Weber, PMP, a practice manager at Trissential in Minneapolis, Minnesota, USA. Registered PMI Members can access the magazine and the article here. My article is reprinted here, and my views are in green color.]
Tathagat Varma, PMP: Fewer people confuse projects and programs than they did 10 years ago, but there still is some confusion because it can be objective. By definition, a project is an endeavor funded by finite resources with a finite duration and specific outcome. A program is a group of projects aligned by a single objective or outcome that can be better managed collectively than individually.
Cindy Lee Weber, PMP: There also can be confusion in projects versus work effort. For example, a request for a report that will take less than 200 hours and US$ 1,000 might be deemed an operational work effort rather than a project. You might not use the same project management framework, or you might use the same framework but with less rigor.
Mr. Varma: Sometimes you have to put it in different terms for executives. I explain to executives that we should use projects to address specific, one-off problems like delivering a product ahead of the market to gain market share.
But we should look to programs to address organizational problems: How do we look at so many moving parts? How do we train all the people together? How can we create consistency in our process framework across the organization?
I explain to executives that we need to look at it as a strategy program with a much wider charter, not just look at the immediate benefits for one project.
For example, we might decide to create a new engine that will improve search results. This cannot be a one-time activity. We need to look at all moving parts. After we’re done, how do we improve it? How do we improve the operational part of it?
Ms. Weber: You have to ensure alignment with executives in language and concepts. I worked on a US$15 million to $20 million human resources consolidation project that really was a program. Because it had so many legs, as the project manager, I had no real responsibility—I didn’t have budget or quality control. In the beginning, I worked with all stakeholders to agree on the language used for this “project.”
I assigned project leads to the individual work silos rather than “project managers,” but their roles and responsibilities were project management-like. I used a program management approach but didn’t call it that. It worked well. Whether we called it a project or program was irrelevant as long as we aligned with goals and objectives.
Mr. Varma: For a large, complex software delivery that was incorrectly labeled a “project,” I incorporated many program management processes. I created a program structure and program government framework, and appointed 14 competent project leads responsible for each of the subsystems, giving them a fair amount of autonomy.
I served as the program manager and did not micromanage the decisions or progress tracking. My role was to put it all together, look at the data and interdependencies, and make sure all 14 subsystems ran on the same timeline so we did not end up with a bottleneck.
Ms. Weber: By treating a true program as a large project, you risk under-resourcing and underestimating the time needed for program management. You also lose sight of some of the urgent parts because there isn’t ownership at the project level.
If it’s cross-functional or multi-site, there’s a tendency to not involve all stakeholders, so you may not understand all the requirements or organizational change that will happen.
Mr. Varma: In addition, the project manager might overstep boundaries and micromanage, which leads to frustration amongst the team.
If it’s a true program, you need a program manager to behave like one—zooming in when there is a problem, then zooming out to manage at a high level. If the project manager makes all decisions and attends all meetings, he or she will burn out at some point. Plus, there can be delayed decision-making because he or she can’t make all decisions on time.
On the opposite end, if you treat a large project as a program, you over-provision resources and management, which increases costs. Secondly, you elongate decision cycles—decisions that could have been made at the team level are made one or two levels above. And at some point, team members feel there is too much upper-management involvement.
Ms. Weber: You also risk losing budget and schedule elements—when you roll up a project to a program, the responsibility of a particular piece gets segmented and you don’t see the overall costs, for example.
And if you put a program manager in a project manager role, he or she may not get into the day-to-day task management of project management. The two roles require different skill sets and interest levels, and there is a big risk in failing to identify those competencies.
Mr. Varma: Moving from project to program manager after a couple of years shouldn’t be automatic because the roles require different mindsets, maturity and problem-solving capabilities.
Because projects are more compact units and project managers generally have authority over team members, team members likely will align with whatever the project manager says. But because program management is all about collaboration and team members don’t formally report to program managers, they have to lead by influence. They have to bring people on the same page, create collaboration and negotiate between different stakeholders.
Ms. Weber: If organizations don’t recognize the right roles of project and program managers, chances are they also don’t understand the role of a business analyst, architect, systems analyst or a quality-assurance person. There’s probably a bigger, overarching problem there.