There is growing interest in the software industry in particular, in a concept known as "Agility". In truth, it's not a new concept and traces its origins within the software industry to when computers occupied entire buildings and programmers used punch cards. This is because Agile isn't about technology; it's about culture and new paradigms of thought, and those things change much more slowly.
One of the core values of the Agile movement is "Responsiveness to Change". It doesn't mean you don't plan (in fact many Agilists will insist you need to be constantly planning). Rather, is says by all means have a plan, just recognize that it's going to change. Whereas the old school philosophy says "plan the work, work the plan", Agile philosophy says "plan for change".
We see this value put int practice to some extent, in most ABA programs. The Analyst starts with an assessment of where the child is at, and lays out a set of programs (we call them "modules" to avoid confusion) and behaviour plans to address the current needs. The team then goes to work, and after some time the Analyst goes through the results and makes some course corrections based on the results.
In my professional practice as a software management consultant, I recognize this pattern as being very similar to how software release cycles are typically managed. Developers may be constantly adding valuable incremental features (in the same way that your EIBI team is constantly adding targets and working them though to mastery), but those features (trial results) are being asked to wait for batch processing into a larger release (direct inspection by the BCBA / Analyst).
In other words, the team is able to do the work but the results can't be compiled quickly enough to create frequent value. You could have your Analyst come to your home every day but wow that would be expensive. (If your job title is "Release Manager", imagine being asked to run a daily release - for each of a dozen parallel projects - and you'll get an idea of the scope of the problem.)
The solution we love to recommend sounds simple - "reduce the batch size!" Make smaller software releases more frequently. Stay on top of the child's progress by analyzing trends more frequently. But if your supporting infrastructure doesn't support this frequency, that advice is really not very useful.
The good news is that much like Release Managers now (finally) have an arsenal of tools to help them build that infrastructure, Behaviour Analysts now have the tools available to help them monitor real-time progress and make frequent programming adjustments.