What is right for 1 team/project is not necessarily right for another team/project. A major deficiency in my opinion.
by: Jim S. | over a year ago | Administration
Completed
Ability to configure projects using different methodologies. (e.g. 1 project Scrum, Second independent project using XP)
by: Jim S. | over a year ago | Administration
Copyright © 2025, Digital.ai Software, Inc. All Rights Reserved
Comments
It would be unusual for an organization to agree to manage their projects with different approaches, but an interesting point.
Our organization has projects with very different needs, and this may require different approaches. Everything in V1 should be configurable per-project.
What changes would you envision?
For me - I'd like to be able to Configure the fields differently for different projects. We have project teams and technology teams who use slightly different fields and drop-downs e.g. Status - The project teams have far more status transitions than the technology teams. At the moment we need to have ALL the status field drop-downs available for both project types. I'd also like to be able to switch off fields we're not using in one project but are in another. Again you have to have all the fields visible even if you don't use them.
I can go either way with the methodology differences, but it seems like a no-brainer that you should be able to have project-specific customizations. My company has a tech side and a non-technical side that is making the transition to agile. Some of the language adopted by the tech side in the system is hard for the non-tech side to adopt. If we could have project specific customizations, V1 and agile adoption would probably be made much easier than it currently is.
Different departments, each doing their own separate projects in our organization use different terms for priority levels, status, type, etc. I can see where having separate fields and lists for each project would be quite useful.
I disagree that it is unusual for an organization to use multiple approaches. That may be true of very small organizations but this is supposed to be a scalable, enterprise level tool. I also believe that many of the configuration items need to be configurable on a per-project basis. This is currently a hindrance to widespread acceptance of this tool within our organization.
This item would get many more votes if we could change the title of it. It should be "ability to Configure the fields differently for different projects" or "project-specific customizations". So, I agree with Toni, Andre, Kathy and Mike above (the previous 4 posts). I need this.
This idea is related, but broader: https://ideaspace.versionone.com/default/Idea/Detail/140
I support the need for project-specific customizations, so long as you don't lose the ability to have global configurations. If I have to make a change to 20 different projects, that would really irk me.
This is an issue which is forcing another development team in our organisation to consider a seperate installation of VersionOne with their preferred set of statuses which are quite different from ours.
Lots of good points here. This is now something we are looking into more along with some of the other configuration-related ideas. The comments here seem to point to more general flexibility between project setup without (as John points out) forcing additional overhead when not needed. This is helpful input for us as we move down this path.
I noticed WIP limits are set per project. This doesn't work well if two teams are working under the same project. OR if one team is working on two projects. Why two projects? We have one project for "sustaining" work (patches) and another for "new release". Just something to think about and make this more complex :-)
Project Workspaces can be created as of the Summer '10 release, allowing flexible configuration across projects.
More info: http://community.versionone.com/Release%20Notes/ReleaseNotes2010Summer.aspx