Project Management

10 Key Lessons From 10 Years of Program Management

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog


View Posts By:

Cameron McGaughy
Lynda Bourne
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Wanda Curlee
Christian Bisson
Ramiro Rodrigues
Soma Bhattacharya
Emily Luijbregts
Sree Rao
Yasmina Khelifi
Marat Oyvetsky
Lenka Pincot
Jorge Martin Valdes Garciatorres
cyndee miller

Past Contributors:

Rex Holmlin
Vivek Prakash
Dan Goldfischer
Linda Agyapong
Jim De Piante
Siti Hajar Abdul Hamid
Bernadine Douglas
Michael Hatfield
Deanna Landers
Kelley Hunsberger
Taralyn Frasqueri-Molina
Alfonso Bucero Torres
Marian Haus
Shobhna Raghupathy
Peter Taylor
Joanna Newman
Saira Karim
Jess Tayel
Lung-Hung Chou
Rebecca Braglio
Roberto Toledo
Geoff Mattie

Recent Posts

Commercializing Agile

4 Keys to Lead Through Uncertainty

Enduring Through Uncertainty: Move Forward with Character

Triads in Agile: The Path to Efficient Decision Making

Measure, Measure…and Measure Again!

By Sree Rao, PMP, PgMP, PMI-ACP

From rookie mistakes to hard-won victories, my decade-plus journey as a program manager has been full of lessons. Here are the ones that stuck with me the most. As you ring in 2023, I hope these lessons will help you on your PM journey.

1. Don’t get too caught up in processes and labels. In my early career as a PM, I was stuck on implementing agile methodologies like scrum, Kanban etc. With experience, I have come to realize that it is important to figure out a process that works in the team-specific context rather than sticking to the labels of agile versus waterfall.

What is effective for one team might or might not work for another team. We get better engagement and buy-in if we involve the team in setting up processes and make the changes that the team recommends. It is important to rely on the collective wisdom of the team.

2. Don’t try to control the outcome of meetin­­gs. I place a high value on clear agendas and sticking to them in meetings. However, there have been occasions where my meetings did not go as planned. At first, this upset me, but I eventually came to understand that it is our responsibility to be prepared (and we cannot always control meeting outcomes). It is important to read the room and adapt meetings as needed.

3. Don’t overload yourself. During the early stages of my career, I was hesitant to decline additional work, even if my workload was already overwhelm­­ing. I was afraid of not meeting expectations.

However, it is important to be aware of your own limitations and feel empowered to say “no” when necessary. While we may not always have a choice, it is important to carefully consider how much work you can realistically handle. Is it better to do a good job with what you already have on your plate, or lower the quality of your work by taking on more?

Constantly being overburdened with work can prevent you from having the time and energy to identify opportunities for personal and team growth.

4. Don’t be a default meeting scheduler. There is a misconception that it is a PM’s job to schedule meetings, and as such I have often been asked to schedule meetings and take notes. However, this is not the primary focus of a PM role. To better manage my workload and prioritize, I have learned to say “no” to scheduling meetings unless I am driving the agenda or have a significant interest or stake in the meeting outcome.

While I may make exceptions in certain cases (such as when I need to expedite something), I have learned to be more selective about the meetings that I agree to schedule.

5. Identify single points of failure (SPOF) for projects and their mitigations. As a Technical Program Manager in the tech industry, I have often managed projects where only one engineer is assigned to a project. This is a big risk, as that engineer is now a SPOF for the project.

Whenever possible, it is advisable to request that at least two engineers share the workload of any deadline-sensitive, critical projects to reduce the risk of unanticipated personal emergencies or other risks. Apart from reducing the risk, this also helps with improving team morale as the engineers have someone else to bounce ideas off—and share the workload.

6. Put things in writing. It is important to document commitments or decisions made during your hallway or informal conversations in writing for future reference. Putting things in writing often leads to more careful consideration and follow-through from your team members.

Personally, I have learned the hard way to always get things in writing to avoid any misunderstandings or miscommunications later.

7. Encourage proof-of-concept development. If your team is stuck in analysis paralysis, or if you are trying out a new technology, get management buy-in to spend time creating a proof of concept or a prototype. This can help to quickly demonstrate the potential of the technology or approach and facilitate faster decision making.

8. Include key stakeholders in reviewing status reports before they are published. Early in my PM career, I gave more importance to adhering to timelines than to aligning with key stakeholders. One time, I marked a project as red (behind plan) in a report without first discussing it with the manager of the team that was running behind. That manager was unavailable, and I did not want to delay publishing the status report.

I went ahead and published the report without reviewing it with him. This had unexpected negative consequences, including the manager having to explain the red status to multiple members of the leadership team.

Since then, I have been more careful about how I report project statuses. Before turning a project status red, it is important to consider possible mitigation plans and to review the status with all relevant cross-functional team members and their management. This may slow down the process, but it ensures that all key stakeholders are aware and aligned on the status.

9. Identify projects/programs to cancel. Deciding to cancel a project or program can be challenging, especially if a lot of time and resources have been invested. However, it is important to consider whether the project is still delivering the value that was expected.

Don't let the sunk-cost fallacy (the tendency to continue investing in something simply because of the resources that have already been spent) influence your decision making. It's better to cancel a project and move on to higher-value projects rather than continuing to invest in something that is no longer worthwhile.

10. Be cautious about reporting program status as green/on track. In my experience, it is rare for all the projects in a program to be on track. If you do encounter a situation where all the projects seem to be progressing as per the plan, it’s important to carefully assess the situation and verify that thorough risk analysis has been done.

While there are several other valuable lessons I've learned, I've distilled my most valuable lessons into these top 10 nuggets of wisdom. Project management veterans, what valuable insights have you gained throughout your career? Share your nuggets of wisdom in the comments section below!

Posted by Sree Rao on: January 03, 2023 01:49 PM | Permalink

Comments (23)

Page: 1 2 next>

Please login or join to subscribe to this item
Thank you for your insights Sree

Dear Sree
Very interesting the theme that brought to our reflection and for debate
Thank you for sharing these 10 key lessons.

When key stakeholders are late in reviewing status reports and this has an impact on projects, what lessons have you learned? (prioritize the project or keep stakeholders informed)

Dear Luis, thank you for always commenting on all the posts. It is encouraging to see your comments. Really appreciate your engagement on these blog posts.

Regarding your question - when I am in a situation where key stake holders are not available to review status reports, if everything is on track or slightly behind plan, I don't wait. If anything is controversial then I wait for a day or two until I get alignment. In some situations I have even skipped publishing the reports for that week (some companies are not so strict about status reports and so it was ok to skip).

If it is impacting the projects then I do not wait but take it up the management chain.

Hope this answers your question.

Well written article. At the end of the day, being pragmatic matters. And I love the last one. There are programs which suddenly turn into orange or red from green. A thorough risk analysis is required here before reporting. Though on the SPOF, I feel it is a waste of resource to assign two engineers for the same project or task. The lead must know what is going on and who will be capable to complete the job if point of failure does occur.

Thank you for sharing. I truly think that putting important topics in writing is critical. If not in writing anything discussed will be blurry within a day or two, and if a few days go by, any perceived agreement or commitment could lose clarity and cause problems down the line.

Thanks Vijay. Re: SPOF, you are right that it does not make sense at task level. But if we consider critical time sensitive projects, it will not be a waste of resources if we allocate according to the need. Ex: If two engineers are working on two different projects 100% of their time, we could have them work 50% each (or 60%;40%) on both the projects. One of the engineers could be the primary on one project and secondary on another project. This way we would have enough coverage for critical projects. Even though the lead may be able to step in times of unanticipated emergencies, having two people working on a critical project de-risks it and also improves engineer morale as they wont be working in silos. This has been my experience.

Thanks Yasmina and Jorge for your comments.

Very insightful, well written.

Great tips! Thanks for sharing.

Too Good, pinpoints some of the mind blocks i had/have and cleared it with alternative solutions.

Thanks for the insights, Sree.

Fully agree, thanks!

Insightful! Thank you for sharing

Very practical and useful. I just shared it to my community on LinkedIn.

Beneficial article
Thank you

Good post. Matches my experience too!

Thank you for the insightful post.
In your experience, do you communicate the complete risk register to your customer (including how do you manage potential issues with this customer) ?

Belkad, I love your question because I love the debate about total transparency. I would say that YES but there are always people who prefer not to and I can understand why. I call it "politics" which is not my favorite topic but to some extends total transparency is also a big risk to manage so...

Willem, Stepane, Ramesh, Stephen, Oyedoyin, Anne, Norah, Chris, Thank you all for your comments!

Belkadi, great question. Anne thank you for your response. I agree with Anne that we have to be transparent.

I do think it depends on a lot of factors - your company's relationship with the customer, trust, your company's culture, severity of the risk / mitigation plans, any potential impact to contracts etc. It has to be dealt with sensitivity and due diligence. When in doubt, run it by your manager or the key internal stakeholders.

Anne, appreciate you sharing this post with your LinkedIn community.

Sree - While I agree with all of your points, the only that I would negate with is "Don’t try to control the outcome of meetin­­gs", it may not be possible to control the outcome every time, but most of the times it sits with PM, whoever schedules the meeting, otherwise time would not have been effectively spent and it may lead to further meetings for the same agenda.

Page: 1 2 next>

Please Login/Register to leave a comment.


"Nothing so needs reforming as other people's habits."

- Mark Twain