Submitted by labraham on December 7, 2009 - 8:38am.Monitoring the health of your program is critical to the ultimate success of the program as well as to managing the expectations of your business users and the steering committee. But program monitoring actually starts with monitoring the individual components / projects within the program and then rolling it up to the program level. I'll list them here and in subsequent articles, I'll put more details on each as well as potentially some examples.
Dashboard: A dashboard is critical for tracking the overall health of your project / program, and for communicating status to your business users and the program steering committee. While you may be as tired of the typical stoplight format of dashboards, as I am, used appropriately they are very helpful in highlighting problem areas that need your detailed attention. The typical components tracked are: Schedule, Resources, Quality, Budget, Scope and of course, Overall Health.
Milestones: Milestones are not project tasks. They are at a higher level and they represent an actual deliverable that can be touched / seen. They should also be small enough that you can have a milestone delivered at least every 2 weeks, and ideally every week. This is important because tracking % complete is really inaccurate, since you don't know if the last 5% takes 80% of the effort.
Risks: Tracking risks is something that needs to be an active ongoing effort, not an exercise at the start of the project. That is because as the project / program evolves, the risks change. So with risks, you should be tracking what the risk is, it's likelihood, the level of impact, and the migitation plan.
Dependencies: Tracking dependencies is another critical issue for success. Dependencies can be the need to coordinate with other projects within the program that are delivering components critical for implementing an end to end flow, it the need to coordinate with projects outside your program that will be competing for the same infrastructure or resources, and it can be the need to wait for the typically involved process of acquiring and installing new hardware in a data center.
Resources: Tracking the resources required to complete a project is a great way to highlight one of the biggest risks that you'll face. The resources you should be tracking are not just the people who are directly a part of your project / program team, but also the business users who will be the subject matter experts and a part of the user acceptance testing, and the infrastructure people who will be setting up databases, servers, operating systems, etc... If you can lay out the resources required and when they are required, you'll see conflicts between resources among the program components, and you'll also have a useful tool to visually present to senior management in order to obtain commitment for the availability of the resources that are not directly part of your project.
Schedule: A Gantt chart showing the schedules for the different projects and when they'll be in different phases is useful for aligning dependencies between the projects and coordinating their schedules.
With these components in place, you've got a good basis for monitoring the health of your program and keeping it moving forward. As the program manager, you will definitely receive pushback from your project managers on the overhead required to keep all these documents up to date. So you'll have to be prepared to show them the benefits of having this information, both to the program and to their specific projects. I'll cover those benefits when I talk about each component in detail.
Trackback URL for this post:
http://www.allianceglobalservices.com/trackback/477
|
Recent comments
1 day 4 hours ago
1 day 4 hours ago
1 day 4 hours ago
1 week 46 min ago
1 week 8 hours ago
1 week 11 hours ago
1 week 1 day ago
1 week 2 days ago
1 week 3 days ago
1 week 4 days ago