He Who Fails Fastest, Wins
There’s a concept in software building called “agile development“. In simple terms, it means that you don’t spend a whole lot of time making a huge complicated plan of every little detail of the whole finished product. (This is pretty counter-intuitive, and really makes most people pretty nervous.)
Here’s one way to think about it. If you’re going to go to DisneyWorld, you could spend a year reviewing brochures and maps of the entire kingdom. Plot your course, exactly which rides you’re going on at what time, where to eat, and how much to spend at each gift shop. Then when you got there you would just measure your success by how well you kept to the plan.
Another way to do it would be just get in a car and drive to the park. Your goal would be to have fun, see the sights, and come away with some good memories. Each day, you’d huddle with the other members of your group and exchange experiences and talk about what you’d like to do next. Most likely, you’d find that many of your early ideas had changed. Some parts of the parks were just not as interesting as you thought. Some were much more interesting.
So day by day, you’d make minor course corrections in the plan — all based on constant feedback from the users. And each round of review would get you closer to that goal of “good memories” that you had at the beginning. Incorporating nearly constant feedback would make sure that your ultimate goal was reached — and your willingness to be flexible and not tie yourself to a rigid plan made months ago would ensure that you could get to the goal.
So how might we apply that to learning? Take a look at how most of us approach courseware design. We perform a needs assessment, create some kind of functional specification, develop a design document, a development plan, do a little production and quality control, create a version 1.0 and send it through edit and stakeholder review, and then finally release it to the learners. By that time the thing is pretty fully baked, and only major problems are going to get addressed.
How about if we just set some major goals — “learners can apply sound lending principles to home mortgages” or something like that. Then we create a quick module, roll it out to some learners, and get feedback. Our stakeholders give the feedback review, we incorporate it, and do another loop. Each cycle brings us closer to a product that meets our goal, and our quality improves with every evolution.
Set down your laptop, and head outdoors. Take a look at how ants build an anthill. They pile up the grains of sand in a pretty organized fashion, but as obstructions appear the hill may take on a completely different shape than what you might expect. But they reach the goal.
I Want My Doctor To Be Arrogant
When I go in for major surgery, I want my surgeon to be arrogant. I’d like him to truly believe that he’s the best there is at this procedure and that I’d be a fool to go elsewhere. I’m not even sure that I want him to spend a lot of time trying to explain to me, a rookie, exactly what he’s going to do or why.
Early in life I had to choose between honest arrogance and hypocritical humility. I chose honest arrogance and have seen no occasion to change. — Frank Lloyd Wright
As I board a 767 for a flight on a stormy day, I want my pilot to be arrogant. I want her to bristle at any implication that she can’t fly the socks off of every single male pilot in the company, with one manicured hand tied behind her back. And I really don’t want her to spend any time trying to make sure I’m comfortable with the route she’s planning or how much fuel is on board.
Timing and arrogance are decisive factors in the successful use of talent. — Marya Mannes
When I’m in a burning building, I want that fireman to be arrogant. I’d like him to believe that he is faster, braver and more skilled than anyone else on the truck. That no matter how dire the situation looks, he’ll be able to get me out and keep me breathing. And I really don’t want him to spend any time considering whether I understand how pumper trucks work or what’s the best way to wield the ax.
It ain’t bragging if you can back it up. — Dizzy Dean
I was told, this week, that I lost a bid on a project because the client felt that I was arrogant. That I hadn’t spent enough time listening to them, understanding their situation, and really explaining exactly what I’d do and why. And I’ve been thinking about this.
It’s a valid complaint. I probably did come off that way. Even though well over half of the time we spent together was taken up by the principal just rambling through his thoughts on the situation in general, as the rest of his team sat mute. Even though the problem they had was no different than any other org that was attempting to spool up on that product.
I’ve got a pretty decent resume on doing exactly the type of work that they were looking for, in some pretty big ponds. Theirs was a very small pond. The fact that I didn’t spend a lot of time asking detailed questions (and turning every single duck in the pond upside down to see if it had feet) must have emphasized that. The fact that I didn’t sound worried about taking on the project, or worried about success, or really even worried about whether or not they wanted to hire me probably did come off as arrogant.
At the end of the day, though — being honest (as Mr. Wright recommends) helps me avoid projects where the client and I won’t mesh well. This group obviously wanted to be very involved in decisions, have me spend lots of time communicating with them, and make sure that they were on board with each choice that I made as we went along. They just weren’t going to be comfortable to get on the airplane, lay down on the gurney, or climb down that ladder on my say-so alone.
That’s certainly their option — and I do have a model where I’m willing to do projects like that — but clients don’t usually sign up.
If you want to help me do the job, I’ll have to charge you double. — Dick Carlson
Now before you start posting comments about how I should just be nicer, or not show this arrogance to the customer, or “pretend” that I’m really interested in how they want the systems managed — tell me the truth.
When the engines flame out, who do you want to land the plane? And do you want them to be arrogant?
ar·ro·gant /ˈær
ə
1.making claims or pretensions to superior importance or rights
But How Do You Get Them To Use It?
I spent time yesterday talking to some folks at a local college, trying to convince them that they should pay me an outrageous amount of money to get their portal site up and running on MOSS. (Not the fuzzy green stuff, but Microsoft Office Sharepoint Server.) Like many organizations, they’d had no trouble installing the software — in fact, they’d had an earlier version three years ago. But the issue was getting the people to use it.
Organizations are all about collaboration tools, these days. The demos show happy employees sharing their IP, working together and easily accessing information across a seamless series of tubes. Everyone is smiling, every document is immediately available, and all their slacks are creased right down the middle.
I’m not sure where these people work, but I’ve never been there. In the real world, actually getting the employees to use collaboration software is by far the most difficult challenge in any roll out. Installation is pretty much a matter of clicking on some wizards, or writing a relatively small check to some guy who logs in remotely to your server. It costs a little more if you actually want someone to ask some questions about how you’re going to use it, but that doesn’t happen very often.
So these folks had some experience with the fact that many SharePoint installations didn’t really end up the way they had hoped. Some groups used them, some groups absolutely refused to, and some groups lost entire days of work when things went wrong. People weren’t always happy about the idea that anyone/anywhere/anytime could look at everything they did. Or that it could be changed, deleted, or “borrowed”. Kind of like having your desk in the hall.
Add to that the fact that early versions of SharePoint (and most of it’s competitors) had frequent issues with access, stability, backups and just plain usability and you can understand why there were issues. If the can of soup you put in your kitchen cabinet vanished one day, and the next day you couldn’t even get the door open — you’d probably start leaving the can out on the counter.
But let’s get back to me and all that money. I told them that the only way I’d found to get people to engage with a community tool was to focus on pain. (Not causing pain, although that might be an option.) I recommend finding a way to eliminate pain for the user.
Here’s an example. If you’re an IT Admin, make a list of the top five calls you get every day. Probably looks something like this:
- How do I reset my password?
- Is my email server up?
- Where is the RAS software?
- How do I reach the helpdesk?
- When is the tech scheduled to arrive?
I recommended that each Sharepoint site at their College just identify the top five issues, and create a dropdown list with links to the appropriate answers. Put the dropdown at the very top of the home page on their site. When a user calls, emails or sends a carrier pigeon — DIRECT THEM TO THE SITE. (Use a friendly URL — “ITHELP” or something, not \\college\datastore\obscure\unknown\confusing\23kks@@3)
Benefits:
- You’ve just eliminated 80% of your calls and emails
- You’ve taught your users that they can get immediate help on Sharepoint
- You’ve taught your techs to put answers on Sharepoint
- You’ve made yourself look like a very smart dude or dudette
But how about the things the college administration wants people to go to the site for — policies, reports, meetings? I probably shot myself in the foot — but I said that was Organizational Development — not something that I could fix with a community tool. (Unless the president said they’d be fired, or offered a bonus of $1000 per visit.)
Once you’ve got people participating in a community, they’ll start coming back. When they need some meeting minutes, or an obscure answer — they’ll go to your node and try a search. If you’ve got meaningful file names and good tags, they’ll probably find what they need. (I’d sure rather do that than play voice-mail tag or wait for you to respond to my email.)
I don’t know if I’ll get the gig — I’m pretty blunt and outspoken, and that puts off some people. But I feel that I owe it to a client that I’m honest about what can and can’t be accomplished with their money.
Think positive thoughts for me.