S
My employer is implementing a new EDCMS. What we did was to create an abstract list of our bottom-line requirements, our really-nice-to-haves, and our gee-we'd-like-these-features.
Once we had that list, we were able to match solutions to requirements and figure out what was best for us, and not just what was "best" in a generic sense.
You need to do a proper requirements definition document, and many posters in this thread have listed a number of requirements that you should consider. I don't really have a lot to add to that list (and I'm grateful to the people in this thread who have posted those requirements).
What I would like to add is that it is crucial to distinguish the true requirements from the nice-to-haves to manage the scope/expense/schedule involved in implementing a system, and I strongly recommend involving more than one person in the requirements definition process if at all possible, so that you don't get too attached to your personal take on what your requirements are.
I'm part of a team who did the requirements definition, and thank goodness for that, because the others on the team were able to recategorize some things I had considered necessary as nice-to-haves. I would have missed that, and we would have added expense, functionality, and delay to the implementation. Since we're a non-profit, we really manage our bottom line as tightly as possible.
Since EDCMSs can be expensive and complicated, managing the requirements effectively before you commit to a solution is crucial. Make sure not to miss any requirements, but make sure to avoid categorizing desired features as requirements when you can avoid it.
Oh, and if you choose a system that requires customization from the out-of-the-box version, get agreement on the requirements of the customization clearly documented and agreed-upon by both your company and the company performing the customization. And don't just do it at the start of the project, but keep refining the customization specifications in writing as the project progresses. Get sign-offs whenever possible.
And if you can work with the customizing team to develop and adapt acceptance test criteria as early as possible in the process, you'll have a smoother development process.
I am in constant communication with the vendor who is customizing our system and I am testing preliminary versions of the system already, and we are capturing a lot of the potential problems early in the process. We are unquestionably reducing the effect the problems could have had in terms of scope and price and schedule, and we're over a month away from implementation. It is 100% worth the time to focus on that communication if you're customizing.
Once we had that list, we were able to match solutions to requirements and figure out what was best for us, and not just what was "best" in a generic sense.
You need to do a proper requirements definition document, and many posters in this thread have listed a number of requirements that you should consider. I don't really have a lot to add to that list (and I'm grateful to the people in this thread who have posted those requirements).
What I would like to add is that it is crucial to distinguish the true requirements from the nice-to-haves to manage the scope/expense/schedule involved in implementing a system, and I strongly recommend involving more than one person in the requirements definition process if at all possible, so that you don't get too attached to your personal take on what your requirements are.
I'm part of a team who did the requirements definition, and thank goodness for that, because the others on the team were able to recategorize some things I had considered necessary as nice-to-haves. I would have missed that, and we would have added expense, functionality, and delay to the implementation. Since we're a non-profit, we really manage our bottom line as tightly as possible.
Since EDCMSs can be expensive and complicated, managing the requirements effectively before you commit to a solution is crucial. Make sure not to miss any requirements, but make sure to avoid categorizing desired features as requirements when you can avoid it.
Oh, and if you choose a system that requires customization from the out-of-the-box version, get agreement on the requirements of the customization clearly documented and agreed-upon by both your company and the company performing the customization. And don't just do it at the start of the project, but keep refining the customization specifications in writing as the project progresses. Get sign-offs whenever possible.
And if you can work with the customizing team to develop and adapt acceptance test criteria as early as possible in the process, you'll have a smoother development process.
I am in constant communication with the vendor who is customizing our system and I am testing preliminary versions of the system already, and we are capturing a lot of the potential problems early in the process. We are unquestionably reducing the effect the problems could have had in terms of scope and price and schedule, and we're over a month away from implementation. It is 100% worth the time to focus on that communication if you're customizing.