1. On Friday morning do your build
   - version your weekly build
   - send an internal 'Test Please'
   - enter your timesheets (at the end of the day)
2. On Tuesday's daily scrum meeting (normally in the morning) send the email
   - use a subject "XXX Release XX - Weekly Project Update"
   eg. Northwind Release 09 - Weekly Project Update

This 'Weekly Project Update' email will contain the answers for the following questions:

• The path of the new package you built last Friday
• The % of the tasks done? (Find this from your current interation)
• The % of the budget spent? (Find from your Billing System. See example of a Billing Report - Project Progress Report)
• Expected finish date

PS: Why Tuesday? You want this $$ data to be right. So wait until invoices are sent on the Monday.

Hi Mr Northwind

Here is an update:

• currently working on Northwind Release_10_Jobs
• I did a build on Friday see http://ant:8000/Northwind/
  • Status: Internal Test Failed
• % of Tasks Done:  62% complete
  • http://tfs.northwind.com/XXX 
• Budget used:          60% used 
  • Authorized:  $75,000
  • Spent:          $39,715
• I expect to finish on Fri 30/05/2008

Regards Eric

Figure: The above is a sample of the 'Weekly Project Update' email

• To make sure that you did not get the message wrong
• To keep an audit trail of agreed decisions
• To keep people who were not a party to the conversation, informed about the progress

Use this approach internally and with clients. As a result, expect to see "as per our conversation" emails that:

• Require a task to be completed
• Explain the logic of the decision
• Include URLs that were referred to 
• Can be referred back to in the future

• (For websites) - Link to mockup, test and live environments
• (For windows apps) - Link to the last build's setup file (which should be every Friday)
• Contact details of the developers and project managers
• Contact details of the company champion
• Every release of the project 

An example from Metal Corp

Note: If you use TFS2010 you can use the built in SharePoint dashboard for this. All you need to do is create a new Team Project using the Agile Template

In fact, for every 1 hour of 'application building' coding tasks there is between 1 and 4 hours of other work which SSW will charge for. This other work includes administration, testing and bug fixing.

Here is a list of the items which SSW considers when estimating a release.

• Project Progress Report: This report helps clients to review the current project progress, check the status of the project and whether they are over or under estimates.

• Project Update from eXtreme Emails helps client to understand what's involved in the project.
  Using eXtreme Emails! to Manage Projects - Send a Status Update every 2 weeks Figure: Generate Project Update Report

1. Additional items - where additional work is required
   • Any triaged additional items not specified in the original release plan (be they features, modifications, bugs)
   • Investigation time for scoping out additional items
   • Adding additional resources onto a project
   • Performing unscheduled tasks such as an additional architecture review or UI audit

   It is easy to fall into the trap of "do-and-charge" without seeking further approval for additional tasks. This is often very easy but becomes a problem as soon as someone (typically a new manager) asks "why is this release costing $45,000 when the original estimate was $30,000?" Oops!

2. Exceeded estimates - where work takes longer than expected
   • When it is known that costs will be 15% greater than the original estimate additional approval is required
   • E.g. If the estimate is $9000 SSW will spend up to $10,350 without further approval
   • Note: this is assessed on a release by release basis - you can't try and "make up" in the next release

Approval can be given in writing or verbally, confirmed in an "as per our conversation" email, and then an updated Release Plan is sent.

Figure: Get work approved and spend less time putting out fires

The solution is to get permission for the work you do before you do it. Get permission verbally, confirmed in writing by email or with a signature (although that's sometimes a whole lot harder).

Always get permission for:

• Additional Items
• Exceed estimates
• Data migration procedures

Having said that you need to manage two potential probems with seeking permission on work before acting:

• Increased dead time while waiting for approval
• Discouraging initiative to fix problems fast

These problems are naturally solved through the continual refinement of what can and can't be done without approval. Different clients will have different standards depending on the type of project. From a time perspective the rule of thumb is never spend more than one hour without approval.

This rule is not generally applicable if you are working on an ad hoc basis on a client managed project OR if the task is an obvious task which you would reasonably assume the client would approve and is not likely to take more than half an hour.