Rules to Better Software Consultants - Happy Clients

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!

This page is for both developers and Account Managers

Aiming for 'happy clients' can be an elusive game. Ultimately what makes one client happy is different from what makes another happy. However the first step to keeping anyone happy is to manage expectations from the beginning to the end of a project.

The following steps are the processes by which you can manage client expectations and, with luck, keep them happy...

​Figure: Making premature statements is not an effective way of managing expectations
  1. Do you use a Project Portal for your team and client?

    Every project needs a Project Portal to help developers communicate and collaborate with clients and each other.

    A Project Portal should contain:

    • The Sprint Backlog (for the developers and the Product Owner)
    • The Sprint Backlog Overview (for Testers - what to test)
    • The Burndown
    • Past Sprints of the project
    • Link to mockups, test and production 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 (or a link to the CRM record)
    Figure: Bad Example - A project portal that is manually updated. This example is from Metal Corp

    10-08-2012 10-59-45 AM.png
    Figure: Good Example - A TFS 2012 Project Portal. The Activities menu has all the actions a Product Owner needs

    Note: If you use TFS2012 or 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

    Figure: A SharePoint 2010 Dashboard integrated with TFS A Project Portal is also a great place to hold files etc so you can send links to clients instead of files. This is explained further in "Do you know not to use email to forward client attachments?"
  2. Estimating - Do you know what tasks are involved in addition to just Development Work Items?

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

    Let's see what should be included :

    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.

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

    Do *not* wait until you have started to exceed your estimate before you notify the client that the release is running late.
    Keep them informed and avoid conflict by sending an email like this: ​

    To: Mr Northwind
    Cc: David (Project Manager)

    Dear Bill Northwind,

    As per our conversation, The Data Migration task in Sprint 3 will take longer than expected and so looks like it won't be delivered this sprint. The data migration of the Coverage Data is more complicated than originally anticipated because an external database (Media Disk) also reads from the coverage table. I am revising the estimate accordingly to 32 hours.


    Figure: Good Example - A sample of an email that informs the client that the estimate will be exceeded

    As soon as you realise that any of your estimates are likely to be exceeded by a material margin (about 20%), then let the customer know ASAP by phone and by email (using the 'as per our conversation' rule). This will ensure that the client is fully aware of any problems and has a chance to decide an alternative action. 

    Never keep the client in the dark when you exceed your estimates, it will only arouse suspicion and mistrust when they see the project deadline woosh past.

    Note: For Scrum projects, you should keep an eye on your burndown chart during your daily standups to see if you are on track to finish all the work in a Sprint.

  4. Approval - Do you get work approved before you do it?

    "Sometimes it's better to ask forgiveness than permission" - Tony Abbott

    The trouble is that the above is predicated on the notion that you're doing something wrong and are happy spending time putting out fires that needn't have been lit.
    Let's see how to live without stomach ulcers...

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

    Get permission for the work you do *before* you do it. Usually get permission verbally, confirmed with an email  (or with a signature, ​although that's sometimes a whole lot harder).

    The natural time for this conversation to occur is in the Daily Scrum

    Always get permission for:

    • Additional Items
    • Investigation time for scoping out additional items
    • Adding additional resources onto a project
    • Exceeding estimates
    • Data migration

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

    This rule is not generally applicable if:

  5. Approval - Do you assume necessary tasks will get approval?

    When you are working on a project, you need to follow the get work approved before you do it rule. However, you should assume some tasks will be approved by a client and do them anyway. This of course depends on the size of the task (e.g. half hour or less) and the obviousness of the task. ​

    If you reasonably assume that the task you are working on would be approved by the customer, and it will take less than half an hour, you should go ahead with that task.

    To: Scott
    Subject: QWI - Aqua UI Improvements from Adam

    Adam suggested that we make the positioning of the "New" Button consistent on all forms. Move the New to the right with the Save and close buttons. Estimated 15 minutes.
    Please approve.

    Figure: Bad example.

    To: Scott
    Subject: QWI - Aqua UI Improvements from Adam

    Adam suggested that we make the positioning of the "New" Button consistent on all forms. Move the New to the right with the Save and close buttons. Estimated 15 minutes. 

    I have made these small changes. Test please.

    Figure: Good Example.
  6. Do you send "Sprint Forecast" and "Sprint Review/Retro" emails to the client?

    Each sprint has a "Sprint Forecast" email that details what will be worked on during this sprint.

    At the end of the sprint, this should be replied to with a "Sprint Review" email that shows a breakdown of what was completed.

    Each sprint has the following stages:

    1. Planning meeting:
    2. The work is done:
    3. Review and Retro meetings