Many automation projects often have boxes of time that are deemed more critical than others. As a byproduct, project members may only give attention to test automation implementation and its returns during those time periods, as opposed to focusing on the returns over the life of the implementation. While there are serious pitfalls to this "timeboxed" view of automation, Dion Johnson describes some situations where it may be acceptable and even necessary.
What I'm about to write may initially seem insane, but here it goes: Although we constantly rail against it, low test-automation return on investment (ROI) is not always a bad thing.
I know what you're thinking. "This guy has lost his mind! He's drunk with power!" Just hear me out, before you make up your mind.
To explain my crazy talk, I will borrow from the concept known as timeboxing. A timebox is a set window of time given to accomplish a set of tasks. In agile development, teams are tasked with producing new software releases, timeboxed to a specific number of weeks. The concepts in this article are not specific to agile, however, so some liberties will be taken with the concept of a timebox.
Given that most projects have periods of time that are deemed more consequential, more important, or at least faster-paced than others, for the purposes of this article I will define a timebox in terms of key snapshots in time, which may or may not coincide with a project's official timeboxes.
Mature organizations with well defined processes generally focus on how they operate over the life of a project, while less mature organizations give significantly more attention to these timeboxed periods of a project. Working as an automator in a mature organization is the ideal situation.