Thanks all for your input... unfortunately, I didn't build these tables.  They were built as data warehouse tables because they didn't want users writing SQL, so to make life easier, they made tables that had lots of columns so end users could basically select * from factTable where createDate >= dateadd(year,-2,getdate()).  To avoid having to do "joins" they ETL everything into single tables for users too.  So there is lots of repetition.  This table likely has 900 columns of which a bunch are duplicated in other tables... but because they say "joins are bad" they ETL everything into one giant flat table.  Sometimes it's values... sometimes it is just a flag 0 or 1.

My thought at doing this was to create a sister table with a 1:1 relationship with the original fact table so that I could offload the user assignment and date and time columns to a separate table, but that's still pushing 314 columns into a table.  My next thought was to pivot those columns and have a table dedicated to statuses.  So for every "thing" I would have a 1:many relationship.  Each "thing" could have multiple users assigned (bonus it would allow multiple people with the same role to be assigned to a thing which can't be done now -- if multiple people are assigned, to a thing, the most recent assignment overwrites the existing assignment).  As it stands, eventually all of those 34 user assignment columns will be populated and each of those 280 date and time columns will have values in them as well.

I was just trying to wrap my head around this because yes you can have 1000+ columns per table... but my brain says it's a bad idea because locking.  As the activity on the table grows, each update statement is going to lock the entire row.  If we are rapidly reassigning and tagging dates/times, that's going to be a problem with growth.  Going verticle would increase the number of rows, but would lessen the row locking as things are inserted/updated.

For explanation purposes ... a "thing" is assigned to a user.  A user can do many different steps which is why there are 34 user assignment columns and 240 date and time columns.  One user could do 10-12 steps to a particular "thing".