Identify the next milestone/deliverable. Put this in front of the project team. It’s usually easier to work towards the next big thing, than the project as a whole. It can be a bit of an art to break up the project into milestones that aren’t too close or too far apart. Try to make milestones that are 2 to 5 weeks apart.
Update the project plan. Is it still realistic? Where might it go off target? Make the project plan week by week, and plan to demo something at the end of every week. Add in all the other events (vacations, holidays, team-wide events). A project plan is not a Gantt chart. Gantt charts communicate effectively, but are often a sign the underlying data is hard to change.
Update your project risks for sure, and probably the rest of your RAID document. For each risk, you should determine if you want to take any action to mitigate that risk. Next to your risk registry, list your plan next to each. Or write down, “accept risk”.
Do a project update. The clients need one and your team (or other internal stakeholders) need one too. A good update should focus on the needs of your reader, and give them just enough information that they can come to you if they need to, to have a longer conversation. One thing I’d like to emphasize is that you should come across as a neutral party: objective, upfront about risk, exposing things without bias. Your update should include a link to the source of the information: the project plan, risk registry, or a link to demo the current state of the project.
Update your technical documentation (or check that your team has). As you progress through the project, you should try to update the key documentation artifacts. Filling in the documentation at the end of a project is hard and often you forget key details. If you are updating as you go, your documentation should evolve with your project.