Leantime
[FEATURE] Toggle (main) features
Is your feature request related to a problem? Please describe. Leantime is growing fast. Even if all new functions are very welcome, the risk of overloading increases. I would like to decide for myself which functions I use in my company.
Describe the solution you'd like It would be great if I could just disable the features so they are no longer visible. It doesn't matter to me whether the switch is set in configuration.php or in the settings. A controller for each project would also be great.
Additional context Add any other context or screenshots about the feature request here.
Thanks for posting this!
This is something I'm, personally, very passionate about and mindful of -- it goes into every feature discussion on our end.
I think, and hope, plugins will end up helping with this too -- but a toggle sounds like you're thinking in core too.
I think we chatted a bit on it -- (tell me if I'm wrong!)
But just wanting to clarify -- I believe it was around the blueprints specifically?
You are rigth, we talked about this. But it's not only the blueprints. I appreciate the "lean" in leantime. So everything that is not really core to run a project should be togglable. If you share responsiblity in multi-pm, there are pm that are not equal familiar to the multiple options. So I think e.g. about a decision company-wide, what kind of canvas has to be used. Or if there should be an empathy map. Or if we ever use timesheets. Every opportunity to fill something out carries the risk of spending too much time or in vain. Especially when I don't have the experience. And the more complex project management is, the greater the risk of not working with it successfully.
" So everything that is not really core to run a project should be togglable. " I think this is the magic word here. What belongs to the core of a project? There are project management best practices that are needed for the successful execution of the project.
- Project Definition
- Goal Setting
- Risk Management
- Ideation
- Planning
- Execution
- Delivery
- Monitoring/Documentation
In my humble opinion all phases are required to deliver a project successfully. So the question would be: Which features are not needed as part of the core or project management? And as an extension: What happens to project success if you don't do those things? I agree that the blue prints section can be reduced but I feel like the main features are all necessary.
I could be wrong though and I'd be happy to discuss use cases.
@Piepe6213 thanks for following up on that. I appreciate your POV and see you're really leaning into the lean concepts here and call out some really important things.
From the point of lean, having views that would take too long to fill out after definitely anti-the concept.
We've run into a lot of projects being execution focused and then details lost. I like this idea and just want to make sure we're deliberate in mapping it out as I worry, the greater harm may be that people don't do important strategy steps at all -- and that will leave us closer to other systems that focus on execution & monitoring as their primary elements of project management.
Deciding what we need vs shouldn't use feels like a more of an advanced user role. It can be really hard to anticipate when or when you won't need something and we've had projects that the originators never tracked why they made the decisions that they did and then they left. We were left with technology decisions that may not have been made otherwise and at a higher cost with no one fully understanding why. If they had known, would they have documented?
There's always these sayings around it's so much harder to create something simple and it's so true. I'm not sure where the line is yet and we're definitely still investigating it so I really appreciate that here, and on Discord, you've been doing a great job on calling out the simplicity course. Thanks for that.
People are intuitive project managers -- we solve problems, create amazing innovations. We (humans) aren't always great at complexity (which business and team related projects are)... it leaves me asking, "how do we increase the success rates of projects so we can have better innovations all around?" -- Preferably without any added work to the user.
At the end of the day, we have some lofty goals over here of project management world domination where we have people using their intuitive human project management skills but with the best of project management frameworks -- and making it something people want to do. We've got some ways to go still :)
Apologies for the long reply; hoping some of the backstory helps. We're wanting to make sure we find the balance between the advanced user and the user that knows how to get things done but maybe isn't getting the benefits of project management yet.
As I'd put you down as more advanced user, do you have any thoughts on how we might use a toggle in a way that works for your needs but also doesn't fall into out of sight / out of mind? Default to "on" seems natural but I'm not sure that it's preventative enough. Perhaps better as a plugin?
I think we basically have to consider two things here: on the one hand, the project itself and multi-project management.
Let's look at the project itself: what makes a project a project? There is no uniform definition for this. In most companies, criteria are defined as to when a project structure must be used. There are different criteria for this depending on the industry. That's important and right. But that also means that the borders are fluid. The larger, more complex, more important the project, the more elements of project management are likely to be required. And sometimes not. A simple example: In 2018 we had the challenge of complying with/implementing the GDPDR. No other choice. We called it a project, although many things were implemented by external partners and not by us, e.g. no software development. Why should I do a risk analysis, for example? That would be a waste of resources.
Building on this, we come to multi-project management. It's 2023, the speed of change isn't like it was in 19xx, when most project management methods emerged. We have a lot more activities today. In my company there are currently 58 who have made it into multi-project management. Why? Because we have learned that at this level of activity it is important on the one hand to keep an eye on all activities and their interconnectedness. And on the other hand, it is important that people have the opportunity to have an overview of all their tasks (including their interconnectedness) in one place. And not some tasks on the post-it, some in Outlook, some in PM tool and so on.
And so we created a multi-project management system in which we installed 2 very experienced project managers as mentors for the project sponsors. And these two project managers decide which framework conditions must be observed in the projects or activities. For example, whether a risk analysis is required.
Coming to Marcel's list of core elements: the words are another perspective, I look at it more from the side of features in leantime:
- Project definition => definitely core
- Project brief => brief is not core, the information in the brief should ideally be merged with the project definition
- Tasks = definitely core
- Milestones => optional
- Sprints => optional, but that's it
- Docs => optional
- Goals => optional
- Idea => optional
- Blueprints => optional for each variation
- Retrospectives => optional
- Reports => optional (maybe best example for plugins)
In general, however, I would also like to say something about the subject of software. Any software that forces me to do something I don't need or want to do is the next candidate for being replaced by other software. Of course it's always a question of analysis and evaluation, but that's basically how it is.
I understand your principle of offering leantime as a tool for the inexperienced project manager and laying the foundation for successful project management with the functions. But in my opinion, that should not lead to paternalism. Whenever I wrote optional above, for me the ideal state would be:
- activated by default
- deactivate in company setting (to avoid to be used)
- deactivate in project setting (only if not deactivated in company setting)
I hope you are aware of how much I appreciate your work and commitment. And I know that I have no right to implement it. But hey, it's open source, so at least I can give my opinion... ;-)
Please excuse the bad Google translation, translating almost 600 words in my head just takes too long. :-)
I've got to apologize for my delay in reply here -- we've been wrapping up some hectic-ness from last week. But secondly, I need to say that I'm humbled at the time and thoughtfulness you put into your reply. Being open source, there's a wide variety of what we get in input around what we're doing here and when we ask for more information, it takes time from your day and work. The thoughtfulness you put in here is much appreciated and really helped with some of our internal discussions.
For some of your points -- it's interesting how varied the experiences are. When we implemented GDPR at my last employer, it was a huge undertaking. That said, they never used "blueprints" to begin with -- I was implementing my own work briefs for larger projects and post work updates/retro statements.
We started discussing an approach closer to project templates -- so to your point, of certain projects only having certain levels of scope -- seeing all those elements are cumbersome. This was an idea in how to blend both the less experienced user (decreasing cognitive overload) and the more advanced user.
So the thought would be that we could map out the project types that would reliably have these specific elements:
Ex: Personal projects may be how a user organizes themselves but it has no outside input or if so, very specific team members. This user likely doesn't need milestones, docs, retrospectives and I don't know how often people are really looking at their own outputs for reports. Simple task management here might be enough.
So then you would see or create a new project by project type: Personal / Individual Large Initiative (everything) XYZ ABC Custom *Advanced User selects what features are needed
Clearly, I have more mapping to do -- and would take all the help in the world on that; as deciding the criteria is the hardest part -- but it could look something like that. In my own experience, I find the gantt chart most useful on projects with stakeholder/over-lapping department work -- so something that doesn't have that may not need it.
I was thinking this approach could add in some counter balance to a straight implementation but would be open to other thoughts and if this is enough from your end.
@marcelfolaron @TareqK FYI.
Hey Gloria, no need to apologize! We are discussing about features, not saving lives... ;-) If I understand you correctly, your suggestion is basically to implement my wishes, just not in the way I suggested. When it comes to the templates, do you think that you define them firmly or that I can define the templates? I immediately think of a feature matrix to define templates (comparable to user roles)... :-) Hit me if I want too much. I have no idea how much work this is. But I like the discussion! P.S. I'm a lucky guy, I have 5 units between "run the business" and "change the business". And every unit organizes their team tasks with a Kanban board, as well as their personal tasks. Everyone sees this as the best way to organize tasks. P.P.S.: In my career I have never managed to explain the meaning of a Gantt to an inexperienced user. That's why we no longer use a Gantt as a matter of principle.
Hi @marcelfolaron @gloriafolaron . I'm really interested on this. We do have some projects, like internal ones, that they just need a couple of features. For example, we have a sales funnel which just uses the kanban module. Super interesting because we use files and we move tasks from one project to another.
Other solutions, like Taiga or the well known Monday or ClickUp let users decide what to disable.
Not a must, but really interesting.
