Plans for 2017
Things to look for from us in 2017.
Transitioning to software as a service only offerings. We currently have 3 partners who have on-site implementations. That number is shrinking to 2 in the new year and moving forward we do not plan to continue to offer on-site implementations to any new adopters. We’ve found that on-site implementations drive the cost up significantly and are far harder to manage. The work we’ve done with you has dramatically improved our offerings to the point that on-site is no longer cost effective. We say this because our over-arching goal is to drive costs as low as possible for all our users and to do that we need to limit costs here which hosted environments allow us to do. If you’re a current on-site customer not to worry, there will be no change for you although we may try and entice you to join us in the future.
Reduction in maintenance costs. We are working hard to get all current client customizations into the base code. What does this mean? Once a customization has been adopted into the base code all annual maintenance costs will be terminated. This is another “what’s good for us is good for you” approach to driving down cost. Having to support a single platform makes it far more cost effective for us so we plan to pass those savings along to you. The good news for those who don’t have customizations is while you won’t be saving money you WILL be getting the benefit of those customizations as they’ll now be available in your FastTrak environment thanks to your colleagues. Just to put your mind at ease, all new enhancements will be turned off by default, so no impact to you unless you choose to turn them on.
Our new approach to upgrades. Building on the last statement, the approach of parameterizing added client customizations will be adopted for all new enhancements we deliver. This will allow us to keep everyone on the same version and roll out upgrades with no impact to you. Only in a case where we are adding new modules or making changes to the system infrastructure (such as workflow, security, notifications) will require our traditional approach and these should be few and far between.
Infrastructure plans. This has been a goal we’ve been working towards for some time now and our hopes are we will make strides in 2017. We want to change the workflow engine to make it much more user friendly, allowing for administrators to easily modify their workflows, add new ones, and apply them to new processes. The plan is to provide a graphical, drag and drop type of interface. We want to make changes to security as well. Currently the security infrastructure is a bit bulky and we feel we can improve on it, speeding the application up, improving the way roles are applied to people, and providing a more user friendly interface. Finally, notifications. Currently the system delivers multiple types of messages (notifications, alerts, letters, etc.) all of which are based on XML which requires modification by Moderas to change. We feel this needs to be modified so that administrators can create and manage these documents through a WYSIWYG editor, allowing you to manage your own notifications.
Managing workload in FastTrak. We’ve been thinking about this one for a while. The first step was to come up with a way of calculating the weight of a proposal (the proposal complexity formula). We completed that a while ago but haven’t yet wired it into FastTrak. The goal would be to weigh each proposal so that when you are looking at assigning a proposal coordinator you can see just how loaded they are. For example you may have one coordinator with 3 assigned and another with 10, one would think you should assign the new one to the person with 3 but it may turn out the 3 are more difficult to manage than the 10 if you can see their weight. Jamie form Toledo had a great idea as well. It would show how many proposals are due the same week as the one being worked on so you could see that picture quickly and easily. Phase two would be something we’re working on with our partner Attain. Evan Roberts, from Attain, has some ideas about showing loading for reviewers as well. Basically a loading by when proposals and other documents are expected to hit a person’s desk in advance. More to look forward to as we move through the new year.
New way of entering data. As you are all aware the biggest hurdle to new implementation is “getting the data in”. Adding people, permissions, units (departments and colleges), organizations, contacts, sponsors, etc. is critical to getting an environment up and running. To date this has been mostly an import process that requires some IT and Moderas support and often delays our progress. Our plans are to change this, allowing all users the ability to add new data directly into fields. For example, if a user wants to add a person to a proposal and they don’t exist already in the system, they’d have the ability to “add new” entering the basic profile information for the new user such as first name, last name, and unit. If the person entering them is an administrator they would be active immediately, if they are a standard user a notification would go to the appropriate administrator(s) allowing them to modify, replace (if a duplicate), and activate them. Once activated (in the case of a new user) they would be sent an invitation to complete their registration adding things like the default security roles, degrees, training, phone number, etc. to their profile and getting their new password.
User management. Currently user management can only be performed by an administrator and that’s something we want to change. We want to put this control into the hands of the users themselves since they’re the best source for this information. This would allow them to update their contact info, training, delegates, etc.
SingleIRB. With the new requirements for using a single IRB for multisite protocols being enforced in April of this year we’ve released a new stand-alone product to support this (www.singleirb.com). It’s a simple application that’s easy to use and we plan to develop integrations so that it will work seamlessly with the FastTrak IRB module as well as deliver API’s or other integration approaches for adoption by other IRB vendors as well. Why would we freely share this with our competitors? The focus of SingleIRB is communication between Reviewing and Relying institutions so integrations with as many systems as possible would significantly enhance this which is what’s best for our users. We hope other vendors will see this as a benefit and choose to integrate, providing value to their customers.
These are the big things on our plate as we currently see them. Please let us know if there are other things you think we should be focusing on, if you feel any of these should be less important than others, basically what you’d be working on if you were us. We value your feedback, I know everyone says that but we actually mean it. We’re not successful if you’re not successful and none of us can succeed without strong communication.