What Should You Do When You Don't Know What To Do?

Youth, Exuberance, and Passion

It's All In How You Do It

The Rebirth of the Internet (and the Death of the Web-Site)

Don't Design at the Keyboard!

Working Conditions

Fractals, Mother Nature, and Software Development

What Should You Do, When You Don’t Know What To Do?

© by Mike Robinson

Sooner or later, this will happen to you:

You're tasked to do a project in a subject-area that you know nothing about.
You're tasked to do a project that involves a computer technology you know nothing about.
You're assigned to take the wheel of, and to “turn around,” a project that is today flying straight off a cliff. (Uh huh, now your name's on it, too...)

What do you do now? (Let's say that you basically like the company and don't want to polish-up your resume...)

Don't try to “bluff” ...
Whatever you do, don't bluff. Especially at the beginning of the task, freely confess that you ~~do not have a plan~~ have not decided upon a suitable way to proceed ... yet. Carefully explain that you ~~don't know anything at all about any of this stuff, don't even know how to spell it, haven't got a freakin' clue~~ need to gather a little more more background information about certain strategic aspects of the task. This acknowledgement is reasonable and sensible. It will affirm in people's minds that, when you do come to them with a proposal, it will then be a proposal worth listening-to and trusting.
Trust, in this case, is critically important. Either it has not yet been established, or it has previously been destroyed. If you brashly say things that you later have to retract, soon no one will listen to you at all. They might smile politely, especially if you're the boss, but you will no longer have their respect. In calm seas or stormy, the crew must trust and respect the Captain ... ever so much more so if they're in a lifeboat.
Employ systematic research:
This is actually a most-excellent opportunity for you to review the current best-practices in whatever field of endeavor you are now presented with. If you're engaged in a “turn around,” it's an opportunity both to reconsider the approach that is now being used, and to build a list of other approaches that might be useful.
Thanks to the Internet, everyone who's doing anything is talking about it every day. No matter what you're doing, you can be sure that thousands of other workgroups on this same planet are busy doing it, too. They're succeeding, or they're failing, or they're somewhere in-between. But they talk.
You've got more options than you realize. It's usually best to stick with ones that have been around for a little while, so that you have good reason to be confident that they are not a flash in the pan. You do not have to become a “guru” in any one of them, but you do need to systematically consider what each one could bring to your table. Do your own research, though; don't rely upon salesmen.
Engage other team-members to assist you with this research task. Especially when they feel that they've been lead down a fruitless road by your predecessor, sharing this discovery-task with them can help everyone restore their confidence. But be careful to moderate the discovery process, so that team members (including you!) don't attempt to squash their ideas into other people's heads. Your mutual purpose is to discover and to select; not to create nor to win an argument. As the leader, you have the final say, but having opened-up the door to other opinions, you must demonstrate that you consider those opinions with the same care that you give to your own. People notice this, even if they don't say a word.
Identify decision-factors:
Gather decision factors. To make any decision, one must have a basis for that decision. The decision-factors present in someone else's situation may not apply to yours, but first recognize what they are. Decision-factors include, among other things: hardware environment; existing systems and established business-practices; regulatory compliance; the desire to obtain competitive advantage (and the specific perceptions of how that might be done); budget and deadline compromises; and “soft factors” such as perceived complexity and ease-of-use.
If you are engaged in a “turn-around,” pay close attention to these factors, because up to now the project probably didn't. It's possible that, having made a correct identification, the project plan (if it actually existed at all) didn't spell-out an adequate way to meet them.
If you're doing a turnaround, and any sort of previous decision-documents did exist, review them (and perhaps ask other team-members to help you). Are they right? Were they followed? Were they finished? Were they maintained? Did the assumptions pan out? Where did the project begin to go wrong, in light of these documents? If you see that the previous plan was not upheld, those rocks are still out there.
Keep personalities out of it:
Failure hurts. A year later, it still hurts. Under high pressure, patience wears thin and blame gets attached where it does not belong. Recognize this when you see it happening, and politely stop it in its tracks. Keep attention focused upon the project, and keep your team together. No one knows everything; neither you nor any one of you. Mistakes happen. Mistakes get fixed, and learned-from. We move on.
Link back to the needs of the user-community, and the computer:
Your task is ultimately to build a business-process, for a particular user-community, using the computer. Use these elements as a compass to guide you. If you're straying too far away from the business need, the user-community need, or the abilities of the computers that you have, then you've wandered off-course.
Establish short-term goals that allow you to promise and to deliver usable, practical deliverables on a regular basis, and make sure these are grounded in the expressed needs of the user-community, not your own. Prototypes, such as non-functional web pages that users can see on their browsers, help to make the users' expectations become concrete .. thus, implementable.
Users always know their requirements better than you ever could, and they can be quite inventive. Furthermore, once you explain that you need to prioritize and to stage things, they can help you do that.
Develop a written plan:
No matter how much pressure may be brought to bear upon you to “don't just stand there, do something!” ... always resist that pressure to a suitable degree. If there's a cliff out there to be fallen-off of, you shouldn't leave the safety of the camp site until you know reasonably where that cliff is. If you're going to need some rope to rescue folks that have already slipped, you'll need to know how much rope to bring with you.
Spell-out the decision factors, and with it, the decision process. Say what guided your decision. Later, you can refer to decision-factors that you have set.
Your plan inevitably will have “grey areas.” There will still be uncertainties and unanswered questions. Point them out carefully.
Develop a Punch List:
Begin turning your plans into actions. A “punch list” is a detailed, itemized list of what needs to be done, by whom, and the order in which to do it. The punch list should include a test-plan: the criteria that a person who's trying to follow the list will use to determine if he or she can safely proceed to the next step. It should also include a timetable. Think of a way to record the actual time spent and to capture any comments (good or bad) from the people who completed each item.
As you prepare this list, “the details will come out.” So many details will come out, in fact, that your attention can easily become diverted from the task of preparing the list. Make a separate list of those details as you encounter them. Include that list in your final preparation, so that people can understand your detailed plans in-context.
When “these details come out,” you're already programming. Yes, you are. You're just starting-out on paper. Given that the finished software will have to deal with every one of these details (as well as any that you fail to discover), in far more detail even than this, be as thorough now as you can be.
Track it:
As the project moves forward: time is spent; objectives are met or found to be inadequate; assumptions are proved and discounted; new discoveries are made. Track these things. Every day, keep a chart and a “ship's log.” What may at first appear to be “useless paperwork” quickly proves its value when you refer back to it and encounter an important point that had slipped your mind.

When you embark upon this kind of project, you're either sailing away from your familiar “home waters,” or sailing into stormy seas, or both. You need not be guided entirely by instincts and intuition. Do what you were taught to do when writing term-papers (yuck!) in school ... possibly even including those 3x5 index-cards. The approach still works.

You're sailing into unknown waters, or back out into a sea that's known to be full of rocks, yes. But that comes second. Your first objective is to discover how to discover what's the best course for your team, given all of the prevailing conditions. Don't leave that to guesswork, to hubris, or to chance.