Please login or join to subscribe to this thread
I'm assuming you mean a duplicate request as "by the book", a project is a unique endeavor and hence there shouldn't be duplicate "in flight" projects.
For requests, a few things to determine if it is a duplicate are:
1. Who is the sponsor?
2. What is the project's purpose?
3. What are the high-level cost or schedule estimates?
4. What are the in-scope and out-of-scope deliverables?
Duplicate? I think you mean"similar".
Generally, you shuold look for similar projects.
Kiron made good points.
In my experience 'duplicate' projects come up if two business groups/sponsors each have a problem, a potential solution to be implemented with a project and even their own budgets. And they often have no information about the other project.
If a PMO / Portfolio Manager notices both projects, there might be synergies in combining them. How to notice it, is your question.
Well, first have an educated look at the projects with specialists, maybe with the help of an architect or business analyst. Is there an overarching interest of the organization to integrate the two projects? Anyhow, what do they have in common? The overall goal (for each of the business units), the implementation, the operations once they are live. If you combine them, it makes the system more complicated.
Are you even in charge of integration? Whose interest is it?
There may be good reasons to keep them separated. Implementation will be less risky, ownership will be clear, you are experimenting more.
Thank you so much for your input. I am currently making a PPM guideline in a corporate level which will be standardized across the subsidiaries of our company. With this, the duplicate May stem wherein Corporate May have done a project in the past, a subsidiary May be doing a similar project. Should the completed project of corporate be extended to the subsidiary or should the subsidiary create a new project.
I guess I need to know criteria for this and how to evaluate the actions that should be taken
It is a new project. It may be initiated from corporate, have a corporate sponsor, use lessons learned and assets from the previous project.
But it has to consider the new timeline, different user base, power distribution which makes it another unique project, even if it has a similar scope and product.
In development, sometimes there is value to having very similar projects in a portfolio.
Two scenarios that come to mind immediately are:
1) Competing solutions similar to companies bidding on a project. They may be downselected based on trade-offs, or highlights of the approaches may be combined to a new solution integrating the benefits of both.
2) Your portfolio may include options similar to how people purchase cars. If you are offering solutions to customers, various solution options may be a better fit to their business model and having multiple to choose from may increase potential market share.
For me the critical criteria are 1) project purpose - what problem is it attempting to resolve, and 2) who is the sponsor - who will benefit from project deliverable (same as Kiron but in reverse order). The comparison need not be exact, the key question is whether there is an advantage in linking or combining the two (or more) initiatives or whether it is better for a stand alone approach. Once you have determined if the projects are compatible (not necessarily duplicate) the next step would be to engage the sponsors and/or major stakeholders and look for mutual advantages.
Looking at possible efficiencies related to linking projects, even when failing to do so, is much better than having to respond to later accusations - "you should have..."
Please login or join to reply