What are the top project management methodologies?

If you were assigned the responsibility of managing an regional OS migration project (moving 30k+ users from Windows XP to Windows 7) within an enterprise environment - how would you go about tackling it?

• The approach to the manner in which large projects are managed varies from one organisation to another. I'm interested in learning about the project management methodologies involved when dealing with enterprise-wide migrations, particularly: - A top level overview of what is perceived best practice management methodologies, from the testing to deployment - Software that can be used to speed up the process (through either in-place upgrades or new builds) - Dealing with meeting weekly targets set by senior management (e.g. 400 devices have to be built weekly, how do you go about doing so) - Challenges that project managers can expect to encounter and how to circumvent them - Processes that could be automated  and how you would go about ensuring overall efficiency and accuracy (e.g. migrating user data and applications) - Dealing with users who appear to be resistant to change - Setting the foundations for the next big OS migration (Windows 9) This is for a university research project I'm carrying out on behalf of an organisation who has just completed their Windows 7 migration. I don't want to just document what I've observed within the organisation, but also capture a variety of opinions from users on here.

• Answer:

  My company is in the process of this exact same project.  Although I am not the PM I am responsible for monthly reporting- so I have been able to watch this from a distance.  I will say from the offset that managing a regional migration is going to be very different from managing a global migration (i.e. employment laws are different globally, there are time change issues, teams are more virtual, and licenses are different) .  I would almost go as far as to say that a global migration could be handled as a program rather than the project.  Phase 1: Initiation- For a regional migration I would first of all identify who all the stakeholders were across the company.  I would write up a charter with budget, scope and timeline estimates.  In the scope I would be sure to outline as many applications as possible that could be affected by the migration.  Obviously this will be different from company to company.  For us we have a lot of software packages that were either developed in house for XP/ old versions if IE or 3rd party programs that were heavily modified for our needs.  Migrating to windows 7 means updating or replacing all of these.  Once I have a charter agreed upon I would get Microsoft on the phone and ask what kind of support they offer.  I have no idea what options they have, but I imagine that if you are purchasing 30K windows 7 licenses- they are going to be able to offer some resources/support.  Phase 2: Planning- Next I would sit down with our IT services to get an exhaustive list of all the applications that will be affected by the windows 7 migration, and then take that list and find developers for each one of them.  I would ask them to provide cost/time estimates for what it would take to upgrade the program to run on windows 7/ newer browsers.  At the same time I would contact procurement and ask them to provide cost time estimates on replacing these programs.  I would then sit down with my stakeholders and we would make some upgrade/replace decisions.  Next I would make an inventory of all the hardware that would be affected by the migration and would follow a similar process.  Lastly I would sit down with our developers to discuss the risks created by having half the company on windows 7 and half on XP (which is inevitable as the migration won't happen over night...) Phase 3: Executing (Application Upgrade) Next I would begin upgrading the programs that needed to by upgraded.  I would duplicate the data we were currently using and test it on the newly upgraded programs- this part would be very agile.  I wouldn't continue with the migration until all programs were upgraded. (Essentially I would follow a standard PMI methodology except for the application development phase which would be more agile).  This is also where I would do most of my planning for the next migration (i.e. windows 8).  I would brainstorm/plan with developers how we could set up our programs to migrate easily to windows 8.  Phase 4: Executing (OS Migration) After that I would divide the company (personally) by departments.  I would choose departments rather than geographical areas because it seems that this would allow for as much continuity as possible during the change (i.e. each team has consistent OS's).  Obviously this would be different for each company.  If I had the resources I would like to assign a PM for each department or groups of departments. Within each department I would also take note of how many people worked virtually and how many travelled often.  I would start with those that traveled often and give them enough of a heads up to backup their hard drives etc.  I would then provide them with loaners in the mean time. For those that worked virtually ideally I would like to push the update to them form a central server- however that depends on whether the company has that kind of capacity.  regardless I would provide them with loaners as well (pushing the upgrade to them could take up to 2 days).  For those that worked in office, instead of providing loaners I would simply work with the team leader to schedule a morning where they could come in late and would send a technician to manage the upgrade. Phase 5: Control- Phase 5 would run in tandem with phases 3 and 4 (but phases 3 and 4 would definitely be sequential). I would ideally have a separate team that handles Quality Control.  They would follow up with each team to make sure that the transition is seamless. We would have weekly meetings to evaluate progress, costs, risks etc. and would submit change requests based on our findings. Practically speaking I would probably set up a sharepoint site that could act as a document repository.  I would use workflows to push change requests to relevant decision makers.  I would create a list that each of the PM's overseeing a department migration could access and update on a weekly basis. I would then link this list to an excel report that I provided to my stakeholders weekly.  I would also use MS project for the WBS/resource management.  Phase 6: Closure- Once the last machine has been upgraded I would finalize all the paperwork- and get my stakeholders to sign off on the completed project.  I would most definitely make a " lessons learned " to use for the next migration. As for challenges- I think the most obvious is resources.  The best way I know to circumvent them is to plan plan plan.  When a resource quits, or gets sick you need to know exactly what the scope of their work load is so that you can go to your stakeholders and say for example I need 1 FTE with skill sets A, B, and C, for X weeks in order to stay on target- they should cost $Y per week. Another will also be people's response to change.  My answer here is assuming an American/European context- you need to get senior level management to buy into the change (they probably already do since they are paying for it...), and be sure that excitement trickles down.  They need to be your biggest fan.  Team leaders need to buy into the change- if they don't its going to be an uphill battle.  Personally I have found the best way to "sell" change is to underline the cost of not changing (i.e. XP will no longer be serviced by Microsoft in 6 months, or all of our clients are using Chrome when they access this feature and it looks like total crap- it is the number 1 complaint our clients had during our last survey...) Voila, off the top of my head thats all I got.  Will update as I think of more.