The situation: We are a small, fully-distributed software solutions provider. We serve multiple clients, and given our size that means every team member is on multiple, part-time billable teams. Usually 2 such teams per person, to minimize context switching. Everyone works a total of 30-40hrs a week, varying from week to week per available work and normal challenges. All teams estimate work using story points or hours, but definitions of these vary by client, as does the methodology (Kanban or Scrum, with varying iterations) and tooling (Jira, PT, and V1).
The problem: Taken together, team composition and execution is never consistent enough to support typical velocity or efficiency metrics, in turn making it a challenge to create trustworthy targets for clients (e.g., where we'll land in a backlog by given dates, prospective work estimates). We do our best to maintain team composition for a few months at a time for continuity's sake, but the aspects mentioned above obviously induce hard-to-predict outcomes and probably obscure other concerns.
So, how can we get better, preferably without drastically changing how we do business?
Approaches that have occurred to us so far have important gotchas:
We lock down our inputs (e.g., definition of story points), methodology, and tooling and iterate until we get as good as we can with them. The gotcha, as we see it: Client relationship risk, since most already have teams, methodologies, and tooling we coexist with.
We come up with per-person, aggregate-able velocity metrics, cross-referenced by the kind of work, team size, etc. as we gain understanding over time. Gotcha: Based on our research this seems speculative and could take forever to lock down.
We stabilize our teams to enable more traditional velocity metrics, estimation, and planning techniques. Gotcha: Business development and sustainment risk, since this will reduce our ability to mix and match teams in response to budget changes and new work.
Which of these sound most effective? Or a mix? Any other ideas?