The question posed was “How to stop wasted development when business units get the UI (user interface) and point out that’s not actually what they were after……?
There is no need to agonize over User Interfaces.
We all work the same way 1) attending to fixed time tasks each day and then 2) attending to floating time tasks in between fixed time tasks. Users of Critical Path Method software in the construction area don’t worry about UI, it was done right the first time around (late 1950’s) and has stayed pretty much the same ever since. It’s in use in hundreds of thousands of sites worldwide.
So it’s really not about the UI, the issues are with workflows, steps, how the steps are interconnected, what forms are needed at each step, and how steps are routed for performance (skill assignments).
As for “development” you can pick any day of the week, define a small scope of work, develop a process map, compile it and ‘piano play’ it in the ultimate UI where the users see THEIR workflows with THEIR forms without any development.
Firstly, if you pick the right software environment, no “development” in the usual sense is needed, you just make images of all of the forms the organization is using, put these in a “bucket” and then, as you build your process map on an electronic canvas, you drag and drop forms onto the workflow steps.
For prototyping, you do not need to actually build forms (in any case it only takes 1 hour per form page and most organizations only have 200 forms).
And, in respect of decision boxes/branching nodes, you don’t need to build rule sets for a prototype, just make the decision boxes manual at the start and once the users agree on the workflow, the steps and the forms, then you can add rule sets at decision boxes that are capable of being automated.
And yes, the process mapping can be done in real time, in front of the stakeholders, as fast as they can say “. . . and then we do this”.
End result: Starting in the morning with a reasonable scope of work, you end up at 1700 hrs with a “piano-playing” working prototype.
And, no need for “development” in the usual sense to get from the prototype to a production system.
The good news is your prototype, after you convert the ‘as-is’ to ‘should be’, can be put into production.
Well it isn’t – you need a good facilitator who can “herd cats” and keep the focus on ending up with processes that are reflective of strategy/goals. The facilitator has to be super familiar with the software otherwise the audience gets bored if the process mapping lags the live process building session. And, all of the forms imaging has to be done as part of the “homework” prior to appearing in front of the stakeholders.
As always, it helps if the facilitator is familiar with the industry area, the application area and the lingo the stakeholders routinely use. A repertoire of bad jokes helps to keep things rolling.
Lastly, you cannot have stakeholders exiting from the room every 5 minutes, so if you want results, organize a weekend ‘retreat’ with no phones and a locked door so people cannot escape.