Classic Projects more powerful than Smart Projects?
This is a question to XTRF, which will likely interest all other Smart Projects users. Quite some times we are being told that the function we are looking for is available in Classic Projects but not in Smart Projects. My understanding has been that Smart Projects is the next-generation version of Classic Projects. It thus is confusing when Classic Projects provides better or more comprehensive project management features than the "state-of-the-art version".
Out of curiosity, is Classic Projects still being developed or will it remain at its current level until it is completely substituted/overtaken by Smart Projects?
Answer
We're still in Classic, due to some key features we need, which don't exist in Smart.
But the signals we are getting is that Classic is being deprecated and there's no point asking for fixes or improvements to Classic, since the effort is focused on improving Smart. Yet, it's been over a year (or two?) and the feature set of Smart still doesn't match what we have in Classic.
Great question, Sancho. I've heard the same and wondered why a lot of current Classic functionality is not available in Smart projects, or at least a good or better substitute.
It would be expected that if smart is to replace classic that a lot of the current features would already be available in smart.
Jaime
I would also like to know that, since classic projects seem to have been abandoned development-wise but Smart projects are still missing essential features.
Do you plan to update classic projects with features such as rolling availability requests?
We use the Classic projects, but unfortunately we also get some answers that some needed function is only in smart projects. Otherwise we think that smart projects are not good for complicated multilanguage projects.
We are new XTRF users that were brought in on smart projects. Initially, we were informed that Classic projects would be phased out for smart projects. However, we were continually told, "sorry, you can only do that in classic projects". (ie, memoSource integration, multiple source language projects...) However, a few weeks ago we were told that they changed their minds on Classic vs. Smart and that they were going to develop them both in parallel.
That left me not knowing if we should consider doing classic projects for some projects and smart for the rest, or just wait and hope for more smart project development (can I please delete an old project please???).
I'd love to get the definitive answer.
@Mark: That is new to me and would have to be communicated clearly to the user community by XTRF. On the XTRF webpage all you see are images of Smart Projects. That would be confusing if Classic Projects is the superior tool for some cases.
@XTRF: Sorry to poke the hornets' nest here, but your clarification is needed, based on these comments.
We agree that Classic Projects interface has lots of great and advanced functionalities and can serve almost unlimited number of complicated project scenarios – at least for now.
Smart Projects were created to provide very easy and modern interface for project management, with focus on improved efficiency, simplicity and user experience. They already allow lots of different project scenarios and more and more Clients use Smart Projects only, even though they do not cover some of Classic Projects functionalities. Of course, we are constantly aiming to close this gap. To adress the shortcomings you mentioned we keep working on performance, better support for multilingual projects, more integrations with CAT Tools, and lots of other useful and attractive features. Although it needs some time, sooner or later Smart Projects would cover all Clients' use case scenarios.
At the same time, we maintain and add minor improvements to Classic Projects though, to allow all Clients transition to Smart Projects when they feel ready. Those whose scenarios are not yet supported by Smart Projects can continue to work in Classic Projects.
I see a lot of benefits in having both smart and classic projects available, and see that smart projects are excellent for the vast majority of projects at least in our case (small, simple, take a document or a package and translate it into one or more languages). We have some problems with the memoQ integration there but I think it will improve. Smart projects are not good if you have multiple source languages, or if the process needs to be planned and designed a lot. The way I see it is that if you have a project where you invoice e.g. up to 200 euros, smart projects should work. If you have a large project and you need flexibility and enhanced function set, classic projects are okay - if you spend 10 hours preparing the project, 10-20 hours reviewing it, DTPing it, etc., then it really does not matter if you spend 10 or 40 minutes doing the administration. I don't think that all the functionality in classic projects should be kept for smart, as feature creep cuts productivity and makes it more error-prone. Where to cut it is a different and tough question...
To me the key to decide whether to use Classic or Smart Projects was the time it would take for PMs to create a project and that we could maintain our KPIs. We performed a 3-step process (translation, editing and proofing) and we tested Smart for three weeks and saw that it took longer to create a project mainly because it does not have the feature to automatically set the start of the next step with the same end of the previous step, nor it kept the project within the established deadline. This was a disadvantage vs Classic. Another disadvantage is that Smart Projects did not record and Actual delivery Date nor and Actual Close date so our reports did not show the projects delivered per Cutomer or PM per month. We also found that it was very difficult to edit the workflow or amounts if changes were needed and that if you forgot to add the language pair and started the project, vendors could not invoice the job. The last disadvantage is that you cannot erase a project once created, so if you are creating projects for training purposes or you accidentally duplicate a project you cannot delete it. Projects Delivered per PM and Customer is one of our KPIs so this was another disadvantage that altered our KPIs. Therefore, we are working with Classic until these issues are fixed.
Thank you all for sharing your thoughts and experiences. We keep hitting walls on the Smart projects but would rather not use the Classic ones (guess we may have to reconsider, though this means more training and documentation have to be implemented on our side). Another problem we´ve found is that projects cannot be hidden from customers in the Customer portal. The test ones we´ve created remain there (I´m not talking about deleting, sometimes we´d like to keep them but toggle visibility for the customer).
The issue that we cannot hide (or delete) projects from customers in the customer portal is a big issue for me. Looks very unprofessional.
We are also hitting a wall with smart projects, but haven't yet spent the time to train our PMs on classic to see if it works better for us. It's a challenge creating a entirely new process. It's as if you have to train on two tools rather than just one.
Customer support service by UserEcho
We agree that Classic Projects interface has lots of great and advanced functionalities and can serve almost unlimited number of complicated project scenarios – at least for now.
Smart Projects were created to provide very easy and modern interface for project management, with focus on improved efficiency, simplicity and user experience. They already allow lots of different project scenarios and more and more Clients use Smart Projects only, even though they do not cover some of Classic Projects functionalities. Of course, we are constantly aiming to close this gap. To adress the shortcomings you mentioned we keep working on performance, better support for multilingual projects, more integrations with CAT Tools, and lots of other useful and attractive features. Although it needs some time, sooner or later Smart Projects would cover all Clients' use case scenarios.
At the same time, we maintain and add minor improvements to Classic Projects though, to allow all Clients transition to Smart Projects when they feel ready. Those whose scenarios are not yet supported by Smart Projects can continue to work in Classic Projects.