What do you do when researching for a project?

Question

I'm about to undertake a personal project, but I'm having trouble coming up with background information in the problem domain. I have some experience, and Google has provided me with more, but I'm still not sure that I have all of the information I need. If you have ever been in this situation, either at work or on your own, what did you do?

I see three options, but I might be missing some:

1. Go with what I have now and let everything unfold.
2. Keep digging for information and maybe turn up something new.
3. Put the project aside for a while, until I have more information.

Answer 1

I try to split the project in multiple part and start to make them one by one. When I figure that I have a problem that I can resolve, I ask question on a forum or here.

Example, if you have a project with a new framework and a new database and a lot of http request (let stay it's new for you), and the need of doing all in ASP when you are usually doing all in Winform... I would create a little project to test the framework, a little project to test the database and a little project to test the http objects... etc. Once I get a part more confident with me, I would create the "real" project and add slowly every parts.

Answer 2

It is not totaly clear to me what kind of project your are talking about.

Here are some more things you can do in any case:

• pick three 'experts' in the field, show them your draft and ask for feedback
• don't rely on google solely, do offline research and scan scientific databases
• create a mind map which will most probably show you some more gaps and clarify your mental representation of the problem
• draw a use case digramm

Answer 3

Find someone who does know that domain and ask them for advice / help / mentoring.

Answer 4

why don't you try the Big6 steps:

1. Task Definition
   • 1.1 Define the information problem
   • 1.2 Identify information needed
2. Information Seeking Strategies
   • 2.1 Determine all possible sources
   • 2.2 Select the best sources
3. Location and Access
   • 3.1 Locate sources (intellectually and physically)
   • 3.2 Find information within sources
4. Use of Information
   • 4.1 Engage (e.g., read, hear, view, touch)
   • 4.2 Extract relevant information
5. Synthesis
   • 5.1 Organize from multiple sources
   • 5.2 Present the information
6. Evaluation
   • 6.1 Judge the product (effectiveness)
   • 6.2 Judge the process (efficiency)

Answer 5

"If you have ever been in this situation, either at work or on your own, what did you do?"

I can't imagine not being in this situation. Everything that involves custom software has to be new and different. Otherwise it's a download and I'm not involved.

Since everything -- to me -- is new, here are my coping strategies.

1. Find the stakeholders -- folks who are (our would) pay to have something done. Get goals and an overview from them. If I can't get goals or an overview, then I stop, I'm done.

2. Interview the actors -- people who actually do the task (or would try to do the task) now. What are their goals? [Do they match the overall goal given by the stakeholder?] What are their means to achieve those goals? How and when do they do things?

3. Locate the information (possibly the things) that actors manipulate. Get an instance of each one. Things that don't have tangible artifacts have to be simulated. A handshake or a conversation -- while nice -- doesn't exist unless it's memorialized in some way.

At this point, I should understand how the actors interact to do (or create) something of value. If I haven't found the interactions, or it doesn't match the overview, I stop.

Notice, however, that I don't know everything. Indeed, I don't know much. But I do know what people will be doing, and how they're like to be doing it.

The next step is to prioritize the use cases. Everything is not of equal significance or importance. Some things matter a lot. Other things don't matter at all. Some are present problems to be solved, others are future considerations.

For the top priority item only, then dig into details. Then move to the next item. Then the next. Get details for each the use cases in strict priority order until I've done enough.

There are two parts to enough. The passage of time and the priorities. This is a time-boxed technique. There's always more details. Rather than hand-wring over everything. Hand-wring until time has run out. If I do things in priority order, I've got the most valuable stuff done.

Answer 6

Most personal projects are about the doing, not about getting it exactly right. Why not assume that you understand 80% of the problem and start. As your project progresses plan to elaborate further. Make sure you design is flexible enough and compartmentalised so making changes doesn't mean throwing it all away.

The other option is to build a prototype and plan on throwing it away. However in the work and personal world most of these prototypes become version 1, and your future code base.

Answer 7

Is the information mission critical? If so then make sure the effort of learning it is worth the value of the project to you. In fact, make sure that the value is twice the effort to be sure. Also absolutely positively do not do the project because it gives you a chance to learn the information. If you do it for that reason, then you will never finish the project or learn the information.

Whatever information you have to up, if it is large, then do not even start the project until you have picked up the information. If it is not large, then split the project between progressing on other fronts and studying. Focus on the project and when you have a pause in the project use that spare time to study.

Answer 8

Thomas, as others have noted you do not specify whether you try to improve your grasp of the problem domain, technical feasibility of solutions or whether a proposed solution is going to “work”. I will try to address all three.

Researching Problem Domain

The goal here is to understand the domain, frame the problem, its importance within the field, impact of the proposed changes and get access to and support from the domain experts. As a result the definition of the task itself may change entirely.

• Befriend some domain experts. I am always surprised how enthusiastically people share their knowledge with these who are genuinely interested and how easy to establish an initial contact. Moreover, if users are affected by the problem you are trying to solve it is more than likely that their help will extend beyond simply explaining what is involved.
• Spend a day in the field.
• Take good notes: rich pictures, mind maps, workflow diagrams, write short scenarios.
• Keep a domain dictionary.
• Collect artefacts.
• Try to get some historic perspective of the domain: how and why did it evolve to its current state and what changes are going on now, where it is likely to head.
• Make regular effort and time to analyse all information you have collected. One of the more usual ways is to extract domain specific nouns and verbs. Nouns are objects of the domain, verbs are actions associated with these objects. These will help you figure basic objects, their relations and tasks common in the field.

Researching Feasibility of Solutions

The idea here is very simple: you might already have a number of possible solutions and you need to understand as early and with as least effort as possible any problems (technical or otherwise) you will not be able to tackle. Even if there is a problem which is very hard to overcome it might be worth making an attempt to solve it. Again, this may lead to a complete redefinition of the task at hand.

• Write down things you are not certain are possible or feasible.
• Mark items that are critical for your solution, i.e. give each item an impact rating and an estimate of research effort needed.
• Prioritise the list with high impact, low effort issues first (you want to know if the solution is not going to work as quickly as possible).
• Work the list proving the concept, keep adding to and replacing things on the list as you discover more.
• Keep a list of alternative solutions; regularly take time to re-evaluate both lists item by item.
• Obviously, you can delegate some of the research, by asking questions to relevant experts or expert audiences.

Is It Going to “Work”?

Here you want to foresee users’ reaction; again the definition of the task might be refined significantly in the process of discovery.

• Trust your common sense.
• Consult with domain representatives.
• Try to come up with as many reasons why it will not work as possible (Ishikawa diagrams are very useful here; they are also referred to as “a fishbone diagram”). Address these possible failure modes.
• Sometimes you need to build an entire solution and let it into the wild just to understand if it is “working”. If you feel this is the case adjust your strategy appropriately and plan the first version to include only “must haves”. Consider a limited pilot of the initial version to iron out most significant hiccups.
• Try to gauge the impact of your solution and the change it brings. Who is likely to oppose the change and who to support it?
• Look at the way solutions evolved within the field. Is yours a revolution or an evolution?
• If it is a revolution consider what effort will be required for users to adopt the change (financial, training, existing arrangements and investments) etc. What are you going to do to cushion the transition?
• If it is an evolution is it appealing enough for people to switch?
• How fast do you expect for your solution to propagate? At times it takes years of continuous sales effort.