CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Introduction
Software is easy if you are crazy as hell.
—paraphrasing Bo Jackson, speaking about Football
Conducting a postmortem—which literally means after death—when a project is over is a great idea. What’d you do well? What can you improve on? How do you do better next time? Sort of like tallying up the scorecard. Of course, I have never seen a really great or official postmortem, but they are talked about a lot.
More common than the postmortem is the ante mortem. Literally, an ante mortem means “preceding death.” An ante mortem is kind of like a mid-course correction. What are you currently doing well? What are you currently doing badly? How do you fix it? The problem is that most ante mortems are conducted like postmortems; a corpse is all that is left when the fixers are done. In simple terms, never-ending ante mortems are the software equivalent of Monday morning quarterbacking on Sunday night.
I am going to introduce a new concept, Focus IQ, in this article. I will tell you what it is, what it will do for you, and how to increase your software project team’s Focus IQ. Before I start, I will tell why it’s important. Here it is: Focus IQ is important because lack of it is what’s wrong with most projects. A high Focus IQ will help keep your project off the ash heap and your company out of Chapter 11.
What Is Focus IQ?
An individual or team’s ability to focus on the right thing is their Focus IQ. Too many distractions and teams wander around like a small child lost in a big wood.
Focus IQ is not like regular IQ. A team’s Focus IQ doesn’t drop from watching too much TV. A team’s Focus IQ drops when the team focuses on the wrong work tasks. Here is a list of the wrong tasks and consequently things that will drop your team’s Focus IQ:
- Protracted ante mortems cause a drop in Focus IQ. Incessantly looking for causation will kill a project as surely as inaction.
- Shiny object syndrome causes a drop in Focus IQ. Shiny object syndrome—aka kid in the candy store syndrome—is caused by people who constantly want to swap in the latest and greatest release of XYZ software’s latest widget, operating system, development environment, upgrade, and so forth.
- Monday morning quarterbacking will kill your team’s Focus IQ. This is similar to the ante mortem. MMQ is when some manager or executive runs out and finds “other experts” to explain what’s wrong. This seldom works because experts don’t even agree with each other in this business.
- Ask some guy syndrome. This is a variation on ask the experts. The scenario goes like this: Bill is a pretty smart guy, so someone asks Bill what he thinks is wrong. This is even worse than ask the expert. At a trial, they at least insist that the pedigree of “expert witnesses” be established and agreed upon before listening to their advice, but in software development everyone thinks he is an expert.
- Too many chefs lowers the Focus IQ. Too many chefs is software designed by committee. Everyone gets to vote, everyone’s opinion has equal weight and merit, and the majority rules. Do you really want to trust your project to the same process the runs our government? Enough said.
- Constipated bureaucracy lowers your Focus IQ. Constipated bureaucracy is when no one knows who owns the final decision any more. The more constipated you get, the harder it is to do anything.
Maybe you can think of more things that hork up a project and that’s what a low Focus IQ does. But, I think you get the picture now.
To the Heart of the Solution: What Is the Right Focus?
Now, you are getting somewhere. How do you increase your Focus IQ? It’s so easy, it is almost painful. You increase your Focus IQ by spending your time the right way. But what’s the right way, you say?
The answer to increasing your Focus IQ is to ask the question: What are we trying to accomplish? And the answer is (in software development, anyway) to build software a customer wants, needs, and loves. The way to do this is ask what’s really important. How would that work? Build that, and ask the customer did you get it right? Then do it again. If you or your team is doing that, your Focus IQ is maxed out.
Do you have requirements that are detailed enough that they describe what to build? No? Then, for the highest Focus IQ, your team should be focused like a laser on getting those requirements. On one hand, you have a meeting about coding standards and the other a meeting to get some requirements details. Which do you choose? Getting those requirements. Ah, now you’re a Focus IQ savant.
I have requirements. My Focus IQ is moving up. What’s next? Do you know what’s most valuable and important to the customer? Well, start designing it, create a couple prototypes, write some great use cases, and maybe some flowcharts or activity diagrams to make sure you understand how this thing will work out problems. Focus IQ just went up.
Notice that nowhere did I talk about coding standards, project plans, timesheets, language wars, or process meetings. That’s because none of that stuff is a deliverable to anyone. You are building software. If your team is doing all that stuff or any of the stuff in the preceding section “What is Focus IQ?” your team’s Focus IQ is like that of the brain in the movie Young Frankenstein, AB Normal.
If you go to work everyday and feel like you work with retards, it’s not really them (hopefully). People who work in this business are very smart generally. The problem is that the team’s Focus IQ is so low it has temporarily made everyone seem a little dimwitted.
What’s the solution? Focus! Focus! Focus! Just asking a couple simple questions and acting on the answers will help get you on track. Is what I am working on right now directly going to help me deliver a high value, high complexity part of the solution to the customer’s problem? If the answer is no, put that task in your TODO pile and come back to it after the software is done. (The key to the first question is “high value, high complexity.” Dropdown lists, screen colors, and fonts don’t even come close to qualifying.) Next, ask is what I am working on right now helping me or my team move forward or sideways? (That is getting more features done or change something that already works.) If the answer is sideways, flop it onto the TODO pile; if forward, keep chugging along.
The two most important things that any team can do right are 1) get good, detailed requirements but they don’t have to be perfect the first try, and 2) prioritize problems by high value and high complexity. If the problem your team is working on isn’t the one that scares the crap out of the customer, and the requirements you have don’t explain it in a manageable way, the Monday morning quarterbacks, morticians, experts, chefs, bureaucrats, and people suffering from shiny object syndrome will be showing up, soon, and they will be happy to tell you what’s wrong. And, they will probably think you are retarded.
About the Author
Paul Kimmel is the VB Today columnist for www.codeguru.com and has written several books on object-oriented programming and .NET. Check out his upcoming book LINQ Unleashed for C#, due in Spring 2008. You may contact him for technology questions at pkimmel@softconcepts.com.
If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org. Glugnet opened a users group branch in Flint, Michigan in August 2007. If you are interested in attending, check out the www.glugnet.org web site for updates.
Copyright © 2007 by Paul T. Kimmel. All Rights Reserved.
