Is this bad practice?
This is set up exactly how I would do it. Looks like basic relational database design at work...
You are not "boned" here. Just keep in mind that when you work with relationships in FileMaker you are not limited to the table occurences that are directly connected to the current layout's table occurrence.
You appear to have this structure to your relationships:
From Org, you can place a portal to Project and you will see a combined list of projects for that Org record. In FileMaker 11, you can set a filter expression on this portal to only list Projects for a specified year. (The specified year can be a value in a field where you select the year.). This can also be accomplished in older versions, but the relationships needed are more complex. A Summary field in Project that computes total values can be placed in such a filtered portal and will will report the total of those records listed in the portal. Likewise, a Sum or other aggregate function defined in Org can compute aggregate values for all project records linked via records in client to a given Org record.
For data entry operations, this shouldn't be a major problem. When you assign a new client to an Org, their projects will automatically be included in that Org record's portal.
The nice part about your setup here is that there are a lot of options for summary reports that will work very smoothly for you here. You'd base such reports on the Project table, but can include all related data as needed from the other three tables, using sub summary and other layout parts as needed. Such reports can be limited to just the projects for a specified Client, Org or Umbrella if you perform a find that limits the Project records to that specification.