Project Management Central

Please login or join to subscribe to this thread SHARE Request to reuse this Topics: Information Technology, Organizational Project Management, Scheduling

Seeking Advice on Project Phasing and Execution Approach DANIEL FALCONER Senior IT Project Manager| Cognita London, United Kingdom Dear All, I am currently managing a long-term project aimed at delivering an optimized cloud platform for my organization, expected to span several years. At this stage, we have initiated the project and established a set of requirements, scope, and deliverables to manage the discovery and assessment phase, with the goal of ultimately delivering approved future state designs for implementation. I would like to understand how others might approach this in terms of phasing and execution. Given that I have completed the initiation and planning for the first phase, it doesn’t seem appropriate to move directly into execution. I anticipate that additional planning, scope refinement, and requirements analysis will be necessary based on the outcomes of the design documents. Would it be advisable to treat these as individual projects, or should I consider updating the business case and project plan, essentially revisiting the initiation and planning phases? Any advice on best practices for managing this type of scenario would be greatly appreciated. Thank you in advance for your insights. Saving Changes... Posted: Sep 27, 2024 5:23 AM

Sort By: Newest First Chronological Votes Sergio Luis Conte Helping to create solutions for everyone| Worldwide based Organizations Buenos Aires, Argentina What worked for me in this type of projects is working with an iterative-incremental life cycle, considering it a product. Becasue of that, I made a strategic roadmap stating product vision and direction over time (3 years or more, revised each 6-12 month), from that creating a product roadmap (1 year, revised quartely). To give you an example, in our initiative we have applications to be moved to cloud, all type of applications: legacy, from providers, etc etc that were in on-premisse servers and others, and so on. At the end, if you like to search from some today models like we followed you can take a look to SAFe model. Just to have a reference. I am not saying that my recommendation is following it. Saving Changes... Posted: Sep 27, 2024 6:45 AM (Updated by author: Sep 27, 2024 6:46 AM) Kiron Bondale Community Champion Retired | Mentor Welland, Ontario, Canada Daniel - I have seen it done both ways. In the case where the initial project yields an approach which can be delivered solely in house and there is no vendor/product selection, then I've seen that done as a multi-phase project with a commitment made (time/cost) on the first phase and then on subsequent phases. Where you might have one or more vendors engaged, then it might be cleaner to treat the first portion as a separate project whose deliverables would be a vendor recommendation, implementation approach and estimates, and the subsequent project would tackle the implementation itself. Kiron Saving Changes... Posted: Sep 27, 2024 7:10 AM Mike Frenette Community Champion Manager, IT PMO| Halifax Water Halifax, Nova Scotia, Canada I would conduct Inititating, Planning and Executing for what I know, as either the first phase of a project, or the first project in a program. An advantage of doing it as separate projects is you will be able to declare victory more frequently. If you do it as multiple phases in the same project, you may not be able to do that. In our organization, for example, we write closeout reports and concut adminstrative closure for projects, but not for project phases. Which way you do it will depend on details of the situation in which you are involved. If you know enough to plan and execute the first phase (or the first project), then do that. Often, though, in this circumstance, the first phase (or project) feeds the next phase (or project) which feeds the next... and so on. This may mean you can treat what you are doing as a program (a series of projects which must all be executed to achieve the desired business benefits), in which case it may make sense to dub them separate projects. "At this stage, we have initiated the project and established a set of requirements, scope, and deliverables to manage the discovery and assessment phase" could be a project with some concise deliverables called "Cloud Platform Requirements". "... with the goal of ultimately delivering approved future state designs for... " could be a project with some concise deliverables called "Cloud Platform Design". "...implementation." could be a project with called "Cloud Platform Implementation". Your organization may decide at the end of a project that you don't want to move forward due to reasons such as a lack of products to meet the requirements and no desire to build anything, or products that meet the requirements but are too expensive, or a change in priorities that can happen when the covers are pulled back and everyone realizes they just want to put it all on pause and spend the time and money on something else. I would advise against trying to lump it all into one big project, which could lead to planning what you don't know. That could land you in the situation jokingly described by one of the key note speakers at the LA Summit whose father supplied some PM jokes for us: "Make sure everyone knows the project budget is just a down payment.". ;) He also said "A no risk project is one that is finished." or something like that, but that is another story. Saving Changes... Posted: Sep 27, 2024 5:59 PM

Please login or join to reply