Expand my Community achievements bar.

Project Implementation Dates

Avatar

Level 4
All, I'm reaching out to ask about your business' established best practice for tracking and reporting on project implementation date(s). I'm on a Project Management team that handles primarily Waterfall projects with a few Agile projects sprinkled into the mix, so I would be interested to hearing your thoughts on either methodology. Our Current State We have two custom date fields on our general project form, Target Implementation and Actual Implementation . The PM is responsible for maintaining this "Target" date along with their normal update activities. The Actual Implementation date should only be entered in the week of implementation or once the date is no longer subject to change. An important note here, we have project monitoring and closeout tasks that continue after implementation, so we aren't able to use any of Workfront's native date fields. As an example, Target Implementation dates are socialized on a Quarterly Implementation Schedule we produce for the business and Projects with an upcoming or recent Target/Actual Implementation date are given a passing mention during a Weekly Performance Review with business unit owners. There are a handful of other situations and ways that these dates are socialized. Pain Points All PMs are not created equal and some can even be forgetful at times, neglecting to update their Implementation dates, creating a scramble to get all the projects to filter onto the appropriate reports before they are pulled up in a meeting with executive leadership. As we mature in our use of Workfront, we would like to have these dates to be calculated from the project schedule, i.e. the task list. I have experimented replacing the implementation dates with the planned/actual completion dates for a task aligned to our implementation milestone. As a concept this works great for waterfall, but becomes burdensome when considering agile projects and their multiple implementations. TL;DR . What does your organization do to track and report on implementation dates when they don't line up with a Project's Completion dates. I appreciate all of you that have taken the time to read my novel and even more so anyone who feels inclined to share their own business practices on the topic. Happy Trails. Erich Giltinan
Topics

Topics help categorize Community content and increase your ability to discover relevant content.

5 Replies

Avatar

Level 10
Hi Erich, We do exactly what you said, we use a milestone attached to Implementation Date. We call it Production Deployment (Final) . We also have Production Deployment 1, 2, 3, & 4 for those instances when the project may be Agile or it just has several deployments. But the Final one is the one we use to compare to the Target. We do a bunch of automation with the API as well, but I'll save that for another discussion. ��

Avatar

Community Advisor
Hi Erich, I invite you to read my "https://store.atappstore.com/handle-start-dates/" Get a Handle of Project Start Dates post, which describes a technique that you might find useful for visualizing an measuring these items. Our "https://store.atappstore.com/products/all/" Create Baselines and "https://store.atappstore.com/product/ubergantt/" UberGantt solutions might also be useful for capturing and visualizing slippages, too. Regards, Doug Doug Den Hoed - AtAppStore

Avatar

Level 4
Thank you both for your quick responses. Vic, The words 'automation' and 'API' always peak my interest. Although, I do agree, going into detail here seems out of scope for this thread. I hope it is okay if I send you a message to expand on that conversation. Anytime I can take the onus off my Project Owners through an automation is a big win over here. Doug, I can see how using a 'handle task' makes excellent sense for businesses that want to build their implementation schedule inside Workfront. I found this to be especially powerful when used in a Gantt calendar view. I explored this solution when we were implementing Workfront last year, unfortunately, it didn't meet our particular business needs. If anyone else has a different approach or strong opinions on this topic, please feel free to share. Erich Giltinan

Avatar

Level 10
As Vic mentioned, we use a custom field on a task where the PM marks that task as the BID (Big Important Date) and that is what we use for launch/release calendars, reporting, etc. That way, that date automatically updates with the project schedule as it gets updated. We also have it setup that a baseline is automatically saved the first time you go from Planning to Current so we can compare the date after the project to see how much slippage we had from the original agreed upon that. Anthony Imgrund FCB

Avatar

Level 10
Ha ha – I love the Big Important Date term. Yeah Erich hit me up anytime. In fact [insert shameless plug �� ] we are presenting at Leap this year on how we use the API on Projects. It's a Technical session called - Using the API for Project Hygiene and it's on Monday 4/27 at 1pm local time. I'm sure it's completely sold out so you might have to try Stubhub or find a scalper at the conference �� . JK I'm sure there are spots. I might add - Big Bad Diggity Dang Immovable Date to my slides (I'll have to footnote Anthony for the inspiration) . But yeah give me a shout if you want to talk more details on how we use the API (we do a lot with that thang – love it).