Rules to Better Software Consultants - Happy Clients - 7 Rules

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.

Do not wait until you have started to exceed your estimate before you notify the client that the release is running late.

An oversized invoice with no warning is never a good experience. A client will always prefer to be told ahead of time if a piece of functionality is going to take longer than anticipated. It gives them more control of what is going on.

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. It's best to tell the client as soon as the risk is identified to inform them of what's going on and ask "Do you want us to continue?".

For this reason, blowouts should be reported in the Daily Scrum, as well as any major delays being told to the client as soon as possible, so that they don't get a big surprise in the Sprint Review. This will ensure that the client is fully aware of any problems and has a chance to decide an alternative action.

Keep clients informed and avoid conflict by informing them ASAP and documenting estimates overrun in an 'as per our conversation' email:

"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 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:

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

This rule is not generally applicable if:

• You are working on an ad hoc basis on a client managed project
• 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.

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: ScottSubject: 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: ScottSubject: 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.

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.

If you're using GitHub to manage your project, create repeatable templates that can easily edited and emailed out.
See GitHub Issues - Do you create a template for your Sprint Reviews, Retros and Forecasts? for more details.

Each Sprint has the following stages:

1. Planning meeting

   • Sprint Forecast email: "Northwind - Sprint 5 Forecast"
   • See Do you send "Sprint Forecast" email to the client? for more details

2. Work in progress

   • "Done" emails are sent asking for specific functionality to be tested
   • See Rules to better Email for details

3. Review and Retro meetings

   • The Sprint review/retro email: "Northwind - Sprint 5 Review/Retro"

When you are about to finish a client project, it is a good idea to prepare a "thank you" email, have it checked and send it to your customer (usually the Product Owner) on the last day. In this email include:

1. Make sure you have completed all requirements
2. Thank for the time and tell them the reasons why you enjoyed working on this project
3. Prepare a list of future improvements you can think of that can be done

There are a number of reasons why this is important:

• It shows that you care about your client/project
• Give them something to think about. They might get you back to fix the problems you have identified
• Show that you will be supporting them after the project ends

Below is a template email you can use:

Email Template

It is really important to understand the difference between a Proof of Concept (POC) and a Minimum Viable Product (MVP). It is also important that clients understand the difference so they know what to expect.

POC: Proving Feasibility

A POC is developed to demonstrate the feasibility of a concept or idea, often focusing on a single aspect of a project. It's about answering the question, "Can we do this?" rather than "How will we do this in production?" POCs are typically:

• Quick and focused: Developed rapidly to test a specific hypothesis.
• Experimental: Used to validate technical feasibility, explore new technologies, or demonstrate a concept.
• Disposable: Not intended for production use; often discarded after proving the concept.

POCs should be built, tested, and thrown away. They are not intended to be used in a production environment.

MVP: Delivering Value

Conversely, an MVP is a version of the product that includes just enough features to be usable so stakeholders/users can provide feedback for future product development.

• End-to-end functionality: Covers a single feature or user flow in its entirety.
• Production ready: Developed with more attention to detail, as it will be used in a live environment.
• Foundation for iteration: Serves as a base to gather user feedback, validate assumptions, and guide future development.

Examples

Consider a startup exploring the use of AI to personalize online shopping experiences. A POC might involve creating a basic algorithm to recommend products based on a user's browsing history, tested internally to prove the concept's technical viability.

Building on the POC's success, the startup develops an MVP that integrates this personalized recommendation engine into their shopping platform, deploying it to a segment of their user base. This MVP is monitored for user engagement and feedback, shaping the future roadmap of the product.

Best Practices

• For POCs: Clearly define the concept you're testing. Limit the scope to essential elements to prove the hypothesis. Remember, POCs are not mini-products.
• For MVPs: Focus on core functionality that delivers user value. Engage with early users for feedback and be prepared to iterate based on what you learn.