In our recent live OpenProject demo and Q&A, you asked us about everything from resource and portfolio management to migration, integrations, wikis and permissions. We were happy to see that we could answer most questions positively. But the session also highlighted something equally important: sometimes OpenProject solves a familiar use case differently, and sometimes the answer is simply “not yet”. In those cases, your questions and use cases are valuable input for the further development of OpenProject.
Here are some takeaways from the session, together with resources to help you find the right solution for your own use case.
Quick navigation:
- Start with what you want to achieve
- Look at the use case, not only the feature name
- “Not yet” is valuable feedback too
- Your questions also tell us what we need to explain better
- Keep asking us how it works in OpenProject
Remarque
Interested in joining a similar OpenProject webinar in the future? Take a look at our current webinars here.
Start with what you want to achieve
Many of the questions we received started with a simple “Can OpenProject do this?”: Can I structure work hierarchically? Can I use templates for recurring projects? Can I link work across projects? Can I plan resources across multiple projects? Can I manage a portfolio?
In many cases, the answer was simply yes. But rather than going through a long list of features, we recommend starting with the problem you want to solve. OpenProject combines different modules and features to support complete project management processes, and often several capabilities work together to address a particular requirement.
Our OpenProject use case guides are a good place to explore this. They show how OpenProject can be configured and used for specific project management scenarios.
For example:
- Resource management: Plan capacity and allocations, work with skills and availability, identify conflicts and balance workloads across projects.
- Portfolio management: Create visibility across projects and initiatives, evaluate them consistently and support strategic portfolio decisions.
- PM² and PMflex: Support the methodology throughout the project life cycle with roles, phases and phase gates, artefacts, project logs, meetings and reporting.
The questions from the webinar also help us see where existing functionality may need to become easier to discover. If someone asks for something OpenProject already supports, that is valuable feedback for our Product, Documentation and Marketing teams as well.
Look at the use case, not only the feature name
Some questions were framed around functionality people already know from Jira, Microsoft Project, Confluence or other tools. And this is where “Does OpenProject have exactly the same feature?” is not always the most useful question.
Image: During our live Q&A webinar, we presented the comprehensive OpenProject feature set before discussing individual use cases and questions.
A good example is Microsoft Project migration. OpenProject does not provide a direct .mpp importer. But if the actual requirement is to move existing project tasks into OpenProject, there is a path: Microsoft Project data can be exported to Excel and transferred using OpenProject’s Excel synchronization. For more complex migration scenarios, the OpenProject API provides additional possibilities.
Another example is BI and reporting integrations. One participant asked about an entity relationship model for the OpenProject database. For integrations such as BI and reporting, we recommend using the documented API rather than connecting external systems directly to OpenProject’s internal database structure. This provides a supported integration layer while allowing the underlying data model to evolve as OpenProject develops.
A third example is knowledge management. OpenProject has a built-in project wiki for keeping documentation close to the operational project. For organizations that require a broader knowledge management platform, OpenProject can also be integrated with XWiki. The two systems can complement each other instead of trying to provide exactly the same functionality.
The same principle even applies to projects themselves. If a project is operationally managed in another system, it can still be represented as a lightweight project in OpenProject with the information required for portfolio management. This makes it possible to create a consistent portfolio-level overview without requiring every project team to manage all of its day-to-day work in OpenProject.
The takeaway is simple: start with what you need to achieve, then look at how OpenProject approaches that use case. The implementation may be different from the tool you are used to while still solving the underlying problem.
“Not yet” is valuable feedback too
We were happy that we could answer most questions during the webinar positively. But naturally, there were also requirements that OpenProject does not currently cover. Those questions are particularly valuable to us.
One participant, for example, asked whether individual fields within the same work package could be visible to some roles but hidden from others. OpenProject already provides extensive roles, permissions and workflows, but this particular level of field-based visibility is not currently available.
There was, however, already a feature request in the OpenProject Community addressing role- and group-based configuration of work package fields. After the webinar, we added the participant’s use case to that feature request.
The question therefore did not end when the webinar ended. It became additional input for an existing product discussion – and that is an important part of how OpenProject evolves.
From a question to a feature request
If you need functionality that OpenProject does not yet provide, the OpenProject Community is the place to share it. Our guide on submitting a feature idea explains how to get started.
First, check whether there is already a feature request covering your requirement. If there is, you can vote for it. But we particularly encourage you to add your own use case.
Why? Because a feature title can only tell us so much. Two organizations may ask for what sounds like exactly the same functionality while actually trying to solve quite different problems.
When commenting on a feature request, it helps to explain:
- What are you trying to achieve?
- Who needs the functionality?
- How do you handle the use case today?
- What would a useful solution need to enable?
This context helps us understand not only how many people are interested in a feature, but why they need it.
Votes and use cases provide important signals for our Product team. They do not automatically determine what will be developed next. Product strategy, technical dependencies, maintainability, available resources and the potential value for the wider Community also play a role in prioritization. But the more we understand about the problem behind a request, the better informed our product decisions can be.
So if a feature matters to you: vote for it, and tell us why.
Your questions also tell us what we need to explain better
There is another possible outcome when someone asks about functionality they cannot find: it may already exist.
One example from the webinar was PM². OpenProject can already be configured to support PM² and PMflex throughout the project life cycle, including roles, phases and phase gates, artefacts, project logs, meetings and reporting. We have a detailed PM² and PMflex use case showing how the methodology can be implemented with OpenProject.
Questions like this are valuable feedback too. Having functionality is only part of the job. You also need to be able to find it, understand it and see how it relates to the problem you are trying to solve.
That is why questions from users and prospective users are useful not only for our Product team, but also for our Documentation and Marketing teams.
Keep asking us how it works in OpenProject
That may be our biggest takeaway from the webinar. Sometimes the answer to “How does this work in OpenProject?” is “Yes, and here is how.” Sometimes it is “Yes, but the approach is a little different from what you may know from another tool.” Sometimes the feature is already being expanded on our OpenProject roadmap.
And sometimes the answer is simply “not yet.” In that case, understanding what you are trying to achieve can be the beginning of a valuable product discussion.
This exchange is particularly important to us as an open source project. OpenProject does not evolve in isolation. Feedback, real-world requirements and discussions with our Community help us understand what organizations need from their project management software.
Want to explore further? Browse the OpenProject documentation and our use case guides to see what is already possible. If you have a specific question about OpenProject or want to see the software in action, take a look at our upcoming OpenProject webinars and join us for a live session. And if there is something you need that OpenProject does not yet support, learn how to submit a feature idea and tell us what you are trying to achieve.
Thank you to everyone who joined our live demo, asked questions and shared their use cases with us. Keep the questions coming. They help us understand what you need – and help us make OpenProject better.
