If this is a requirement of a project then the style, format and content of these reports should have been details in the project documentation already. If it isnt then go to all the potential recipients of the report and gather their requirements. They will have to use the data so it needs to work for them. Find out what they want to know, how often then need to know it(daily, weekly, monthly, on completion, etc) and how they want to be told(person to person in meeting, email, SSRS report, telephone call etc). Once you have that then you can start to design the reporting framework and get some updates out to the key project members
On any project, SQL Server, .NET, MQSeries integration project etc, I'm using a very simple method for day-to-day project progress followup: Excel. I create a Work Breakdown Structure in the beginning of the project, where I outline all the tasks, and set calendertime and responsible person to each task. A column in the chart represents a week and a row represents a task. A task can stretch over any number of cells. Each task can have any number of subtasks, and subtasks can have subtasks etc. I'm colouring in blue for planned tasks, green for tasks finished on time, pink for finished late and red for late and not finished. I know it sounds pretty stone-age, but it gives a nice overview and it's easy to work with. If you keep the WBS updated each week you always have an up-to-date report on the project progress, and you can spend time investigating/explaining only the tasks which are late/failed/changed etc. Management will never ask any questions about tasks which have finished on (reasonably) time or that are planned to finish on time.