Start with your existing documentation
A project often begins long before someone opens a project management tool. Its goals may be described in a customer brief, its constraints in a contract, and its practical details in meeting notes, spreadsheets or technical documentation. The document-to-project direction in ABOLTUS is designed around this starting point: use the material your organization already holds to prepare a structured proposal for the work ahead.
You would select the relevant documents and define the scope of the project. The planned process would retain their versions and source locations, helping the team see which information belongs to the current proposal and which questions still need an answer.
Turn source material into a proposed project
The intended output is a draft project organized around the goals, requirements, deliverables and constraints supported by the selected material. Proposed tasks and work packages would connect those requirements to practical steps. Responsibilities and deadlines could be carried over where the documents state them explicitly, or added by the team during review.
Missing information should become a visible question. If a document describes an outcome without specifying a measurable target, the project should record that gap for discussion. A suggested estimate, dependency or owner must remain distinguishable from something already agreed in the source. This makes the draft a useful starting point for planning.
Keep every requirement connected to its evidence
A requirement is more useful when the team can inspect its origin. The plan connects a proposed requirement to the relevant paragraph, table cell or saved excerpt, including the conditions and exceptions needed to understand it. A short sentence can depend on a qualification elsewhere in the document, so preserving context is part of the intended workflow.
People would review the proposed interpretation and approve a specific version. Open questions and conflicting statements would remain visible. This gives the project a record of what was accepted, who accepted it and which documentation supported the decision at that time.
Understand what a document change affects
Project documentation continues to change after planning begins. A revised specification may affect several tasks, an acceptance condition or a previously approved decision. ABOLTUS plans to use explicit links between sources and project items to identify the parts that may need another review.
The proposed workflow would show the changed evidence alongside the affected requirement or task. A responsible person could then decide whether to update the project, keep the existing agreement or request clarification. Historical decisions would retain their original basis, allowing the team to explain how the current project version developed.
Connect the plan to acceptance and results
Creating a task list is only one part of building a project. The implementation direction also connects approved requirements to acceptance criteria and the evidence used to check them. Depending on the work, that evidence could be a reviewed deliverable, a recorded inspection or a test result associated with the relevant version.
The aim is to make progress understandable: what was requested, what work was planned, which checks were performed and what result they established. If a requirement changes, an older successful check may need to be repeated. The project should make that relationship visible to the people responsible.
An example: preparing a customer delivery project
Imagine a team receiving a customer brief, a service proposal, a technical specification and meeting notes. The intended workflow would bring their requirements into one draft project, link each proposed item to its source and identify differences that need clarification. The team could review the scope, agree responsibilities and define what successful delivery means.
Later, a changed specification could lead to a focused review of the affected work. This is an illustrative use case for the planned functionality. Its value would need to be measured through the time spent preparing the project, the quality of the resulting requirements and the effort needed to keep it current.
A development direction shaped by real projects
Creating projects from documentation is a distinct ABOLTUS development direction, grounded in the project's document research and implementation plan. The planned approach begins with reliable sources, saved excerpts and reviewed relationships, then builds toward project proposals and change tracking. The wider platform is in development; this website does not upload documents or create working projects.
If this matches your workflow, register your interest and describe the documents you start from, the project structure you need and the decisions that currently take the most effort. Those concrete situations can help guide useful pilot scenarios.
Bring your working documents into the conversation.
Tell us about your use case and the result you need.
Register your interest Explore CRM from documents ↗