Peter Merholz has given us a system-sensitive [CMS} innovation insertion process.
The process is cyclical but follows the sequence listed below. (In what follows I have taken liberties...with the aim of abstracting the more general innovation insertion model. Apologies to Peterme where I have misinterpreted and thus misrepresented)
1. Gather Assumptions and Requirements
2. Analyze Competition
3. Understand Goals and Tasks
4. Develop Persona's and Scenarios
5. Build content Model
6. Design Information Architecture
7. Prioritize Features
8. Design Interaction
9. Protypes & Patterns
10. Validate Usability
[Repeat Process ]
* please go to link... Diagram is much more appealing; I'm still awkward at picture insertion into a weblog
Such as it is, the cycle "begins" with "Gathering Assumptions and Requirements." This is the step where you look internally to understand the [organizational or system] drivers of whatever project you're involved with. The thing is, that's pretty much where [many organizations] began and ended. They understood the [--] drivers, got a sense of the features and functionalities they wanted, and then would go out and buy software to solve it.The problem is, as they learned, that the issues isn't with features and functionality, but with the software fitting into current work processes. What this means is that, when buying [functionality enhancement] software, companies need to do more work, move forward along the cycle, to "Understand Goals and Tasks." This is where you observe user behavior and needs in order to understand the processes people engage in to accomplish their tasks.
What surprised the client was that they thought this was the responsibility of the vendor. Part of the reason they bought this software was for the "wisdom" the software was meant to have embedded within. That there was a "wisdom" in how the software presents work processes, and that the company ought to learn from that wisdom and adjust their work accordingly, taking advantage of this "wisdom."
This totally took me aback. How on earth could this enterprise software tell you how to do your work? It's your work! And, this is what the client learned, in a painful way. That software can't come in and change how people work--such software will simply be ignored, be rejected. [The organization/system has] to step up and take more responsibility for the integration of software within [its complex of processes], because no one else knows how [its processes work, individually or as an interconnecting set of processes]. This is something that content management system vendors have had to deal with, and has lead to a solution of separating the content/data and the presentation.
Remember, the problem with the software wasn't features or functionality, it was how those tools were presented. Unfortunately, the design of the system was hardcoded [and thus less amenable to the adjustments necessary to make fit within present work processes]..
What will be clear, moving forward, is that [system enhancement] software companies will have to follow the lead of CMS and provide a greater degree of flexibility in how people can interface with their tools.
I found this sequence, after thought and interpretation, to be quite useful as a model for inserting a new process into a [CMS] systems process flow. Good notions.. my bet is, after client adjustment to a higher level of responsibility, that the insertion is more likely to be successful.
I'm concerned with the subset of organizations whose continuing survival is not based on whether or not they achieve their explicit purpose(s). (Patronage systems, a significant subset of school systems, armies, etc., many families, etc.) In some sense they are intact (jobs stay, walls are up, cash flows etc.) -- but for the organizations I'm referring to, the appropriate, objective and subjective evidence of "doing well what it's supposed to do" is meager or absent. And, upon deep inspection, one finds out that there are processes that work against functional productivity.