Custom object to replace OOTB Idea object - not advisable?
I work with a customer who has the need to change the Idea object. The problem with the OOTB object is that it has some functionality that they don't want to use like 'submit for approval'.
They do want to have the possibility to convert to project these 'new' Ideas through a custom process. But I think that without the 'Convert to project' button it will have to be converted through an action item.
Is this possible? I have read some posts about converting objects to projects but I do not understand why XOG is involved in order to have the mapping code that the process steps requires when converting to project.
Maybe I'm mixing different concepts so this is why I really appreciate your thoughts on this matter. I know it's not a good practice to create a new custom object to replace the OOTB Idea object, so I would really prefer to have the chance to custom the OOTB Idea object without the 'Submit for approval' button.
Hi Flo. I'm gonna pick sides with 'Not Advisable'.
1) This is a fiduciarily irresponsible decision. Translation: That's an expensive path to commit to. You're throwing out all the money CA & others have committed to what's already been matured in the tool and committing to building it all yourself. There are hundreds if not millions of dollars of functionality (Demand Management & CRM views, Reports & Portfolios, etc) built around Ideas. If you choose to 'go it alone' and create a new object - you throw all of this out. It's worth the effort to weigh the pros and cons of this. Example:Clarity 13.2's OOTB Portfolio Management feature. Would the organization benefit from seeing the Demand in Ideas stacked in with the 'committed' work in Projects and evaluate what to work on through what if analysis? Clarity 13.2's Portfolio Management features do this. If you choose to forgo the Idea object - you lose all this good work. Same goes with other reports, portlets, processes, etc. If you go it alone - you're alone. You've committed to building it all yourself and this is expensive. Isn't not building a PPM system yourself why you bought a COTS system?
2) This too shall pass. When we got off the ground with Clarity, an executive leader asked to scrub the word & all functionality around Approved from the system. "We're a cost center funded by our customers! We don't approve anything! We're purposely funded to do this work!" Technically... not incorrect, but a little hung up on semantics. Welcome to the coaching moment. Ask people to remain curious and take the long view. We now use 'Approved' as a very important state in the system and have new functionality upcoming that will make this even more important (Much out of the box functionality does too.). I'm glad we sat in the pocket and took the hits on this one. Take the time to try to understand the value in a feature and trust that it's probably been thoroughly 'field tested'. When questions arise, use forums like this for answers or to bounce ideas (like you just have!).
The Process: OK - the above is subjective opinion. Now let's look at the objective process you will kick off.
2) List the pros and cons of each (classic 'build vs buy') and be prepared to put dollar values with them.
Stay Curious! - Run the above process.
I've networked with institutions that have custom Portfolio Management objects that integrate with their other enterprise systems that do *exactly* what they need. The OOBT Portfolio Management features don't provide them value - this is OK. 'Pros' land on 'Custom' for them on this.
We do not use CA's Status Report sub object & surrounding COTS stuff. We were off the ground before theirs came into being and have greater functionality. This we value ($$). 'Pros' land on 'Custom' for us on this.
You may find your new, custom 'Idea' is right for you. All I ask is be prudent, take a fudiciarily responsible long view and base the decision on a fully vetted bake off.
This has been successful for us. Hope it helps you as well.
Have you thought of creating a standard project (use it like an idea) and have a process flow for approval ?
Hello NJ, the customer is already using the project object and I have also suggested to use the same object for their ideas, since after describing how they want the ideas to work, were the same as the project object does and like they are using it currently. But they want to have the ideas separated from the projects and they do want to convert them after some actions and status changing.
Thank you very much for your advise. I'm not convinced myself on following this path, most of all because the reason why the customer plans to create a custom object to replace the Idea object is only because the 'submit for approval' button 'confuse' the users.
I really appreciate all the pros and cons you have detailed, I think that it will make sense for the customer and I hope to convinced them to stay with the OOTB Idea object, they are planning to use reports and I think portfolio mgnmt as well in a near future.
P.S: just in case you might have approached to something llike this before, is it possible to remove the 'submit for approval' button? Someone from Support has told me that maybe I could try that at VXSL file level, but of course I have never been there before... just wanted to know if someone tried it before. Thanks!!
1) Follow the idea Support gave you. Work with CA Services or a 3rd party vendor to modify the app to remove the button. This of course will have an initial expense and a recurring 'care & feeding' expense of the maintenance through patches and upgrades.
2) Create an auto start action on the Idea that automagically submits the idea for approval upon create, thus making the button disappear. I just did a quick test. The button is on the first screen after the user clicks 'new', but after the first save & navigate the process kicks off, automatically submits the idea for approval, then the button is gone from all screens for the idea from this point forward. This is in the box today, is fully supported and doesn't cost anything other than 10 minutes of time to create (notwithstanding testing, training, documentation & support - but you'll have this on whatever you do).
Now that I think about it, even if you did implement #1 you'll still need the auto submit process anyway. Start with prototyping this & see what you think.
Thanks Rob! I'll try your second option, I was thinking about something like that and I think customer will agree with it!.
This is just such a great response, that even though it is four years on I've got to give this an upvote because it is still relevant and helpful. I must have re-read this half a dozen times.
And of course this advice is not restricted to CA PPM - you see the same concerns with any large software implementation where terminology and processes collide.