RE: Berst practices for creating a NS project with multiple clients?
Wanting to learn the different options for dealing with this scenario
Realistically, it really depends on your specific requirements, and especially with projects you’re going to have to play around and thoroughly test out your scenarios with how they function for your typical transactions. But at a high level:
- One project: If your billing scenario is wildly simplified and you don’t need to bill directly from NetSuite, you could just create one project with no customer/a dummy customer. This is most likely not the case, and has other gotchas, but throwing it out there, just in case.
- Create multiple projects:
- with the same task structure, and then roll them up with reporting. This actually works pretty well (I did it at another company) but you have to be really consistent about your task naming/structuring. A project template can help with this, but for more dynamic projects where your tasks/reporting breakdown is changing, this approach is going to rapidly become untenable. Also, for time entry, this can be a challenge of people knowing the correct project to hit, so you might think about building an auto-allocation to support this.
- using a custom field to link the projects together. This sounds like a really elegant solution, but ended up being pretty difficult back in the day. Might be more feasible now that you can do multiple joins with SuiteAnalytics Workbook
- A hybrid approach: Have one project just for tracking the overall project health and activities and then have some sort of allocation or semi-automated method of replicating that information in other projects for billing purposes. Main drawback here is the potential for a lot of work/data duplication, and you’ll constantly need to ensure that everything is tying out correctly yourself.
- Don’t use projects at all: I have often found that the more complex project applications can often be better handled by just creating something specifically for that use case rather than trying to force projects to do something it’s not really designed for. Of course if you’ve got enough things that are harder to do somewhere else like billing time, managing resources, rev rec, etc., you might be stuck with projects, but it’s definitely worth considering.