A lot depends on the size of the organization number of Projects that need to be migrated, the number of Project Managers, Programs, Portfolios, and so on. While the schedule and timeline are critical for the Assignment or Change Management Project, the cost of migration is usually ignored citing reasons like internal resource deployment, Knowledge Management, Capability Building and Resource Enablement.
None of this, in my experience, fits the bill because the Project Managers are dedicated to Project delivery and the cost of distraction has to be accounted for separately either for the shared Managers sparing time for the PMO tool deployment or the dedicated Project Manager and their team working exclusively on the migration to the PMO tool.
Even with a dedicated team, based on the function and number of projects to be migrated the production teams sparing and sharing their productive time has to be assessed for a cost-benefit analysis.
In our case of migrating from a disconnected manual SPI and CPI reporting to a Project Management tool, at the organizational level of about 5 products, 25 projects and about 50 Project Managers (indicative numbers please, for contextual purposes) a timeline of over 12 months was not sufficient.
The learnings from our Migration Project can be categorised as follows:
Planning and Suitability Check
Keep the customisation requirements very low and restrict them to reports. If the product required additional features for a fitment, then either the product is not suitable for deployment for your organization or the organizational processes need restructuring before you go for the PMO tool deployment decision. The PMO has a critical job to support the organization with this as is the study or the readiness study for the organization. Strictly no customization of functionality or new features or modules should be approved, at any stage of the migration timeline. This should take about a month's time.
Process Mapping and modifications within the organization
A dedicated team of change management professionals shall be deployed for mapping the Project Management processes to the product features. The changes for switching to the PMO tool should be identified. Based on the size and complexity 1 -2 months is a good time for this exercise.
Pilot or Go live? Decision, Accommodating the exceptions
Being an internal project a pilot project would be ad-hoc and questioned for resources, time and effort. So the go-live date has to arrive at a consensus and the consensus could itself take a few week time. Consideration would be requested from project categories like, legacy projects (cannot migrate as the entire data is on a different server/tool, data cleansing needs to be done before migration, no approval for tampering with the legacy systems, etc), Hot pursuit / critical projects, ( we need more time, as we cannot spare resources right now for the next few months/ until this project/ phase is complete, etc.), Our Projects are on client-server and the tasks cannot be reported on this PMO tool/ client prefers manual reports/ Client approval is required/ Cannot ask for client approval/ need approval for client access to the PMO tool, etc. Subject to a fairly complex organization with all these exceptions, this could take about 2 months to pursue and get the buy-in for the much sought-after organizational change.
Rule setting, Skills Building and Training
The Project teams would go through a few meetings with the PMO deployment team to gain an understanding of the product, its mapping, and the procedure to access and start reporting tasks, requirements, CRs, Approvals, time and effort, backfills, absenteeism, dummies, exceptions, tasks, external consultants, internal consultants, client access and other criteria for deployment. This could take about 4-6 weeks time for a fairly complex organization with about 20 Project Managers/ representatives in the pursuit of their respective projects.
Time to Dance
Now the ground is ready and it's time for the first project to claim an award for the first task reported on the PMO tool. Under the pressure of production and CRs from the client assignment, a blended and balanced migration onto the PMO tool would be carried out by all projects. By the time the deployment team or Change Management team is ready with the migration project completion report it would be about 3 months time without causing any ripples in the production projects. We are again referring to the same "fairly complex" environment here.
The timeline for the End to End
As such it is fair to plan a 6-7 months journey for a decent migration onto a PMO tool. Even if the organization is small and can afford a faster deployment, blending with production activities and billable tasks take higher priority to focus on the migration tool.
Dos and Don'ts, Failure modes
1. The Project being a support activity, should be planned carefully to keep the PMO tool migration cost low.
2. Make changes to the organizational processes before the deployment.
3. Strictly no functional modifications in the tool to meet the organizational needs.
4. Estimate the cost for all the resources involved, from the client assignments PMO team and bench, into the PMO tool deployment assignment. Set a limit to the total project cost as a percentage of the product cost. Roll up to the organizational infrastructure cost.
5. If the resources assigned to this project are released within a month of the initiation for want of Production/billable requirement, then the project timeline gets extended accordingly. If the resource reallocation continues, the project timeline could go up to 2-3 times the estimate. Time to decide whether the organization may actually not be not ready for or not need the PMO tool.
@PraveenKambhampati, great post, thank u.
@Ben Arbeit Thanks Ben. Kind of you.