I watched an SAP presentation today about their NetWeaver platform, and although the product was only of peripheral interest to me, I love their philosophy on how to get started on a project: think big, start small.
I can’t even count how many projects that I’ve seen fail, or miss their targets significantly, due to over-reaching on the first phase. Usually, someone gets all excited about the technology and before you know it, they’re trying to implement the 8th wonder of the world in Phase I. Schedules slip, but even worse, vision slips: often, no one is left with a clear idea of what is to be accomplished, or the path to getting there. [Of course, the converse is just as bad: the pilot (a.k.a. Project In Lots Of Trouble), where someone hacks together a system without proper design or testing, and it becomes the cornerstone of a future legacy system, but that’s a story for another day.]
This type of scope creep is especially prevalent on BPM projects, since it’s so (conceptually) easy to just add another step to the initial process, then another, and another. What starts out as a simple process with 2 human touch-points using an out-of-the-box interface and 3 system touch-points using standard adapters becomes a morass of custom interfaces and extraneous exception paths. Without fail, the biggest argument that I ever have with anyone on a BPM project is about keeping the first phase small so as to get something into production sooner.
Of course, as a designer, I believe in getting some amount of the design work done up front: you have to understand the overall scope and the required functionality to provide a framework for the work, but you also have to carve off a reasonable first phase that won’t take too long and will provide a useful system, when implemented. In the case of BPM projects, if you can’t implement that first something inside 6 months, there’s something wrong with what you’re doing.
Think big, start small.