Recommendations for structuring customer projects post-implementation

[ScottCe]

David from MaritzCX is interested in feedback from Workfront Community and any recommendations for the following: Once MaritzCX completes a customer's implementation project, their CSM team takes over maintenance tasks for the life of the partnership and currently creates an "Ongoing Project" to track these tasks. They are interested to know how other Workfront customers approach this type of ongoing maintenance situation. Scott Ceraso Workfront David Clayton MaritzCX

[VicAl]

We do the same (kinda). Each of our Scrum Teams has their own "Team Project" that serves as a bucket to hold any ongoing, ad hoc, feature requests, issues, etc. I use the naming standard of [team name] Team Project so that I know these are "bucket" type projects and not a standard typical project. For example my team is Workfront/PMO Team Project. I never actually view it in the Project view. I just look at my Team View (Backlog, Iterations, Issues tab, etc.). Vic Alejandro, PMP, CSM | IT Program Manager Denver Water | t: (303-628-7262) | c: (303-319-6473) "http://www.denverwater.org/"> http://www.denverwater.org INTEGRITY | VISION | PASSION | EXCELLENCE | RESPECT

[JaclynRe]

The department I serve at Equifax is responsible for implementing products/services for our customers. When a service "goes live", and the implementation is complete, then it gets transitioned to support and the implementation project is closed. In our world, support does not use Workfront. However, there are implementation teams that act as a 2nd level support for the service they implement. This is how we manage support/maintenance of customers who have completed implementation. We have a Project that we created and established a queue with routing rules. Basically, we set up a support queue. The overall project is "[Service Name] - Support" and the individual "issues" or "requests" that come in function similar to a support queue. Each post-implementation request/issue is tracked in the Issues tab, time logged and we have some custom fields we set up so we can pull client IDs against the post-implementation issue/request. On a side note, this is also how Workfront Support Requests are submitted and managed. Request Queues are very beneficial for us, and it really promotes collaboration and encourages our workers to streamline updates, communication and anything else directly through Workfront. View this on Workfront > Jaclyn Reiter, PMP, SA Equifax, Inc.

[DavidCl1]

Thanks for your responses. It sounds like I am on the right track. MaritzCX has a customer number that is associated with all hours billed toward that customer. I create an "Ongoing" project (like the "Bucket" project) for each customer and add the customer number to a custom field. I also have set up request queues which will feed a triage team, which will then assign the tasks to the appropriate Ongoing Project so that the hours may be billed to the correct number. One drawback we have seen using this approach is that new tasks created in the project will have a start date that matches the start date of the project, which in most cases was months ago. It was a bit of a pain to have to manually set the start date of each new task, but this is less of an issue now because the teams are shifting to using the Kanban view. David Clayton MaritzCX

[VicAl]

Yeah that's a bug that Workfront won't admit to. It drives me crazy. It's never any use to anyone to create a new task with a start date in the past. Which after Day 1 that project Start Date is in the past. Does anyone know of a Feature Request out there? Vic Alejandro, PMP, CSM | Senior IT Project Manager Denver Water | t: 303-628-7262 | c: 303-319-6473 Http://www.denverwater.org Sent via mobile phone