Who should be on the PMO and Functional Teams?

This topic contains 6 replies, has 7 voices, and was last updated by  Thant Coleman 1 year, 9 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #65643

    Carli Luhrs

    Who should be on the PMO and Functional Teams?


    René Geltink

    As much as possible persons with experience in the specific business combined with experience in M&A processes. M&A is a very specific field of expertise in which it is very important to get it right the first time to make it work.


    Artur Dwojak

    Hello Carli, Rene,
    Appart of dedicated professionals from each area under investigation.
    Architects – on each level (Business, Application, Databases, Infrastructure)
    Process Analysts – especially on Business level
    and someone from Change Management.
    (I think something extremely important is to validate readiness for merge/acquisition on both sides).

    Next point… Program Manager and 2 – 3 independent consultants to validate and present results of final documentation analysis


    Lisa Chan

    I saw that the PMO in some organization involves cross-functional teams who are brought together on a temporary basis to deliver technical projects on-time and within budget. That is may be for strategic reason in execution of different types of projects.



    The PMO team requires skilled experienced people who align with the goals and who can act as leaders. The best should be on the PMO team. The functional team requires representation across all functions in the target co. Determining who should staff the functional positions can be challenging as perhaps the target functional manager fears for their future. In many cases it mat make more sense to have the functional leader from the acquirer lead the functional team.



    In our organization, the PMO is made up of the Project Mangers (or business leaders if that department doesn’t have a Project Manager) who are responsible for overseeing the work. The Functional groups include a business lead and participants from each org who are responsible for the work today. This is really important as the processes, tools, and technologies for each organization may be different – so you can evaluate what would be a best practice. Pre-close there was a business lead from each organization, and Post-close a new lead was identified to represent all.


    Thant Coleman

    First lets level set. Depending upon your PMO you’ll have various and many skill-sets within the PMO that may be at your disposal. Beyond the project managers and business analysts, some PMOs will have Accountants, Marketing and all sorts of resources that in theory could handle any effort within the organization and not have to matrix resources (or not as often) from functional areas in order to get projects done. Most are not staffed this way but PMOs like this do exist. Most PMO have project managers and requirements/business analysts and along with these resources there may be solution architects and so on … It totally depends on the organization. You may have to utilize resources that report to a functional area in the business and these resources may be 100% assigned to supporting the integration/project or working with the project and still trying to cover their “day” jobs. This may of course be elementary but sometimes we must state the obvious.
    With all this in mind, I would offer that regardless as to how you must acquire them, you’ll at least need the following;
    • Project Manager / Program Manager
    • Business Lead (this person should be well rounded in all areas of the business and can be a liaison for the Team)
    • Functional Area SMEs (depending upon the size of the organization, you’ll need at least one or more from every functional area impacted. These folks should be gurus. They should be able to understand the big picture in terms of how the organizations functional areas and processes relate to one another. They can listen and readily identify impacts and risks posed by another department’s actions. When these folks return to a senior manager with recommendations, the managers will undoubtedly listen as they are proven experts.)
    • Technical Lead (preferably someone very seasoned that understands systems and software. This person can also serve as a liaison to technical departments)
    • Business/Requirements Analyst Lead
    • Process Improvement Lead
    • Quality Assurance Lead

    Others may structure their teams differently, but this works for me. Realize that larger organizations may require a hierarchical structure within your team, such as 5 QA resources reporting directly the Lead for example.

    I hope this make sense! If anything is unclear or you’d like to discuss for any reason, please let me know.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.

Loading.. Please wait