Category Archives: Program Management

Three questions every program manager must ask

Suppose you are the new program manager assigned to a program. How would you go about finding your way inside the complex maze of a program, its stakeholders, sponsors, component teams and various vendors? If the program is yet to commence, you might be able to get involved much more deeply, and influence the state of affairs meaningfully. But if the program is already underway, what do you do?

If you take time and ‘learn’ about the program before you act, you might get a deep and thorough understanding of the program but then you might be under time-pressure to deliver results faster. On the other hand, if you straightaway jump into the mechanics of the program, sooner than you realize, you are neck-deep and drowning into the gooey tarpit of unending stream of fires. Yes, you might start delivering the goods that make your program sponsors happy (at least in the short term), but you might not be bringing about systemic change that make you strategic in thinking and approach. Without a more holistic and long-term thinking, you also start drinking from the same well, and very soon, you are also just another ‘manager’ who is fighting fires rather than working proactively to prevent them in the first place. Mind you – if they wanted another firefighter (no offense to the noble profession of firefighting), they would have hired one! So, how do you make a mark?

Over time, I have found asking some simple questions is a great way to get started. Interestingly, these simple questions are very powerful and if the core program team can’t answer them unanimously, it is a pointer that something is not quite right. Here we go:

What are the goals? If the goal is to put out a quick prototype that serves as a placeholder for conversation with customers (as opposed to a powerpoint-laden marketing brochure that no one trusts anyway), then no point in having a complex program management mechanism in place. OTOH, if the goal is to do something like build a skyscraper in two weeks (like this http://www.cnet.com/news/chinese-build-skyscraper-in-just-15-days/), then you will need a very rigorous program governance structure in place with months of advance planning, contracting, timelines, SLAs, and so on. Not knowing the goals is like not knowing where’s the finish line, or not having a clear picture of what the success will look like – we It is the thinking behind questions that matters!might keep pressing on but keep moving in circles, or might misdirect our efforts into something else that looks like success but is not! Kennedy’s vision of sending a man to moon – and bringing him back alive – before the end of the decade is a great example of what is the goal – it fired up an entire nation and aligned everyone to that one single goal.

I once led on a large program (over 190+ engineers in my team developing a complex 3G softswitch). It was an extremely important product for the company – perhaps the most critical endeavor that year, more so because in the previous year, we had blown away millions of R&D dollars building the product that never saw the light of the day, and wastage of money apart, we lost one full year in the market. I recognized the the goals were very clear – deliver an architecturally sound product as soon as possible, and ideally close the year with a field trial. I set up a rigorous program team in place that not only delivered the first version of product in 8 months flat, we did even better than the original goals – instead of closing the year with field trials, we actually closed it with an $18million sales of the product. On the other hand, a few years before in another company, while leading a product development in a very new area of Digital Video Broadcast, I took the risk-first approach and built an incremental development plan (think of the first increment as a simple yet technically complex “Hello World” displayed on your digital set-top box using the entire tech stack for the first time!) that helped us mitigate the technical risks and consolidate knowledge assets at each step rather than build it all in one shot. Even though the result was below par, any other approach wouldn’t have made it any better!

Why are we doing it? Knowing the ‘why’ helps us understand the desired end-state better, especially when the chips are down, a program manager will need to muster up all their energies and tactfulness to negotiate and broker agreements with various components teams (who, for all right reasons, might be more interested in their own line of sight rather than the overarching program goals) or stakeholders in a politically-charged battlefield (e.g. CEO’s pet project ?). On a more positive note, this is also the articulation of the ‘benefits’ of a program, and really distinguishes when a project ends (“outputs”) and when a program delivers (“outcomes”).

We have all heard of the story of the bricklayer, the mason and the cathedral builder. It is the deep understanding of the purpose that helps convert knowledge and skills into passion and an almost obsessions towards the end goal. When Tony Hseih says Zappos is not really into selling shoes online, but rather in the business of ‘delivering happiness‘, it sets the context and direction for everyone in rank and file and aligns everyone’s attitudes and behaviors towards the goal – even if sounds aspirational (and would you really want to pursue any goal that is not aspirational?). Not knowing ‘why’ behind something could be like being given the command to do something without knowing the context behind it, and people might go through the motions and do what is functionally expected of them, but will never be deeply passionate about the cause that might make the difference in the bigger scheme of things. An interesting application of asking why 5 times makes sure that we don’t get stuck as the superficial reasons but actually peel the layers and go to the deep cause underneath.

Where are the biggest pain points today? Are they inside the component teams inside the program, or at the intersections? While a program management approach is a great way to address friction at the intersection, given that technically it is still an ‘overhead’, it might not be the best approach to solve problems inside individual component teams. For example, if the product quality of a component is an issue, perhaps more of TDD or automation or CI or better code review practices might be needed in that team – rather than creating more checkpoints at the program level.  

I recently bought a data card from a very reputed company. The product was absolutely lousy and the service was atrocious. Funny thing is they were too preoccupied in building marketing ads without paying any heed to customer’s pain points. So much so, if you write your grievance on their facebook page, they will delete it no time, but they won’t come and address your grievance. When we shut out ourselves from customer feedback, we lose sense of what’s really making customer driving to us (or driving away from us, as in the example I gave earlier), and then we end up goldplating the requirements that we think the customers want. The end result is a train wreck in slow motion. When Flipkart realized that a major reason people don’t buy online is because they don’t want to pay upfront and then live in the anxiety of waiting for goods to be delivered or low credit card penetration, etc., they created Cash on Delivery, and when they realized they couldn’t own the entire customer experience cycle without really making the last mile of buying cycle – the physical delivery of goods – a painless affair, they literally built their own courier workforce. Acquiring a deep understanding of these pain points will help you prioritize and focus on delivering them with alacrity. 

I have found that these are not just relevant for a program manager but are helpful to anyone – a product manager trying to understand more about why his customers buy (or ignore) their product, or an HR manager trying to create the new hiring campaign, and so on.  

[This blog post was originally posted on LinkedIn at http://www.linkedin.com/today/post/article/20140423015413-3616140-three-questions-every-program-manager-must-ask] 

What’s in a Name?

[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.

Can Program Managers Make it to the Executive Suite?

Note: I recently shared some view on this subject for PMI’s Career Central article by the same name. You can access the original article here. In this post, I have shared the original article, with my comments highlighted in green color.

 

Not many of today’s senior executives come from a project management background. But that’s not to say that program managers aren’t capable of getting there.

“The skills required in most executive positions compared with those required to succeed as a program manager are similar,” says Oluwatosin Agbetusin, PMP, PgMP, program manager, Ericsson, Lagos, Nigeria.

Outlining the similarities, Mr. Agbetusin said both program managers and executives:

  • Decide and guide the actions of their teams
  • Manage human, financial and physical resources
  • Oversee stakeholder management
  • Ensure the organization’s strategic goals are achieved
  • Help establish oversight and proper governance

According to a 2011 PMI-sponsored study, Project Managers as Senior Executives, about 74 percent of respondents said the experience and skills required for project and program management is good preparation for an executive position. Survey respondents included senior executives and project and program professionals from six countries.

And program managers are particularly well positioned to make the jump.

“Program managers usually report to higher levels, which gives them a broader view and more personal exposure to the executive levels,” says Russell Archibald, PMP, the San Miguel de Allende, Mexico-based co-author of the study.

Before moving into his role as senior director of business operations for Yahoo! in Bangalore, India, Tathagat Varma, PMP, worked as a project, program and general manager. He says the skills he honed as a program manager gave him an advantage over line managers.

For example, as a program manager for Huawei Technologies, a telecom company in China, Mr. Varma managed 190-plus people on a program with 14 parallel projects. His experience also taught him how to overcome challenges like cultural barriers and stakeholder alignment.

“It’s about leading with influence versus leading with authority, which I learned as a program manager,” he says. “My approach was to focus on results and let component project teams figure out the means to achieve those results.”

Similarities between executives and program managers center on such abilities as strong decision-making, communication and negotiation, according to the PMI-sponsored study. But one skill that truly transcends positions is leadership.

“As a program manager, if your leadership skills go beyond just managing programs and into areas like contributing valuable insights into strategy, or operational and personnel skills, you will start getting regarded as a leader,” says Naveen Venugopal, PMP, project and program management consultant, International Finance Corporation, Washington, D.C., USA. “This can pave the way for an executive spot in the long run.”

To set themselves apart, program managers must take a holistic view and get creative, says Asad Ullah Chaudhry, PMI-ACP, PMP, PgMP, CEO, AUC Technologies, a training and development firm in Karachi, Pakistan.

“Most program managers think rationally and focus on deadlines and scope. They lose the creativity. To be an executive, they need to use an innovative approach for managing their programs,” he says. “Review the whole process, and try to remove the bottlenecks or shorten the process.”

Program managers should also seek projects aligned with the organization’s overall business goals, says Mr. Varma. When program managers can show they can both deliver and develop or influence strategy, they’re more likely to rise up the ranks, he says.

For added credibility, program managers should consider earning a Program Management Professional(PgMP)® credential.

“The topics, core skills, requirements and knowledge identified as part of the PgMP® credential process are very important for any program manager to either land an executive job or succeed in one because they are closely tied to those required for executive-level job functions,” says Mr. Agbetusin.

Whether program managers realize it or not, the very nature of their role is preparing them for the executive suite. If they continue to hone those abilities, they’ll be on their way. 

If you are a program manager, or know someone who is one, ask them to share their viewpoint on this topic. Program Management is in nascent stages, and it serves the larger community to collate all lessons from its practitioners. 

Can Program Managers make it to the Executive Suite?

Notes from 4th International PMO Symposium

I had the wonderful opportunity to attend recently concluded 4th International PMO Symposium at the beautiful Loews Royal Pacific Resort in Orlando, Florida from 6th to 9th Nov 2011. I was invited there as a speaker, and more on that in a little while, but let me share what I learnt there.

PMO Symposium is organized annually by the PMI PMO COP and is the largest and surely the best such event globally. This year saw over 435+ attendees – double from the last year! Though the participants were predominantly from the US, there were folks who flew down from Switzerland, Finland, Mexico and Saudi Arabia just to listen to various experts and practitioners talk about the thoughts, trends and advances in PMO profession. The largest participation still is perhaps from the conventional industries – utilities, nuclear power plants, construction, government regulators, confectioners and then the good old IT departments in many such industries.

This year’s theme was aligning execution to strategy and going by the issues addressed and the participant interest; it seems that is the hottest topic in most organizations globally.

Pre-conference Workshops There were four pre-conference workshops on Day 0, which happened to be a Sunday. While there were far more interesting Universal Studios attractions and thrill rides tempting and teasing us from a very close distance, I chose to use my Sunday afternoon productively and signed-up for “Essential Considerations for PMO Design and Development” by Terry Doerscher and Mark Price Perry, Founder BOT International. Both are industry-recognized experts and speakers on strategic planning, PMO and portfolio management. All four workshops were overbooked, and at $89 pricing apiece, it was a great way to learn of new ideas and trends from the practitioners and experts alike. Terry and Mark reminded us that PMO is a service organization that serves unique needs of organization through servant leadership. As per them, the core PMO functions are:

  • Gather and distribute information
  • Manage Demand
  • Reporting and Analytics
  • Coordination and collaboration
  • Issues and Opportunities
  • Capacity Management
  • Process and Tools
  • Specialized expertise and reporting

The prerequisites for PMO, in their words, are:

  • Significant chronic opportunity for improvement
  • Common to multiple areas of organization
  • Unaddressable by current structure
  • Expected ROI outweigh estimate costs

I think this is a very interesting articulation of why, when or where do we need a PMO. Having seen many instances where executives or other stakeholders struggle to figure out why exactly they need a PMO, it could serve as a simple and smart way to check if a PMO could help them. Significant chronic opportunity means we don’t simply jump with a PMO solution to every problem that comes our way. Also, there could be very specific problems that are perhaps best addressed by other conventional means than having a PMO in place. And finally, the current means must have been tried and exhausted before we turn to a PMO as a panacea (which it surely isn’t :)). The Cost-benefit analysis is simply good business decision-making at work. If any of these are missing, we might perhaps be solving the problem sub-optimally. That is not to say the problem can’t be solved by PMO, but that the PMOs would typically create maximum value when all these ‘prerequisites’ are present.

And finally, the PMOs drive values by:

  • driving consistency and alignment
  • create economies of scale
  • mechanism to provide new service or capabilities

A key thing here is that PMOs of the past were the dreaded and shunned lot because they drove consistency and alignment via ‘process terror’ (not Terry or Mark’s term, but rather my own take at it), but today’s PMOs are really all about facilitation and collaboration. Instead of the conventional ‘push’ approach that hardly works anymore (if at all it ever worked!), the PMOs today are expected to ‘pull’ the organization together and create an alignment.

Overall, it was a good workshop where we strangers got working together on each table and got to know each other as we identified and discussed PMO functional roles and responsibilities, structure and reporting, operating assumptions critical success factors and PMO development and operation in our respective organizations and learnt a great deal in that process. I would always recommend signing-up for such pre-conference workshops irrespective of your experience level – there is always something new we can learn in such sessions J, and it is such a wonderful networking opportunity, especially if you traveling out of town to the conference venue.

Keynotes I am a big fan of keynotes because they allow prominent thought leaders in the subject space to come forward and share insights and also create some controversies. To me, a keynote is not worth it if all the speaker does is confirm the conventional thinking. It should bring new ideas to the audience and dare to raise pertinent issues that set the tone for the conference and beyond.

There were two wonderful keynotes. Iain Fraser, an internationally recognized thought leader and a PMI Fellow, talked about governance and Jim Furfari, and ex-airforce pilot and instructor regaled the jam-packed Pacifica Ballroom in his unique way. Iain shared the mantra for good governance in his keynote “Governance: What does it really mean for a P3M Environment?” as – Future Focus, Identify Issues and Communicate, Compliance and Risks, KPI Monitoring, and Skills and Succession. He also shared some findings from the EIU Survey of 600+ C-level execs where the most important skills at individual level was identified to be ‘Execution: the ability to get stuff done’ and the most important capability for organizations is to find leaders to implement change. 72% of the respondents stated their organizational performance suffered due to lack of skills. Now, that’s lot of food for some serious thought! Finally, to sum it all, he elucidated the key attributes of successful governance, and two of them that resonated extremely well for me were – align horizontally and vertically, and use balanced scorecard approach to align policy, people, process and performance to create roadmap to excellence. This was music to my ears as my recent work has been on these lines and I have come to believe that organizations that can scale-up and sustain their success can only do if they are able to create and maintain such alignment and lockstep processes and people to create blueprint for excellence. Even my talk at the PMO conference had this alignment as one of the key themes and a critical success factor – it was a great validation of the approach from an expert.

Jim is an ex-airforce-pilot who used a lot of humor in his talk “Finance is Not an Option! The PMO Role in Enterprise Strategy” to talk about what maturity (rather, the lack of it) can do. He claims to have a unique expertise on both – building and bombing bridges! If you don’t believe in ‘maturity’ of your project managers, all you had to do was look at five video clips of airplane landings that he showed with progressive competency to handle higher complexities and constraints. If you don’t want to be piloted by a lower maturity pilot, why should expect your customer to accept his project being managed by a lower maturity manager? In his views, PMOs should be seen as ‘tough and competent’ – tough when the situation demands them take-over the situation and lead from the front.

Presentations There were 29 speakers from Australia, Greece, India, New Zealand, South Korea, Switzerland and the US. The presentations were top-notch and represented the growing importance of PMO in today’s business, especially concerning alignment of strategy to execution. It was pity that one could only choose one presentation from the three simultaneous ones, but the program guide and the symposium CD circulated at the registration provided enough information about the presenter and synopsis about the talk.

After every presentation, there was a generous 15-minute transition time for the next speaker to set their session. This gave ample opportunity to audience to network among each other and also catch up with the speakers.

My presentation was around my current work on business excellence where we are looking at creating a holistic program and not just focus on hard metrics. We have identified four pillars – culture, execution, innovation and operations as the key drivers of organizational excellence, and creating the lockstep is the key to achieving holistic results. The organization goals are broken down into horizontal and vertical goals which are then executed and tracked in quarterly reviews using a homegrown scorecard that allow us to track holistic progress for the organization. You can view my presentation “Orchestrating Excellence – The Yahoo! India way” and also the paper “Strategic Alignment of Horizontal and Vertical PMO Goals” that was earlier selected at the PMI National Conference, Bangalore, 2011. The paper talks about the approach taken in more details while the presentation is a high-level introduction to the framework.

Networking and Socials Microsoft hosted the day one social at the beautiful Hard Rock café. We pretty much had the entire care at our disposal and provided great opportunity to mingle with like-minded PMO professionals from all over the world over cocktails, fun games and Xbox. I met some very folks who are doing business with India and some of the very interesting learning was that almost everyone had similar situation – I have a team in India and these guys never open up. They remain quiet in meetings and I can never get them to participate enough in proceedings of the team. How do I change this situation? Not meaning to sound rhetoric, I did offer my 2 cents, but it left me thinking – on one hand where we are talking about raising the game for PMOs to get a seat at the table, most of them are also struggling to get their India teams to get onboard. Are we, the India teams, going to be the bottleneck? I hope not, but I also realize that I haven’t seen much change in this situation in last twenty years. If only we had a magic formula!

Vendors Vendor participation was simply fabulous. Right from Microsoft, Oracle, Planview, Eclipse, BOT International, to IIL, George Washington Universtity and even the PMI Bookstore, they were all there. Most of them were competing in the PPM tools and I thought Planview was the
only one where I saw the good old familiar “product funnel”. However, if you were shopping for the latest and greatest PPM tool in town, that the place to be. It indeed was an excellent forum to compare and contrast vendors and tools.

The highlight of vendor booths was the to-die-for sweepstakes! With iPads, Kindles and Laptops up for grabs, it sure made it even more worthwhile to go over to booths and check their offering out. I waited with bated breath to hear my name among winners, as were most of us, but alas, perhaps some other time :).

Conference Organization and Logistics If ever there was a conference going to be organized by the PMO professionals, it was only expected that it lived up to the highest expectations of meticulous planning and flawless execution that the PMO profession has come to be  synonymous of. And it surely exceeded expectations on every count! From the initial call for presentations to the selection of venue, scheduling of events, organizing logistics, not only everything was on time, it was also done absolutely error-free.

The venue choice was superb and the hotel service was flawless. The lapel mikes and on-screen projectors simply worked without any support staff! The break-out areas were large and allowed good resting places for those tired legs. I especially liked the small device that converts Blackberrys into handheld scanners. Whether you went to a presentation or to a vendor booth, your name card was scanned and lo and behold, all your contact information was instantly loaded in their back-end system. Vendors used it for their own visitor data, and of course, the sweepstakes. The conference organizers used it to record the attendance for PDUs! Their promise is that the PDUs will be uploaded for all participants! How about that?

Lessons Learnt This was a unique session that I never thought could be such a powerful way to end such a wonderful conference. We were down to the last hour on the last day and with less than 80-odd participants left who got together in this last session that stood between them and their flights home or Universal Studies park tickets, I for sure didn’t know what to expect. At best, a boring session and at worst, people walking out of the session!

Rommy, Frederic and Craig got us together and asked us to make groups of 5-6 folks sitting together and share what we felt came across as the two most compelling takeaways and then whittle it down to 4-5 per group. I think it was only apt to do some introspection, both individually and as a group, to condense so much of knowledge download over the past four days into the most important learnings. Then we went round the room and each group shared their views, and here are the themes and ideas that came up loud and clear:

  • Strategic role of PMO
  • Focus on organizational PMO – not just methods and consistency but benefits realization
  • Show value of PMO to organization
  • PMO is really to solve a problem, not to find a problem
  • Strategic attractiveness is not just about money
  • Change driver within the organization
  • Importance of communication – eve level and with stakeholders
  • Focus on strategic alignment
  • Involve more than just the leadership team
  • Focus on value provided to business
  • Org structure: where should the PMO report – it is important to adapt to reporting level
  • If you can drive your strategy through the organization, you make yourself valuable
  • Integrating agile in the org
  • Ingantibles can be part of the expectations
  • Project management is not a certification but a profession
  • Need to move out of the weeds and become more strategic and ask org how they can provide more value
  • Don’t just track the deliverable but the value of deliverables
  • Move forward from measuring project metrics to business value
  • Voice of the customer
  • Raising the level of PMO to influence the org

Hopefully this gives you a flavor of what was discussed and what people walked away with.

Road Ahead I was fortunate that my presentation was accepted and event organizers extended me the opportunity to come and present. To sweeten the deal, they waived off conference fee, offered complimentary hotel accommodation during the conference and even offered to reimburse the airfare to the venue (though my company picked that up as I was traveling for work at the same time)! Could there ever be a better incentive to become a presenter! I am thankful to my employer Yahoo! for allowing me to make my presentation. I got some good takeaways from the conference that I intend to put at work. I also hope reading these notes will inspire you to put up a proposal for next year, and if I could be of any help to you in this regard, I will be happy to oblige. I am surely looking forward to making another good proposal for the next year’s conference…

More details You can get more details at https://www.facebook.com/pages/PMO-Symposium/119305434821907?ref=ts or http://www.linkedin.com/groups?gid=2089137&trk=myg_ugrp_ovr. Frederic also wrote about it in a blog post.

What are the program management competencies?

Program managers are the glue that bring your best people and teams together to collaborate like never before. They crack the hardest problems by cutting through the red tape in your organization and aligning them to the single goal. Clearly, a lot depends on having the right program manager in place. How do you hire or groom good program managers? Or, in a large organization, how do you ensure that your program managers have similar minimum competencies across the organizations? You might or might not have a single program management framework, but it might still be a good idea to have some model that allows you to baseline your program management competencies.

Levin-Ward Program Management Competency Model

Levin-Ward Program Management Competency Model

Last week, I sat through an evening session by J Leroy Ward, who has recently co-authored a book on “Program Management Complexity – A Competency Model” with Ginger Levin. He talked about the Levin-Ward Program Management Competency model that they have created. They have identified two categories of competencies – six performance competencies related to the functional ones and another eight personal competencies relating to the soft-skills. While the specific competencies are not really new, and the performance competencies are more like the specific ‘stages’ in a program lifecycle – Defining, Initiating, Planning, Executing, Monitoring and Controlling and finally Closing, they have put in efforts to specify what exactly contributes those competencies. The personal competencies relating to soft-skills are Leading, Building Relationships, Negotiating, Thinking Critically, Facilitating, Mentoring, Embracing Change and finally Communicating. I would recommend it for any newbie to program management – it could serve as a good roadmap on what to learn and focus on. The book also gives self-evaluation questionnaires for organizations, program managers and prospective program managers.

During the Q&A with Leroy, many folks (incidentally, majority were from Indian service companies – which is a very interesting phenomenon because most of them don’t have a company-wide program management function today) asked questions that seemed to indicate that the ‘Indian’ context was missed out. For example, there were specific references to cultural sensitivities, managing globally distributed teams and so on.

I also pitched in with my 2 cents and offered my views on two program management competencies that I consider fundamentally different from project management. I mean all those 8 personal competencies in Levin-Ward model are kind of ‘similar’, or linear extension to what you would expect a project manager to possess – albeit in little lesser proportions. However, these two competencies, at least to me, represent a fundamentally different and additional skills required without which a program manager can’t simply operate. Let’s discuss them:

Lead by Influence

Influence and Authority are extreme ends of a continuum. When there is very high authority, the ‘leader’ need not have any personal credibility – the followers have no option but to simply follow the ‘orders’. Needless to say, this is the old world that is rapidly falling out of favor. The new world order requires leadership to embrace influence to bring about necessary change.

In majority of organizations, more so in today’s matrixed organizations, a program manager has no direct or indirect people responsibility. He has no ‘positional power’ to lead by ‘authority’ anymore. This is a significant change from the classical project manager who typically has solid line reporting of his team under him. Even though the command and control model is long dead and buried (but perhaps still alive and kicking in some old world industries and governments), the project manager still wields ‘reward power’ for he allocates responsibilities, approves resources, writes their appraisals, determines their salary revisions and makes recommendations for their promotions and other career progression avenues. So, while on a day-to-day basis, we can argue that teams are ‘flat’, there is always this invisible hierarchy that is present at least in our minds. Contrast to this, a program manager is devoid of all such ‘reward powers’. He might have a bigger responsibility mandate than the component project managers, but he still has considerably less ‘power’, both positive and negative, to motivate (or coerce) team members to achieve the program objectives. In today’s complex problems, it takes more than a monolith silo to deliver! There might be individuals and teams spread across the organization, or even outside, all of whom must collaborate in real-time to deliver a solution.  In such scenario, the program manager must rely on his ability to lead by influencing the component teams. What does it mean?

Leading by influence means establishing personal credibility and accountability and earn trust among rest of the program team. It doesn’t mean doing everything by himself, but by facilitating collaboration of work within and across the team. It doesn’t mean dropping names to coerce the teams to somehow reluctantly agree on some artificial top-down resource and schedule constraints. It means listening to issues from all component projects and adjusting plans to achieve the program goals. It means tearing down the silos by establishing trust and transparency and helping people succeed with each other – not at the cost of each other. This article “The Language of Leadership” by Nancy MacKay nicely identifies ten leading by influence skills. I think that makes a great list.

Tony Wagner has identified it to be among seven survival skills (and I would strongly recommend checking out other six skills as well). Leaders like Mahatma Gandhi and Mother Teresa led by influence. It’s high time we learnt this fine art.

Manage at Interfaces

Project management requires fortifying a project to maximize its output. In a way, it is like a small tribe that must protect its interest over everything else. However, a program is like a much larger state that must not just look after interest of its multiple tribes but ensure that that the sum total of it all is maximized. Its primary interest is in the ‘outcomes’ that lead to creation brand-new or significant and sustainable enhancement in existing capabilities of an organization or a society. For example, Bangalore Metro is a program, whereas its components like individual metro stations, or the tracks, etc. are its component projects. While a component project manager is interested in ensuring that he hits the deadline and quality bar for his project, the overall program manager must work with all individual project managers to create a program plan that identified and manages interdependencies and allow the most optimum outcomes to be created at program level. To that end, the program manager doesn’t have micro-level control over what goes on inside each project. He must resist the temptation to micro-manage each of the component project les he loses the oversight of overall program (and also, quite possibly, upset the component project managers by such intrusion). He must manage at interfaces.

What does that mean? First of all, this is not a recognized term (a search for this phrase led me to just two pages on the net, both of which were in a totally different context). Managing at interfaces means establishing a two-way trust with the project managers that allows everyone a space to perform while focusing on the higher-order ‘outcomes’ of the program. It means involving all key participants and collaborators, identifying establishing interdependencies and establishing collaboration mechanisms that allow the program to flow smoothly without anyone getting overinvolved in other component’s inner details. The aspect of managing at interfaces is not just limited to program manager alone – it is also required that other component project managers also establish similar levels of trust among each other. Why is all this important? Well, there is a segregation of responsibility. Unless you are working in a trivial program (in which case you might argue why do you need such elaborate management structure overhead?), there is every need to establish structures and mechanisms that would allow smooth flow of outputs from one component project to another, and if we allow them to get involved in white-box details of each other, we will not only lost the focus very soon, we also run the risk of back-seat driving – that of louder voice getting what it wants. We run the risk of breaking down common agreement and running the program on side-deals instead. Needless to say, this would be contrary to achieving common goals of a program.

Managing at interfaces symbolizes a sociological setup where teams trust each other and the program manager. It allows decentralization and appropriate division of responsibilities by eliminating any overhead that could breed mistrust. Obviously, this is an end-state that is achieved by upfront investment by program manager (and the organization as a whole).

So, there you have it. Do you recognize that program management is not just an overgrown project manager? Does your organization realize that more of whatever the project managers have been doing in past just won’t qualify and train them for program manager roles? Do you recognize that apart from performance competencies, your program managers need a completely different set of skills that allow them succeed? What are the program management competencies?

Project Management vs. Program Management

Program Management is often seen as the next logical step for seasoned project managers looking to take on bigger challenges. While project management is more about managing within boundaries of a project and gatekeeping it against anything and everything that threatens the status quo, program management is typically all about breaking those very boundaries and managing across them by taking up anything and everything that threatens the status quo. In this post, I will examine how they differ in its approach on two important aspects – scope management and people management.

Scope Management

Like I mentioned above, a project’s success depends on its ability to retain focus against all odds. Once a project scope is defined, its estimates made, resources  allocated and commitments made, the project manager is pretty much focused on gatekeeping everything else out of the scope lest the project success is threatened. In reality, most projects would have a CCB, or a Change Control Board, of some levels of formal authority, there is still a tendency to bulk up the entire requirements in first-pass and do as much as possible in one breath irrespective of how much time it takes and whether the final outcome is acceptable to the customer or not. While most of the traditional world still likes this model for various reasons, software development community identified this as a bottleneck and created the suite of so-called ‘agile methodologies’ that exploit software’s ability to incorporate late changes to specs without seriously endangering the project or its deliverables. Still, at a high level, a project must work around a reasonably stable set of requirements to ring-fence itself against any potential changes to the ‘core’ of a project – the premise being how can you build a successful product on a shaky and wobbly foundation. After all, don’t we pay product managers to do a better job of defining those requirements upfront rather than changing their mind later in the project and calling it as customer change request to cover up what they failed to think of in the first place! Surely, everyone understands changes in workflow or bells and whistles, but I am talking about the core architecture – the fundamental DNA of a product that must be understand before any further allocation of time, money or resources is made. So, clearly, scope is sacrosanct to a project.

A program is a different beast. As the highest level of body chartered to translate an organizational’s strategic intent to reality, it can’t box itself inside any boundaries of defined or undefined scope. Anything that could impact a program’s ability to accrue full ‘benefits’ envisaged from it must be taken up. While in theory, a program must have a defined scope to plan its activities and resources around its deliverables, in practice it is not so trivial. Any reasonably large program has sufficient number of moving parts, uncertainties, conflicting requirements and rapidly changing priorities. It is very typical in a program for the component project managers to carve out their pieces very sharply. A lesser reported fact of life is that developer’s motivation to work in newer and sexier technology often dictates the choice behind a project taking up (or refusing to take up) a given problem. Program organizational structure and governance plays a very important role in ensureing that component projects are not only cleanly defined, they also identify inter-group dependencies and secure commitments to address them. To that end, a project might safeguard itself by rejecting an inter-group request, but eventually the program needs to address it! Similarly, a project manager might complete the work within her boundaries but it takes much more for the program to be ‘done’, let alone be successful. I have seen many situations where project managers would be so focused on their project that they won’t recognize that unless the program was successful as a single entity, their individual progress was meaningless. This could get aggravated when teams are geographically or organizationally dispersed. However, none of those can hide or discount the fact that a program is only as  successful as it ability to influence things that might not be in its line of control but whose impact is definitely in a project’s line of success, especially if those things were to backfire.

While a project is like a fortress that must protect itself against all invasions to survive and eventually be successful, a program is more like a university, a rose garden, or a mission – they all deal in ‘soft power’ and maximize the ROI of their mission by keeping their doors open and by teaming up with their potential adversaries.

People Management

A project manager in a functional organization wields significant ‘positional power’ and thus has very high ability to influence team members behavior. While today’s organizations are highly flat and democratic, there is still an asymmetric balance of power, for the manager who writes your focal and annual salary revisions also potentially has the power to decide when you should update your resume! Surely we have come a long way in management-worker power-sharing from Taylor and Ford era, make no mistake that there is no such thing as a perfectly symmetric world where a manager and her team member have equal rights. Thus, a project manager has much higher ability to define the work and assign people to it as she feels appropriate. She also has a much higher level of responsibility towards training and career development of her team members, and being the closest face of management to the team, she is the official spokesperson of the upper management. A team will likely listen more to her than to the CEO. She must balance two opposing sets of expectations that, if not aligned properly, can set the project on fire. To that end, people management for a project management must be one of the toughest job.

In high contrast, a program manager manages at boundaries of participating organization in a highly matrix environment, and hence must manage by influence and not by any formal authority. In a software team, a program manager needs to get Development, QA, Product Management, Usability, Documentation, Marketing, and several other functions on the same page. In most organizations, they are organized along the functional lines and hence report to a solid-line manager in the same skill-set pool rather than program manager. Given that many of these resource might be timesharing on a program, their eventual loyalties are still with their respective line managers and hence a program manager can only rely on collaboration and influence as the key measures to get everyone onboarded. In some cases, there might even be a conflict between a component’s goals and the program’s goals and if such issues remain unresolved, the only recourse to make the program successful might be to move the problem up the command chain. Still, there is a big value in managing large and complex endeavors as a program, for it allows an organization to manage its resources and inter-group dependencies and conflicts in a more systemic and transparent manner. Some of the best program managers I have seen were not the ones who stopped managing the interfaces, but went over and above what their jobs required. They established a direct contact with key team members in component projects and created an alternate informal channel to validate project risks and plans, and to feel the pulse of the organization. They would do it very unintrusively without creating any friction between the line manager and them.

How does your organization view these two important functions?