Rules to Happy Clients

1. Do you correctly triage additional item requests?

   

   Figure: Only if it's life and death does it get added "in this release"

   "Triage" is a term originally used to describe the assessment of injured persons into a priority order based on the severity and urgency of their injuries.

   While developers don't often deal with real life and death situations very often, the ability to prioritise and action issues that arise can keep the heartbeat of a project steady and strong. Failure to manage additional work requests will have an adverse affect on estimates and deadlines. Additional item requests can consist of of new feature request, bug fixes, modifications, and undiscovered work (i.e. work you didn't initially anticipate). You can manage additional item requests with eXtreme Emails.

   "In this release" OR "in a later release" (or a "changes" release)

   The first step is to analyze the priority of the additional item. Priority is dependant upon the severity of the request. The priority will determine whether the request is done "in this release" or "in a later release".

   For example, a crash-to-code bug that prevents one or more users accessing the system is high-priority and will be fixed "in this release". A request for a new screen with a new look-up table that doesn't prevent users from operating the system and will be allocated by the project manager to "a later release".

   A client may specify "must be in this release" on an additional item request. This will generally be done as requested unless the request will have a material impact on inflexible time and budget restraints. For example if the work will take 2 extra days which means a critical deadline will be missed, the work will be delayed. Otherwise it can probably go ahead.

   A client may request a small feature (e.g. changing the sort order of a combo-box). This work can go in this release so long as such requests are kept to a minimum - less than 1/2 hour.

   Approval by project manager and client

   The second step is to obtain approval for any additional item request from both the project manager and the client, and then add the request into the Release Plan marked as an additional item. The work will not proceed without written approval from the client. See more about how to Obtain Approval Additional Items Exceed Estimates.

   To: Evan Lin - SSW
   From: Alan Ha - FinaMetrica
   Subject: Client List for Administrators
   
   Hi Evan,
   
   Can you plese add sort function (like the one in office 2007 - see below) next to the fields: Last Name, First Name, Advisers and Organization. This will be applied to all the relevant pages which have these fields in the list i.e. adviser list for administrators, client list for advisers, etc. Please use the text Ascending instead of "smallest to Largest" and Descending for "Largest to Smallest".
   
   Thanks,
   Alan
   
   

   Figure: The above is a sample of the customer's request, and will go into a later (or changes) release, not the current release

2. Do you send a weekly project update each Monday?

   A simple weekly project update report will be sent to Adam and your Project Manager every week. To do this there are 2 simple steps:

   • On Friday Morning do a Weekly Build
   • On Monday morning send your "XXX Release XX - Weekly Project Update"

   The Weekly Project Update report will contain the answers for the following questions:

   1. The path of the new package you built last Friday
   2. What's the % of the tasks? (Find this in the release folder)
   3. What's the % of the budget? (Find this at the Project Progress Report)

   I am currently working on Swift ?Release_10_Jobs
   
   

   • I did a build on Friday see http://ant:8000/Swift/
   • It is 60% Complete
   • Budget:
   • Authorized: $75,000
   • Spent: $39,715
   • I expect to finish on Fri 30/05/2008
   
   
   

   Regards,
   
   Eric Phan

   Figure: The above is a sample of the weekly project update report.

3. Do you email clients as soon as you realise you will overrun your original estimate?

   To: Jo CC: David (Manager) Dear Jo Release 3 of Target Contacts will take longer than expected. This is to let you know that the data migration of the Coverage Data is more complicated than originally anticipated because and external database (Media Disk) also reads from the coverage table. I am revising the estimate accordingly to 16 hours. Regards, Tim

   Figure: Notify the client of an email like this, that the estimate has been or will be exceeded.

   Do NOT wait until you have met or exceeded an estimate before you notify the client that the project running late. As soon as you realise that any of your estimates are likely to be exceeded by a margin 10% or greater, then let the customer know ASAP by phone and by email. This will ensure that the client is fully aware of any problems and have a chance to respond to them.

   Never keep the client in the dark when you exceed your estimates as it will only arouse suspicion and mistrust when the project deadline wooshes past!

   
   

   We have a program called SSW eXtreme Emails! that automatically generates emails to notify the client of an exceeded estimate.

4. Do you notify your project managers and clients of code and other application changes?

   You will inform your managers/clients of code changes where possible. To do this, you will put code snippets of the the changes into an email outlining what modifications you made (highlighting changes in yellow).

   This has several benefits:

   • Improved visibility and transparency - The project manager can see the work actually being done
   • The project manager can raise questions and issues about the code
   • We have even found that these emails act as a code repository and backup when there are irrecoverable problems with your source control database

   

   Figure:The client/project manager cannot tell what you actually did

   

   Figure:Notify the client/project manager of code changes and highlight the code changes

   For those developers lucky enough to be using Microsoft Team Foundation Server, you will associate your changes with a work item - so that future developers can work out not just WHAT changed - but WHY.

   To do this, you could note the work item in your "Done" email when completing the item. SSW has a tool that does this automatically for you - SSW eXtreme Emails!. This will help you to create Team Foundation Server work items from your emails automatically and associate your code changes with the original work request with Unix-style diff files. In this way, you will be able to work out WHY a particular change was made in code right back to the original mail item.

   

   Figure:Using NotePad2 to view code change (diff files) generated automatically by eXtreme Emails.

   Even better - when using Team Foundation Server, you can use a Checkin policy to force your developers to associate every checkin with a work item.

   

   Figure:You can make developers associate checkins with work items with a Checkin Policy (Right Click Project->Team Project Settings->Source Control)

   

   Figure:You can make developers associate checkins with work items with a Checkin Policy (Click Add)

5. Do you use a project page for your team and client?

   A project page is not a place to introduce the project. It will be used to share the project process information between your teammates and clients.

   A project page will contain some basic components:

   • Link to mockup, test and live environments
   • Every release of the project
   • Related resource download

   

   Figure: A sample of project page

6. Do you know what tasks are in a Release Plan in addition to Development Work Items?

   Just like building a beautiful house is more than the bricks, a software project is more than the sum of the coding tasks.

   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.

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

7. Do you provide project progress report for clients?

   Communication is a critical part in project management and it's essential to provide as much information as possible for your clients so they know the progress. We provide the following two reports for clients:

   • Project Progress Report: help our client to review the current project progress, check the status of projects whether they are over or under.

     

     Figure: Project Progress Report

   • Project Update from eXtreme Emails, this 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

     

     Figure: Update Report Email

8. Are you flexible with the ordering of your releases?

   Every now and then your clients are going to want to move on to another release which they see is more important than the current one. Provided that it doesn't have any negative effects on the current release, there will not be any reason why you can't stick to the "customer is always right" philosophy. So what will you do when this happens?

   1. Move any left over work/items to the next release
   2. Send a debrief to the client with a note eg. As per your request we have just cancelled Release five and will start on Release six. The remaining items have been moved into Release seven.
   3. Send a Release Plan for the new release

   We have a program called SSW eXtreme Emails! that allows us to manage releases and track our project's progress with a built in estimating and reporting tool.

9. Do you get approval for additional items and when estimates will be exceeded?

   Clients tend to pay bills a lot quicker if they have approved the work you have performed! Release Plans are required to be formally approved before work commences. Similarly, any changes to the release plan need approval. Changes to the release plan can take two forms:

   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 and confirmed in an "as per our conversation" email.

10. Do you get work approved before you do it?

    

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

    It's sometimes said that it's easier to ask for forgiveness than it is to seek permission.

    The trouble is that the above is predicated on the notion you're doing something wrong, are happy spending time putting out fires that needn't have been lit, and don't mind living with stomach ulcers...

    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.

Acknowledgements