What makes a SOW for project management or software development different from SOWs in other industries?
My experience suggests the scope of the work is often not entirely known in many software projects. Not understanding the entire scope makes documenting the statement of work difficult. Software is perceived to be a quick fix or adjustment allowing for feature additions or changes on the fly, and to some degree this may be true. However, the archetecture of the software must be able to accommodate the growth of the feature content, and sometimes this is not accounted for in the SOW. We learn as we do the work, and that learning may alter the SOW in some way but those documents may not get updated with this learning.

What challenges might someone in these industries face during the writing process, and how can they overcome them?

If you expect the final product to be able to be predicted in its entirety in the SOW, then you are going to have some difficulty. The better solution is to do what you know, learn from that doing and alter things as you learn. This will require a good measure of control over the requirements and updating the SOW with what is learned as you learn it. This updating must be controlled and left to ad hoc approaches.

Deliver the product in iterations, steadily increasing the total capabilities defined and test each instantiation of the software. Update the requirements and SOW as you go through these iterations. This update is fodder for the next iteration of the software.