Hey all. We are leveraging Fusion to manage work across our various lines of business using Fusion to create Parent/Child relationships. This allows us to share the necessary data from upstream teams, give visibility to the Project Owner on status of Child Tasks, etc. We have a new user who is coming from another company where they did not use Fusion and is recommending that we build "mega" projects that include all of the teams that do work at some point on the project She recommends creating one giant intake form that would incorporate the information needed throughout the entire project. This just doesn't really make sense to me. Looking to this community to provide some feedback on how you are managing projects across disparate teams. Thanks!
my personal opinion is that mega projects aren't scaleable.
I've seen these in use at inception (seems to be a popular option to start with) but then as folks start becoming more evolved and want to make changes, it has run a risk of quickly getting out of hand and being very high maintenance.
As a quick example/s, if you have a mega form and one of the workflows within it gets retired, what do you do with all those custom form fields? We have this as separate forms, so we just deactivate the form and it never gets used again -- it's just on the objects that have that form already attached. How easy is it to edit a mega form (system admin backend experience vs user front end experience)? What if different teams using the form want to use the same field in their "section"? And what if they all have different answers to that field?
Another quick example on the project side: the more complex a team's work, the more they tend to want their own project. Users get really unhappy when they have to wade around in a larger project full of other team members. Occasionally there is also some amount of fighting over who really should be owning a project, and what does "complete" mean. Reporting metrics can also be more complicated in this kind of situation.
Views
Replies
Total Likes
I think there is pros and cons to both approaches. From a Management perspective everything is in one place and easy to find. If the users are working on reports than the one mega project is never an issue. It is only an issue for the PM who might want to see everything in one place. Cross Project Predecessors in my experience have been issues and not easy for a PM to navigate. Having to move from project to project. However with all of that said I would love to hear how you are leveraging Fusion to create these child projects for you. Our Mega Projects have become to Mega and we are actively looking for away to slim them down that makes sense.
Views
Replies
Total Likes
Thank you both so much for the responses! We are using Parent/Child tasks to share out the tasks specific for the downstream teams (e.g., creative development, reviews and approvals, etc.). This allows the Project Owner to see the status of the child tasks while giving ownership of them to the downstream team. The child tasks are created as issues and the downstream team converts them into a project to complete the work they own. Updates occur automatically back to the Parent project. Allows everyone to manage cycle time reporting, etc.
Views
Replies
Total Likes
Interesting thread @djmitchell; following.
For those who do venture into the sub-projects / cross project predecessor arena, I invite you to consider our Timeline and/or Roadmap solutions:
The latter is among our top R&D priorities, and we have set our next major release's sights on rivaling some of Microsoft's Timelines...but directly from within Workfront, in real time (as always). Happy to chat further via doug.denhoed@atappstore.com.
Regards,
Doug
Views
Replies
Total Likes
Views
Likes
Replies