Paper on project without any result - how to conclude

Question

I'm reporting on an engineering project that is in its early phases. Therefore, there are no results, but there is already a quite detailed plan on how the problems in the project can be conquered. Now I was asked to present the project at a conference. I want to present the current state, but I'm not sure how to structure a conclusion as there is no result, and I can't evaulate, if the planned methods will be successful. Still I believe presenting the intended methods will bring value to the community.

How do you conclude a project presentation that doesn't have any results but already has a quite concrete and detailed plan? What content could I provide? Or can one just not provide a conclusion in a paper? That seems a bit unbalanced...

Answer 1

I think the conclusion of a paper and the conclusion of a project are two different things.

In my view, the conclusion of a paper is the summary of the paper while the conclusion of a project is the end results of the project. Your paper has the current state and the future plan of the project. These can be the conclusion of the paper. They are not necessarily the conclusion of the project.

If you don't feel comfortable with having "Conclusion" section in your paper without stating the true conclusion of the project, my suggestion is to write a ""Summary" or "Future Outlook" section at the end of the paper. This is a personal taste, in my opinion.

There are many papers without "Conclusion" section either by authors' choice or the final conclusive results for the problem/conjecture were not obtained yet at the time the paper was written.

Answer 2

What goes into the conclusions section in a paper is a bit field-specific. I am doing research in computer science (services / software engineering), and oftentimes, the conclusions are basically the place where you summarize the main points of your paper. It is not required in my field that the conclusions contain hard data / findings. If the paper is of more positional nature (a roadmap paper, a "Towards ..." paper, etc.), the conclusions will be more of an outlook on the challenges ahead.

Answer 3

The paper is about an analysis that has been performed to address some challenges and fulfill some objectives. The result of the analysis is a plan.

The plan should fulfill the objectives, it should be fault tolerant, it should consider the possible risks that may materialize during the project or it should do whatever it should do and it should be like whatever it should be (I don't know the specific details about the objectives and the analysis).

In any case, the conclusion should be that the plan fulfills the objectives that were set for the design of such a plan. If it doesn't then you should try to do the plan again, because that would mean it's wrong. I guess it's right, that's the main conclusion and that's the reason to publish a paper.

If after the project you find out it was wrong, then that could be a good reason to write another paper. With lessons learned, mistakes, etc. so that nobody else makes the same mistakes (we should make some progress in the state of the art of mistakes as well ;-) )

PD: Future lines are not exactly conclusions, a conclusion is something that ends. Every end implies a new beginning, and thus future lines (imminent beginnings) are included in this section, but let me note they are two different things (and opposite to a great extent).

Answer 4

You could include information about metrics for success, what a solution might look like, future directions, etc. And then the conclusions for the paper would summarize what you presented, rather than what you're going to do.