Steven ThiersCEO| ST ProjectsAntwerpen - Hoboken, Belgium
Hi All, My project is close to the cutover. A lot of teams of different applications are working together towards the cutover. Of course, the project has an overall cut overplan, but the teams also have their own cutover activities. However the detail of the cutover activities of the teams is far to detailed to be contained in the overall cutoverplan. In the overall cutoverplan we manage the handovers between the different teams. There 's where it becomes difficult. Some teams, mostly IT-infrastructure teams and database administrators have small tasks in the different cutoverplans of the different teams. If these tasks are kept in the detailed plans, then the central teams lack overview. If they're contained in the overallplan there will be very much/to much interaction between the general plan and the detail plans. Ideally all those plans should be integrated and teams should elaborate their part collaboratively, but the tooling we use, or the way we use it, (MSProject) does not support collaborative elaboration. Has anyone experience or tips how to collaboratively elaborate One plan? Saving Changes...
Sort By:
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
I work in the situation you described for each project/program I have to lead. MS Project can be used to support collaborative elaboration creating a "master" with subprojects into it. But it is a mess. And at the end, the key question is if that provides value. What we do is to keep tasks at summary tasks for monitoring and control and give each team the posibility to contribute to the summary task progress by updating the detailled tasks by themselves. So, as project/program manager, what we have on the radar is, at summary task, the reminder duration, the remainder work to do in the remainder duration, making a relation between both to detect if we have an issue. Additional to that, we keep the relation between summary tasks if needed. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Steven, agree with Sergio, do not try to put everything into one plan.
There are 2 aspects to manage: every team should have their plan and you must manage the interfaces among them. You named handovers and I would add key resources shared by several teams.
As a tool for coordinating 10 teams I have used a regular short standup meeting looking at a wall with all dependencies. In a cut over situation, you need to be flexible and adaptive to upcoming issues.
Upcoming and milestone handovers as well as identified issues are visualized on small cards and put on the wall before the meeting. Saving Changes...
I'd echo the feedback from my virtual colleagues that integrating the detailed schedules into a master schedule might be a bit messy.
However, one way to make this work is to add some high-level milestones at the very top of your overall cutover schedule which are linked to the detailed milestones from the individual child schedules.
That way, any time you open the master schedule and refresh it with the updated child schedules, the high-level milestones would also be shifted.
And, when you present the information to stakeholders, just use an outline level which hides the "gory" details. Saving Changes...
Milena IlievaProgram Manager Global accounts| VMWareVienna, Austria
I agree with all said earlier.
I was given a project 3 years ago to move a company's office from one city to another - the project was in a different country from where I was located.
The project was very complex, as in parallel to the office move, the whole team (from all departments, good it was not big office - around 40 people) opted to leave the company, as they did not want to move to the other city. To make things even more complicated, we had to implement a new ERP system (cut-over 1 month before office move), train the newly hired people.
I do not want to discuss why such decisions were made - it was very political project, and we were not fail, but I think that management team which decided and approved the project and the timeline, got their lessons learned later...
I am coming from IT, and to be honest I did not have much experience in similar projects. But there is always first time they say.
I did not have detailed project plan, nor I tried to define such. I defined high level project plan with milestones, together with the workstreams / sub-projects leaders and let them prepare detailed plans for their teams and work. I had a weekly status meetings with the teams' leaders to get the status, discussed the risks and to keep all informed on the work of other teams and any issues, or risks.
That was the best I could do from project management point of view, the project management maturity was at a different level in the different teams and I knew I could not ask, nor expect the same level documentation (plans and reports). I stayed at the level of coordination, dealing with escalations, when and if needed, and tried to keep focus and awareness on any issues and risks, as well as measures.
One can argue that it was a program, which I believe it was by its scope and definition, but this is not so important. Important was that we delivered as planned (we had 1 month delay, but it was included in the contingency, so still fit within the timeline). Saving Changes...
When I was running SAP implementations, I would use Excel for the cutover schedule - it was driven by more detailed plans that individual teams were responsible for. You need the detailed plans, but not everybody needs to read them (and most won't, even if they tell you they want them).
In the spreadsheet, each team had its own column, including timezone columns/conversions, as needed, for offices in EMEA and SEAPAC. I only got into detail on a specific team's activities when an activity was driving a decision or cross-functional dependency. I used lines for decision points, including go/no-go, and color coding to group people when a team needed further elaboration (the BASIS team drove a lot of cross-functional dependencies), Depending on the project, we would print it on either a plotter or several sheets of 11x17 paper, and then post it in our "war room" for go-live, giving everyone a visible schedule that could be marked up throughout the cutover event.
I chose Excel over MS Project because Excel allowed me to provide a linear view of each team's key activities in parallel with the other teams - no bar chart with extra lines, and multiple time zones in one view. It's probably also because I'm a little old school and don't like to use MS Project to track activities at that level of detail. For our CRM HANA migration/upgrade, we started Friday afternoon and finished Sunday morning, with multiple activities happening throughout the day, Saturday, and multiple groups testing and fixing bugs Saturday night. Excel provided a more user-friendly/readable format, and I worked in an environment where most people didn't have MS Project and were more familiar with Excel. Saving Changes...
Lonnie PacelliAuthor & President| ProjectManagementAdvisor.comBellevue, Wa, United States
Agree with Kiron. Define higher-level milestones in the master plan that align to individual team detailed plans, then manage to the milestones. Advise that be done through frequent real-time communication to ensure nothing is dropped or misunderstood. Also have a clear understanding of milestone dependencies, where if one milestone is missed the downstream impact to other milestones is understood. Saving Changes...
I check with the teams how they want to do it.
Usually in the master plan I only have one line "Cut Over Execution", and after all the task are included in a shareable document, that allow the team to check the different time zones (we usually work with CN, JP, EMEA, LATAM...) and the activities with their dependence. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
As a project manager, we always need to decide what should be on our radar. As was pointed out, the answer is anything and everything that would affect your project outcome. Anything else should be handled by other projects, initiatives or individuals.
The next question is what does your "radar" look like? Is it your project schedule, a subsidiary plan, meeting minutes or something else? You should decide based on the affected stakeholders Saving Changes...
Community Champion
