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.
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?
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).