Frequently, we're hired to produce a product. We write code and set up a production environment and deploy to it. We build the features the client wants, in the order the client wants it. We show the client progress along the way. Life is good!
This approach puts a lot of work on the client. The client has to:
- Plan releases or marketing pushes that include groups of features we're building... and time those releases.
- Make sure the backlog is full enough that the team can work efficiently, which gets even harder when the team has specialists (and a CSS guy/designer versus a server-side coder is a specialist!).
- Set expectations with his bosses or clients based on the team's work, even across vacations or sick days.
For some clients, particularly clients who are themselves experienced engineering managers, this is not a problem. They're used to looking at past velocity, evaluating a backlog, considering relatively complexity and risk, and setting a reasonable release date. They're also used to actively managing a backlog considering not just priority but the team's skills and availability.
For other clients, this is a bit much. They're simply not technical clients. Or they've never managed a team before. Or they don't have enough exposure to the team to see when vacations happen or when the team makeup changes. For these clients, if you want to be successful as a consultant, you have to help them with all these things.
No matter how good the product is you build, if you're a consultant, you're offering more than the product. You're offering the product and the way it gets to the client over time. Consider your client, and make sure you're covering the delivery as well as the product itself.