Program Status Meeting

  1. Apart from running regular daily standup meetings with development/engineering team, it is important to run Program Status Meeting involving engineering, program management, product management , sponsor and other important stakeholders.
  2. It is important to use program management plan in program management tools and/or deck.
  3. Purpose of this meeting is to under how we are tracking towards our deadlines. Also align on the program progress, address roadblocks and discuss next steps. This also helps brainstorm solutions to program roadblocks.
  4. The frequency of Program Status Meetings can be weekly, every 2 or 3 weeks or 1 month depending upon program complexity and stakeholder alignment. Ideally Program Status meeting should occur in weekly or every 2 weeks frequency. Decide on frequency at program kickoff/start and maintain and hold these meetings as per frequency
  5. Program Manager should start with Status of Program. Status of Program can be Green, Yellow and Red. If Status of Program is Yellow and Red, mention corrective actions.
  • Green: On schedule, on budget, all good.
  • Yellow: Potential issues with schedule or budget, but both can probably be saved with corrective actions.
  • Red: Serious issues and the project will probably be delayed or have significant budget overrun.
  1. Start the meeting by going over Program Gantt Chart. Program Manager goes over current week program activities planned from Gantt chart and highlights the stage the program is. Program Manager should clearly state whether the program is in Design, Development, Testing , Deployment or Support phase. Program Manager should clearly highlight all dependencies for current and next week. Program Manager should also highlight major deadlines and milestones in the future weeks
  2. Program Manager or Scrum Masters of different teams share their team updates. Updates should include what team did since the last time they met, what team will do till the next time they meet and any blockers or obstacles.
  3. Provide Status Update on RAID items and Capture new RAID items – RAID stands for Risk, Assumption, Issue and Dependency. Program Manager should review and share an update on existing Risks, Assumptions, Issues and Dependencies. Program Managers should also add new Risks, Assumptions, Issues and Dependencies to RAID backlog. Program Manager can also use this time to solve issues/roadblocks and also to remove risks/obstacles that can occur in future.
  4. Program Manager should then go over next steps. Next Steps should highlight next week program activities, steps to resolve roadblocks if any.
  5. After Status meeting is done, program manager should send Program Status update email which should include :
  • Milestone Completed since last status meeting
  • Milestone Missed
  • Milestone Planned till next status meeting
  • Risk log
  • Issue log
  • Action Items

Portfolio – Project Selection and Prioritisation

Portfolio – Project Selection and Prioritisation

As Portfolio / Program Manager, you will have lot of projects in your project backlog. As an effective Portfolio/Program Manager, you should prioritise the right project and select it for further planning and execution.

You need to prioritise projects by scoring/ranking projects on different prioritisation criteria. Some of prioritisation criterias that I recommend portfolio/program managers to prioritise projects are listed below :

  1. Strategic Alignment – You need to see if your projects is aligned to your organisation/department strategic goals and score it accordingly
  2. Financial Criteria – You need to see your projects ROI , Savings and Cost vs Benefit. Based on this , you can score the projects
  3. Risk Criteria – You need to also check how much risk is involved.

You can give different weightage and score for each of the above criteria and then prioritise your projects based on final scores.

This exercise will help convert your project list to prioritised project list. You can start planning and executing projects based on projects ranking in prioritised project list

Also, it is important to revisit the prioritised project backlog on monthly or quarterly basis to make sure you are working right projects which are high value to your organisation at that point of time

Author : Santosh Kumar Singh – Program & Product Management Professional

Cloud Architecture: Availability Vs Durability

Cloud Architecture: Availability Vs Durability


Availability refers to system uptime. Availability is achieved through hardware redundancy.  If any component fails, hardware redudundacy helps in system uptime .


Durability refers to long-term data protection, i.e. the stored data does not suffer from bit rot, degradation or other corruption. Rather than focusing on hardware redundancy, it is concerned with data redundancy so that data is never lost or compromised.

Cloud Architecture: Horizontal Scaling vs Vertical Scaling

Horizontal Scaling vs Vertical Scaling

Horizontal Scaling is also known as Scaling Out. Vertical Scaling is also known as Scaling Up
Horizontal scaling means that you scale by adding more machines into your pool of resources. Example : As web traffic goes up you add more web servers to take on the traffic.
Vertical scaling means that you scale by adding more power (CPU, RAM) to an existing machine.
One generally scale horizontally in Cloud

Cloud Architecture : What are Containers


Containerization is an OS feature where Kernel allows the existence of multiple, isolated user spaces known as Containers. These containers may appear as real computers to programs running in them as they have access to all the resources a real computer provides, like connected devices including network devices, compute power, memory, hard disk. However, a container is isolated from other containers & resources allocated to them.

What Containers help acheive ? Isolation, Co-existence of applications, virtualization of software, replication in different environments.

Cloud Architecture: What is Micro-services Architecture

Micro-services Architecture

Micro-service architecture is a software architecture where complex applications are composed of several small, independent services communicating with each other using APIs. These application services are small, highly decoupled and focus on doing a small task. Microservices refers to smaller and more manageable services that serves a specific use case. Microservices are generally deployed into containers.