« broken, then fixed | main | free book »
from Accept responsibility to make your online project work
"Business managers can make online projects by accepting the responsibility for their design - or court disaster by letting technologists shape them."
This is an intriguing look at what happens to a project from conception to reality. The trouble comes when the project is handed over to implementers. "...they hire people and firms who have built software and systems. 'Those people and firms have their own interests', Thomas points out, 'and those interests won't necessarily align with the aims of your outfit. The outsiders want to bolster their list of stated achievements - their CVs, their corporate brag sheets. The individual developers want to work with bleeding-edge technology. The more pragmatic firms want to re-apply previous solutions.'"
As Sartre said, "hell is other people"
Guess what the recommended cure is? Something remarkably similar to an aspect of IA-- interaction design. The article recommends that managers "define in precise detail what users of the system can do - a tough, confronting task which takes place before a single line of code is written, and which requires managers with at least a small measure of technical savvy and a great deal of determination."
The article's key failing is not recognizing that business folks are no more trained to design a humane system than engineers. There are three part of success... what is technologically feasible, what is business necessary and what is user desirable/acceptable. Pay too much attention to one of elements, and the project's likelihood of failing shoots through the roof.
If you don't sympathize with what's described in this essay, you've led a charmed life. I'm on a project right now where I'm trying to figure out who is making decisions and defining requirements. I think it's the offsite programmers....
I do sympathize-- deeply. But I still think it doesn't go far enough. In some ways it's a riff on "inmates", which also blames engineer's inability to understand users for the failings of technology products. Of course they can't-- most engineers (not all!) aren't wired that way. I'm just saying, neither are business folks. I agree that business managers need to keep a sharp on on the implementors to assure the business vision is being held, but they also need to hire UE types to keep an eye on the end user experience. Of course, then they'll have to watch the UE's as well, to assure that the user experience is balaced with the business need. But that's what the venn diagram is all about: finding a balance that assures a successful product.
This project also has had no formal definition of requirements nor has it really identified the users in nearly 20 months. The developers have sorted out who the users are and have put together rough requirements, but the business management disagrees with what the users are asking and want functionality that is counter to what the organization does. The scope of the project changes drastically as the inital elements required that drive the project should come from the knowledge of their own business, which is not constant.