Champions
Thursday, April 5th, 2007For any project, find a user-champion that will carry forward, advocate for, and ultimately, love your project.
The other day a colleague and I were discussing a dauntingly large project. Effectively, we are planning on completely re-developing our web strategy and moving to a new technology. A huge task, no doubt.I rather adamantly suggested that we break the project into smaller pieces, and focus firstly on one chunk that I felt would have the most “bang for the buck” (the main CMS, if you must know). I advocated a rather agile approach, getting some users on board with us as a pilot group, and then expanding from there.
My colleague didn’t think it was a good approach, so dismissively challenged that I try to make it work with some of our most difficult users.
These are, apparently, a group of neophobic users with a history of poor relationships to our department and a host of other hurdles tied to them. If I could get them onto a new system, he stated derisively, I could get any of our other users on it.At first, I was defiant. I wanted to prove him wrong (I’ve always been one to challenge people with they dismiss my ability to surmount a goal). I quickly realized, though, that working with a group of users that do not want to be worked with is a fool’s errand. I quelled my defiance.
Success of a software development project, in my mind, is all about taking the (long-term) path of least resistance. It’s about finding those paths that will make your (or the future developer’s) life easier. That way, it becomes less of a painful slog, and more about facilely getting it done. More about feeling good about what you’re doing. More about enjoying coding.
Adding complexity and more headaches to chase down uncooperative users does not sound fun, nor do I think they will assist with getting a project going. They won’t push for it, they won’t tell others about it (positively), and they ultimately, won’t care about it. These people will more likely weigh me down, and make me despise the project before it ends (if it ever does!). Not a good time.
On some (very) successful software projects I’ve been involved in, both for this position and prior, I’ve had users that immediately took to what I was doing. The cheered on my successes (since it was a new feature, bug fix, or just better training), and they espoused praises of the application. The praise got around, I got more recognition as a successful developer, and other people started asking about using the software, too. It was growing without a word from me!
These, my “champion users”, were key in getting and refining the project requirements. They pushed to get support, they told my managers when things were going well, and they offered suggestions when they broke. I’ve started to realize that, even if you dearly care about a project’s success, if you don’t have a project benefactor (read “user”) on your side to champion it to others, you’re probably screwed.
So I’ve started making a point to always get one with me. It helps me plan, it helps me work, and, in the end, it helps me feel successful. Once we get ourselves a nice huge Katamari of users to provide momentum, we can roll up the difficult cases. :)
Back on the project itself - To my colleague, I advocated to instead find users that care about what we would be doing, have a stated need that we could fill, and have previously been upbeat towards new things coming from us. If we had these, champions, I argued, they would help us move forward on the project.
Eventually, he quelled his challenge. I was told that I could pursue my project of choice, and that I could pick the pilot user group I wanted. I was pleased. :)
Does this mean I will be successful? Nothing is certain, but I like to think that it will be a key component in ‘making it work’. At the very least, working with people that genuinely appreciate what I’m doing will make it that much more fun.