まずはじめに今回の法改正の対象となる業務の内容は「業務請負などの受託開発（フリーランスも含む）」です。

・販売目的のソフトウェア開発
・SaaSなどの自社でのサービス提供目的のソフトウェア開発
・IT系の人材派遣（労働をサービスとして提供）

などの業種は今回の対象に含まれません。
要は「●●を作ってくれたらいくら支払う」という形の取引が対象になるという感じです。
このあたりはシステム開発ならなんでもかんでも工事進行基準という風に勘違いしている人が多いので要注意です。

具体的には受託開発のどのような部分が問題になってくるかというと

・要件定義や開発や保守や運用などの工程を一括で契約を行う
・要件定義を行わずに開発を行う
・仕様変更を契約書の変更を行わずに行う

などの今まで受託開発の業界では慣習として普通に行われてきた「あいまい」な取引の部分です。
この部分に対し、工事進行基準会計が始まると具体的にやらないといけないことは

・作業前にきちんとした要件定義を行う
・作業ごとの正確な見積もりを行う
・仕様変更が行われた場合は新規案件として、作業を明確にしたうえで別途契約を結ぶ
・各工程を別契約で行う（要件定義、設計、開発など）
・決算をまたぐ場合は進捗の度合に合わせた売上計上を行う

などです。
要はきちんと「何をして、いくらもらって、いくらかかるのか」かをハッキリさせたうえで進捗に合わせて「どこまで完成したか」を売上・原価ともに正確に会計に反映することが求められるということです。
原価の計算を行う際には、用いる計算方法は「原価比例法」と「EVM」などがありますが、一般的には原価比例法が用いられることが多いです。

ただ注意点として受託開発であっても必ずしも工事進行基準に対応しないといけないわけではありません。
対応しなくてもよいとされる場合は

・工期が非常に短い
・見積もりが非常に難しい場合（新技術の利用や発注者からの要件があいまいな場合）

などでこの場合は工事進行基準の基本となる正確な見積もりができないため今まで通りの工事完成基準を使う形で問題ありません。

最後に工事進行基準のメリットデメリットをまとめると

（メリット）
・納品時でなく分割して売上が計上できるためPLがきれいになる。
・また、決算期をまたいで売上計上が全額翌期になるなどの問題を回避できる。
・正確な進捗管理ができる

（デメリット）
・進行状況の把握が面倒。
・完成していない段階で分割で計上されてしまうので決算を挟むと未回収の売上に対し税金が発生する可能性がある。
・大企業の下請けなどは原則義務付けられるので小さな企業では対応できない、もしくは大手企業が進捗把握のコストを嫌って下請けを利用しなくなることが予想される。
・対応できないと進捗管理が甘いとみなされる可能性

などがあげられます。
いままで適当な要件定義で開発を行っていることの多いIT業界からすると死活問題になりかねない改正なだけに、この業界の方はぜひある程度知っておいたほうがいいと思います。