As discussed in Part One of Making Agile More Agile, Techtonic has deployed a refined version of Agile development to assure all customers receive the maximum value. Created from the debriefs and feedback from dozens of projects, Managed Agile places additional emphasis on precise cost control while maintaining project flexibility.
In Part Two, we will review how our process manages task complexity and creep, and how to price and bill for services.
Managing Task Complexity
The best practice is always to discuss the project with the client before work begins, being sure to cover possible change items and “must-have” versus “nice-to-have” features. This information can be very valuable during project baselining and sprint planning, because it allows you to effectively use the other mechanisms previously discussed (flex spending and change control) to call out how the actual work is differing from assumptions already made for recordkeeping and billing purposes.
This obviously takes effort, and in many cases, it can add significantly to overhead.
Unfortunately, managing change and complexity cannot be solved by flex spending, as this only addresses unexpected modest expenses. Change control really doesn’t “manage” anything either. Managing the complexity of (for example) tasks, team work, and timelines is something clients don’t want to hear about. From their perspective, this is something the dev team should anticipate and manage behind the scenes. Sure, it will take time but if you ask, they will say it’s not their problem. So what should be done? When creating an estimate or project baseline, be sure to account for some shift in complexity. See Part One for several ways to do this – another is to assume this will happen and build it into the original estimate.
There are a number of downsides to this type of approach (although we have seen it used successfully). The most significant problem is it hides these challenges from the client. This means there is no communication or sharing in the solution, and if it impacts the timeline, you are not fostering trust by providing the most current, clear accounting of the project.
The best solution we have found is to manage through the other two processes already outlined and to set the expectation at the start of the project. Always expect some amount of complexity will emerge during the project (not during an estimation phase), possibly related to the flex spending and/or a change control item or two.
Compared to standard Agile, our method more accurately captures product cost and the supporting details. Many businesses and clients want the “freedom” to make changes, and will usually be able to allow the team improvisation needed to handle it. Below is another approach that may work.
Sprint-Based Pricing (with change control in additional sprints) – In this case you can start with an expected number of sprints and vary this throughout the process. It can be done using a change control mechanism as described or simply by updating the time/sprints remaining based on currently requested features as needed.
Billing and Pricing
If you work as an outsourcing partner or service provider, it is particularly important to think about pricing.
As an old sage once said, “T&M is not a project management strategy.” This is true, but it is very effective as a billing method aligned with Agile, and many companies use it. It allows the dev team to use all the tricks previously described, and simply set client expectations. Make sure everyone knows what is needed to complete the project, what the cost will be, and when the work will be completed. This is our preferred approach.
Some clients will want a “fixed bid,” and this works if the scope is well documented. However, all bids generally change – the question is by how much.
I’ve personally been involved with two projects having budgets that were the same on the last day as on the first. One is the 40% flex spending project described above. The client was very aggressive in managing changes after they hit about 25% extra. This means they began telling their own people “no” a lot, and told everyone (including us) to focus on budget and timeline once we reached that 25% mark. Even with those measures, we essentially came in exactly on budget.
The other time it happened, the client cut 50% of the project scope on the first day of development and said – OK, now you have 50% of the budget to make sure you deliver all the changes I want. Tell me when I’ve spent most of it and we will manage carefully from there on out. Which basically amounts to the same thing, except they had to get it past procurement, which is why they asked for much more than they really wanted in the first phase.
Needless to say, those were unusual cases.
What we have in “fixed bid” situations is an initial estimate and an agreement to manage costs through the mechanisms that we described. We prefer to call this “feature based” estimation and cost management, but that can be a mouthful. Sometimes “fixed bid” is the simplest term to use.
Communicate, be transparent, and don’t be bashful. If you are delivering value, the client will be happy to pay. And with Managed Agile, they will know exactly what was received for their money.