As a system admin, I have been receiving queries from project managers regarding projects that have multiple Go Live milestone dates. For instance, in an integration deployment project, there may be different Go Live dates based on the region. For example: Go Live in UK in Jan, Go Live in US in Feb, Go Live in JPN in Mar etc.
However, a project milestone path typically has only one milestone (example only 1 Go Live), which is confusing when PMs want to mark multiple Go Lives.
I am curious to know how you handle such situations in your organization. Do you create additional milestones (example: Go Live 1, Go Live 2 etc), or do you have a workaround? Because the number is not fixed, it's really hard to say. Any insights or best practices that you have implemented would be greatly appreciated.
Milestones in our instance:
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Hello -
We have a similar need because our projects can have multiple phases. Generally, our goal has been to have a single project represent a set of work sold - meaning we could have multiple deliveries/go-lives as part of that.
I've been hesitant to trust a field that a user could edit and mistype a key word. Therefore, we have a custom field called "task - event" that we use to tag key tasks as an attribute. The list includes items such as: approval, start of build, and go-live.
We're then able to use this attribute to find the tasks for reports, automations, and integrations with other systems. We also use this as a tag for Fusion to identify project level attributes like:
One of our milestone paths is for major programs, which can involve multiple product release formats (e.g., self-study online; live; both). We use separate milestones to track these go live dates ('06--SSO Course Delivery' and '07--Live Material Delivery'). Having the separate milestones also allows us to track these releases against target dates we've entered into a custom form for these projects.
Hi there, I was at an org where we have multiple tasks in a project that could symbolize something going 'live', like you're saying. What worked well for us is using task name conventions. We had keywords like publish/live/deploy depending on the project type and those words were always in those kinds of tasks. All templates had the correct naming so we weren't relying on people having to remember, and all 'milestone' reports pulled tasks containing those keywords. This worked very well for us instead of using WF's actual milestone functionality. It was also used in our editorial calendar in WF to pull tasks w/ those keywords to show our 'live' tasks in all projects, colored/grouped by portfolio on the calendar.
@KristenS_WF and @Madalyn_Destafney - I appreciate your input on the task naming convention. I will bring up your ideas with our PMOs for further discussion. Thank you both for your valuable input.
We are using a standardized naming convention that is specific to Global, which applies across different project categories or groups. Milestone tasks are given names that are similar to a specific keyword, along with a numerical value that increases incrementally. This system makes it easy for project managers to recall the name of each milestone task, even if they don't remember the specific keyword. Furthermore, the combination of numbers and keywords can be easily identified with different colors in a Gantt chart, making it suitable for both short-term and long-term projects.
Views
Replies
Total Likes
@Kundanism - Can you give me an example please. Is it similar to what Kristen has mentioned above? 06--Task1, 07--Task2, etc?
Views
Replies
Total Likes
Hello -
We have a similar need because our projects can have multiple phases. Generally, our goal has been to have a single project represent a set of work sold - meaning we could have multiple deliveries/go-lives as part of that.
I've been hesitant to trust a field that a user could edit and mistype a key word. Therefore, we have a custom field called "task - event" that we use to tag key tasks as an attribute. The list includes items such as: approval, start of build, and go-live.
We're then able to use this attribute to find the tasks for reports, automations, and integrations with other systems. We also use this as a tag for Fusion to identify project level attributes like: