Voices on Project Management

> Back to Voices Home

Multi-Project Schedule Planning, Part I

| | Comments (1)
Projects are rarely planned and executed in isolation. In general, they have external dependencies on activities, tasks or deliverables outside the project's reach. Managing tasks and dependencies that spread across several projects, which are not necessarily part of a program, creates a multi-project management context.

For instance, say you are managing an IT project, delivering a software application. Many of your project tasks will be conducted within the project's boundaries and with the full control and ownership of your project team. Nevertheless, your project has dependencies on a software component, developed in parallel by another team within the same enterprise, yet as part of an entirely different project. Your project will have to wait for the other team to finish and deliver its component to deploy and test your software application. Since the two projects have phases and deliverables dependent on each other, their project schedules will have to be correlated.

Managing correlated schedules requires a different approach. In a single-project context, a project manager plans the schedule, giving consideration to the project context, the work to be carried out by the project team, assumptions, risks, and the tasks' internal and external dependencies. This is more or less a silo approach, where the external dependencies rely on deliverables and not on the project phases or cycles in which they are produced.

In a multi-project management context, the project managers involved, or an overseeing multi-project manager, will have to reach alignment across the projects in several aspects, including:

  • Aligning project stages and deliverables depending on their interrelated dependencies
  • Reaching agreements and locking down commitments for respective conditions, such as the quality of deliverables, meeting deadlines required for the touch points between projects  
  • Sharing risks and planning required measures together, in case one project negatively impacts the other
Let's go back to our previous IT project example, and how alignment could happen. The two projects start off independent of each other. Then they can have touch points during the requirements analysis and scoping phase, when your project team will analyze and hand over requirements and product specifications to the other team. Then the two projects will meet again during a joint testing phase, when both project teams will deploy and test their application components integrated together. Finally, the two projects will meet again during the go-live deployment, when the rollout of one project will not be complete without the rollout of the other.

The more touch points the projects have, the more complex their schedule planning will be. The stronger their dependencies, the less flexibility you will have when planning your project schedule. And the more relevant the other project is for your organization, the less planning flexibility and schedule control you will have on yours.

The situation gets even more complicated when your project depends on three or more other projects, which have different schedule plans, business criticalities and even project management approaches. For instance, your project is conducted in a waterfall methodology, and it's dependent on another project following an agile approach. It can become quite challenging aligning your waterfall schedule to the iterative and dynamic schedule of the other project.

What is your project scheduling experience with dealing with multiple projects that depend on each other?
 

 

Bookmark and Share

 

The views expressed within the PMI Voices on Project Management blog are contributed from external sources and do not necessarily reflect the views and opinions of PMI.

Leave a comment

All comments are reviewed by our moderators, and will not appear on this blog unless they have been approved. Comments that do not relate directly to the blog entry's contents, are commercial in nature, contain objectionable or inappropriate material, or otherwise violate our User Agreement or Privacy Policy, will not be approved. For general inquiries not related to this blog, please contact Customer Service. Please read the Comments -- Question and Answers.

1 Comment

Thanks for your interesting article. I may add that some additional complexity comes to the table when shared resources are also included in the equation.
It would be really helpful to have your insights for that as well as for how to handle, at the portfolio level, projects within different programs that are not hard logically linked to each other but inter-relate for shared resources, by subcontractors' capacity or even by a product of the project that provide service to the other one such as a expanding a marine port (transportation program) and improving road access to that area (Infrastructure program).

About This Blog

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.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll

Categories