午後２の問１を選択したのですが、
ステークホルダマネジメントにて「要件定義への参加を促す〜」的なことを書きました。
ステークホルダマネジメントになっていますかね。。。
皆さんはどのようなことを記載しましたか？

いま問題読み返したら、確かに「リスク、スコープ、ステークホルダ、プロジェクトチーム、コミュニケーション」がプロジェクトマネジメントの対象例になってますね。
相当焦っていたのか、この部分を思い切り読み飛ばして、「ユーザビリティ検討の成熟度」を対象にマネジメントしたと書いたけど、これ通るかな…

ステークホルダのユーザ部門で、要件定義が繁忙期に重なったが、参画率と要求仕様のあいまいさ起因の手戻りを減らすためにどう動くか？をベースに書いてました。

標を達成するための「ステークホルダエンゲージメント」についてフォーカスを当てずに書いたしまった気がします。。
ステークホルダが重要→要件定義に参加する施作を〜
これじゃ、落ちたかなぁ・・・

問１でプロジェクトチームのプロセスを題材にしました。
新人がいるから、通常週1回の進捗確認会をテーラリングして個別確認会をベテランと実施させつつ、進捗確認会でもその内容を簡単に報告してもらう、みたいな。モニタリングはTODOリストを共有フォルダに上げさせてチェック→遅れが発生したら声掛け、にしたけど、週次で報告もらってるから不要では？と、後で自分で思ってしまった。

問１を選択してチームマネジメントを題材にしました。問２の「目標未達成」は私の会社（ブラックに近いグレー）では許されないのでとても書けるテーマではなかったです。
 要件定義が難航したため、納期を守るべく開発工程は１つのチームによる逐次開発ではなく、チームを３つに分けての並行開発に切り替えた。並行開発は弊社では初となるため、チーム間のマネジメントを重要視した。施策としてチーム内の定例会だけでなく、チーム間の定例会を設けるようにした。PMとしてチーム間のトラブル仲裁に尽力したのと「自分のチームだけでなく、他のチームのことも考えて助け合いながらPJを進めていくこと」を繰り返し説くことで、プロジェクトが進むにつれてメンバーが一体となりチーム間のトラブルは減少した結果、納期を守ることができた。

改めて書き起こすと「修正の有効性」を「チーム間のトラブル件数」でモニタリングするのは無理がありますね。開発期間短縮のため「逐次開発→並行開発」に切り替えたのだから、有効性は生産効率でモニタリングするのが妥当だろうと今になって後悔。
来年リベンジします。