I am trying to move toward a "passive update" approach for my small web development firm. I have created a Status Report template that I plan on having my team submit weekly for all open projects.

You can se an example of my proposed status report [url=]here.[/url]

I would appreciate any feedback on what I've created.

I'm hoping that by requiring such a report on a weekly basis, my team will start to take ownership of their deadlines and will free me from having to constantly track down the status of things.

Am I asking for too much here? Am I missing anything?

Thanks much for any feedback!


sholden's picture

One of the approaches discussed at the recent Manager Tools conference was to have weekly reporting done via 1on1s, and having team members provide monthly written reports.

Another suggestion from the conference was to not dictate a report format and wait and see what others consider are effective ways of reporting their own personal status.

I have just started to do this but I haven't had my first monthly reports due yet, so I can't say much about the format I'm seeing.

- Steve

mikehansen's picture


Here are some thoughts.

First off, let me challenge your whole approach. I think you should entertain setting up weekly meetings with the project team (one for each active project) to go over key topics, including status. This way you can help guide the projects while providing a consistent forum for the team to raise concerns and communicate with each other. This helps the peer-pressure aspect of the team dynamic, which should help your project stay focused.

The podcasts on running meetings rock, so I would suggest an agenda like this (hard to format this, it should be in a table format):


Client Communications

Urgent Issue - eMail Functionality

Last Week’s Progress

Goals for this week

Change Order – Boolean Search

Open Issues from the floor

Meeting End

The Client Communications would include previous touch points and planned communications for the next week. The Progress and Goals would include milestones hit, missed, and plans for the next week. Open issues is the place where new stuff can be discussed, plus it provides a buffer incase something runs late. One of the goals each week should include identifying the person to draft the next agenda for the next status meeting.

However, if you are not looking to be that directly involved with your projects, you could still have the team meet once a week and record the minutes of the meeting in a simple word doc, which would give you what you want.

My gut says that you will want more perspective on the progress of your client communications and project milestones than you will get from the document you created.

If you stick with the document approach, move the last page to the top (client communications, important topics) and simplify the milestone reporting to be 1) what they did, 2) what they missed, 3) what is the focus for this week. The check boxes, and overall title, owner, date structure strikes me as way too bulky for you to weed through to get the simple story.

My .02


DWElwell's picture

I tend to be something of a minimalist when it comes to status reports. I view them as a communication tool and not an accountability tool. Hence, I am not particularly interested in a long list of activities my directs were involved in.

In general I follow the format

I. Accomplishments
{Insert bullets that discuss items that were completed or had major milestones in the past week. Each item should reference the relevent work breakdown structure item number, or if not on the WBS, detail who made the tasking.}

II. Planned Activities
{Insert bullets that discuss what WBS items or other tasking will be worked in the coming week}

III. Risks/Issues
{Insert bullets that identify any new or changed risks or issues, including an assessment of liklihood and impact, along with response strategies being considered}

IV. Items for managment attention
{Insert any items that require management action or decision, if any}

V. Planned Time Off
{Summarize any planned absences for the next week, and who is covering, if any are so identified}

And that is pretty much it. This is an email, not an attachment. Not that in general, all of these items are discussed in the O3 or the weekly staff meeting, as appropriate

Nik's picture

I'm a huge fan of the shared to-do list approach. (Tech options include BaseCamp, pmWiki, dotProject, MS Team Server, etc.) Then when specific tasks/milestones are completed, they get checked off, and you can see it. Not only is it a passive update, but it's very nearly passive for the task-doers.

O3s or formal periodic reports can serve as a more formal record of what's happened, if that's necessary.

jhack's picture

I like DWEIwell's format. Consider two changes: focus on deliverables rather than activities. Accomplishments are completed deliverables.

Deliverables are measurable. They can be seen, and their quality assessed. Reports, prototypes, specifications, brochures, nailing down a meeting with a prospect, etc, are all deliverable and measurable.

Two additional thoughts on deliverables: I'm a big fan of "it's either done or it's not done - there is no such thing as 80% done." If no deliverable is scheduled to take more than a week (you can have interim deliverables like drafts, components, etc) then you have an easy status report from your directs: These are your deliverables, with due dates: are they done or not done? It also provides a specific context/impact for the risks, issues, and items requiring attention.

tvalleav10's picture

All great ideas folks. Thank you very much!!!


DWElwell's picture

Jhack -

I do like the focus on deliverables. The only difference might be terminology. In most of my projects, Deliverables are mandated by contract I.e. System Requirement Document, a System Design Document, a completed System. There's a typically significant amout of time between them with lots of intermediate activities (I work on large government programs)

I as a project manager, I wanto to know that the intermediate activities are going according to plan (or not), as well as know about major deliverables. Of course, in well formed Work Breakdown Structure, it will be clear what intermediate activities a deliverable is dependent on....

I disagree (slightly) about your "do/not-done' point. If you have well formed metrics associated with your work, it is very helpful in judging whether you are on track. I.e. I you are building a brick house for me, knowing that you have laid one storey of brick when your schedule indicated you should have laid two is very helpful. Waiting until you have blown the schedule (or budget) is often too late.


Mark's picture

I'm not sure I'm on point here, but Dan's post makes me want to add something.

I've noticed the migration, from the IT service delivery and contracts world, to the rest of the business world, of the use of "deliverables". Deliverables USED to be contractually dictated physical property - media on which contracted for software was stored, or hard drives, or monitors, or physical media with updates, etc. The word was used in order to make clear the performance of the contract - that is, the thing being paid for had to be physically deliverable. Software is not, in and of itself, deliverable in a physical way, and early contractors for services recognized this. I hesitate to say it was a lawyer who created the term/use, but one can't discount that.

Nevertheless, it gradually then morphed into representing soft stuff like updates without physicality or even features on a a website, and physical delivery was not actually intended (though if it was in a contract, you can bet physicality (burned CDs are in vaults everywhere, folks) was required. But the word was being used differently.

And now, it has become somewhat synonymous with accountabilities, or responsibilities, or tasks.

I think that SOMETIMES I hear IT folks using it with more formality than the business person they are speaking with expects or understands.

Probably TMI, but thought I'd share, as someone who pays attention to language and its evolution.


jhack's picture

Dan, you're right. There are certainly tasks (like laying pipeline) that are amenable to a "60%" done status. The key is that the progress is actually measurable. I work in the software industry, where estimates of completeness are not easily verified by straightforward measurements.

Mark, I should have used the term "artifact" which includes both deliverables and internal work products. These internal work products (like a draft design suitable for review) can then highlight progress. In both cases, though, this is something that is real: it can burned on a CD, etc. And it can have a status (done, not started, etc).

DWElwell's picture

Probably a issue of semantics more than anything else. I like the word "artifacts" as a generic term.

In any case - it's good to make sure activities are aligned to them...

smholland10's picture

My very first mentor passed me this SECRET of Project Managment: "The key to a successful project is to know what will be left behind for customers to use when the project is closed"

Status reports are an upwards communication tool. Depending on the size of the team, and corporate reporting requirements, your directs should be send you a short report that articulates:

ID - from Plan (a Word document not something from MS Project)
Status - Blue (Complete) Green (On Target) Amber (Corrective Actions agreed) RED (Off target - I need help)
Name - from Plan
Owner - Who wrote the update
Short Description - from Plan
Key Roadblocks:
Key Issues:
Upcoming Activities:
Next Report Cycle -
Subsequent Key Activities-

Your report to your masters should be similarly structured summarising the information from your team.

Ideally you should recieve the information no later than lunchtime the day before you meet with your team so that you can prepare for the team meeting and focus on:
Red - What needs to be done to correct performance
Amber - How is performance tracking to Corrective Action Plans
Greens - Congrats and support.

Team success is not about blame. Encourage your directs to make a task/project/Program Red without fear - Bad news does not get better with age, the sooner you can get corrective action plans in place the higher the likelihood for success



jaxnd's picture

I deal with 6 advertising agencies on a daily basis. Each Wednesday is set aside with a pre determined time for an agency call. The calls are to last 30 minutes but I usually block an hour.
Each agency uses a similar excel spreadsheet format that is updated each week.
I have been using this system for more than two years and it works pretty well.
Columns include job# date job opened, title, status, next step, by whom and when. Completed jobs are moved to a new worksheet so we can keep track of when something was done. It is also fun to show the boss at the end of the year pages of completed jobs.
Hope this helps

thaGUma's picture

I woud seek update on five heads:
1. Cost: will or have changed? If so why and how much. Can/how do we recover it.
2. Programme: Ditto
3. Specification/Deliverables: Ditto
4. Hold over issues: update summary and as affects above.
5. Next stage: anticipated risks and evaluation.

Our goal is to deliver projects in accordance with the board approvals. Continual update against this is the key to control of issues. Ensuring transparency (i.e reporting issues immediately) generates more risk but gives more credibility.

stephenbooth_uk's picture

[quote="tvalleav10"]I am trying to move toward a "passive update" approach for my small web development firm. I have created a Status Report template that I plan on having my team submit weekly for all open projects.[/quote]

Have you had a look at existing 'Best Practice' methodologies like PRINCE2 or PMI?

PRINCE2 defines a number of products (in PRINCE2 everything is a product whether it's the thing the project is to build or a report generated for the management of the project), the one that's closest to what you seem to be describing is a Checkpoint Report. These are produced by the manager of the team doing the work and defined as being composed of:
[list]Date of the Checkpoint
Period covered by the report (PRINCE2 doesn't define how often the reports are generated, just that they should be regular)
Report on any followups from previous reports
Products completed during this the period (unless a team are working on something that cannot be split into smaller units this is usually better than trying to estimate what percentage complete you are, in software development it might be functions/modules written whilst in construction it might be courses of bricks layed)
Quality work carried out during this period (Quality work basically means any checking done to ensure that the products fit to the specification)
Products completed during next period (what we're planning to do next)
Risk Assessment (known risks hit in this period (and what was done), new risks identified (and how the risk is being contained), risks we might hit next period)
Other actual or potential problems or deviations from the plan.[/list:u]

Most organisations I've seen use it add a summary at the top which usually just consists of a reference to the task in the project plan, planned start date, actual start date, planned finish date, expected finish date and an assessment (usually colour coded) of how the task is going. Typical colour coding would be something like:
[list]Green - Everything OK
Yellow - Problems but still within contingency and steps have been taken to get back on track, not going to impact on project deadlines or outcomes
Orange - Problems and outside contingency (or likely to breach ciontingency in next period) but steps are being taken to get back on track, not going to impact project deadlines/outcomes or changes to deadlines/outcomes have been agreed with the project board
Red - Problems, outside contingency (or likely to breach contingency in next period), likely to impact project deadlines or outcomes, project board have not yet agreed a change to deadlines or outcomes.[/list:u]

If you want to find out more about PRINCE2 then I can reccommend "PRINCE2 a practical handbook" by Colin Bentley.


smholland10's picture

As a Member of the Project Management Institute (PMI) I can assure everyone that PMI is not a methodology it is an organisation.

Many folks often refer to the Project Management Body of Knowledge (PMBOK) as a methodology [i](Methodology - a system of methods used in a particular area of study or activity)[/i]. PMBOK is the knowledge that a Project Manager could reasonably be expected to know in order to be Certified as a Project Management Professional (PMP).

There are many methodologies that provide a framework for Organisations to manage projects. Some of the following are well known methodologies are 1) Method One used by Anderson's (Accenture), 2) Catalyst from CSC, 3) WSSDM from IBM. All of which will deliver supporting Artefacts for the project management process.

Where people come unstuck is mixing project engineering activities with Project Management activities. These comments may be a little philosophical but for PM professionals they are important.

The requirements of good Project Management do not change whether you are managing a Construction project or a Business Transformation project.

AT the end of the day you need to use what works for you and your organisation.

Duardo's picture

[quote="tvalleav10"]I am trying to move toward a "passive update" approach for my small web development firm. I have created a Status Report template that I plan on having my team submit weekly for all open projects.

You can se an example of my proposed status report [url=]here.[/url]

I would appreciate any feedback on what I've created.[/quote]

Stephen is on the money about the Checkpoint report in PRINCE2. The templates are freely available. I only have one suggestion tho regarding the PRINCE2 checkpoint report template...i prefer to put the impact on tolerances first as this is high priority info... you can download the template [url]

I hope that helps...

anis260472's picture


I m working also in a web dev company, and I found your status report missiong a general project status and to much focused in Milestones

If you are interrested I ll send you the status reports that we ve implemented in our company

[email protected]

jblack's picture

You can find a few good articles on status reports as well as a few status report templates here: