Don't Try to do Everything at Go-live
When implementing a new AMS, there is a tendency to try to get everything done and "in the system" prior to go-live. After all, you've got this shiny new system with all kinds of new functionality. Why not go for it and have it do everything it can and have that all happen at go-live?
There are plenty of reasons not to do that, but one important one is this: The more you use the system, the more you'll know it and understand it, and the better your decision-making process will be about adding new features and/or processes.
For example, a client of mine was trying to decide whether or not to pay for some customization on their AMS to better manage fundraising. The baseline functionality was "just OK" but the client wanted more. After a long discussion about whether or not to pay for customization, my client said "How about we use the baseline functionality for now and see how it goes. Maybe we'll learn more about how the system works as we use it, and we'll find a better way to do it without having to pay for a customization."
Wise words!
It's literally impossible to know everything about your new software when you go-live. You will always learn more as you use the system. So as you make decisions about what should be available at go-live, consider those things that might make more sense to implement after you've been live with the new system for a while.
Even though it's new and shiny, not everything has to be ready at go-live.
![]()
Wes's Wednesday Wisdom Archives
MDR (Minimum Data Required)
MDR (Minimum Data Required) I’ve written about minimum viable product (MVP) in software development in the […]
Simpler and Faster is Better
Simple and Faster is Better Earlier this week I was fortunate enough to attend a […]
Patience and grace
Patience and grace A past client of mine recently told me: “You inspire confidence and […]
Sometimes you just have to try it and see what happens
Sometimes you just have to try it and see what happens The single greatest key […]
Training and testing
Training and testing I’ve written before that the best form of training follows this process: […]
How to save a “failing” project
How to save a “failing” project It is not unusual for me to receive a […]
How to avoid the “IT black hole”
How to avoid the “IT black hole” Going all the way back to my days […]
The “People” are important!
The “People” are important! I’ve written a lot about people, process, and technology over the […]
Always look for the MVP
Always look for the MVP I first wrote about minimum viable product (MVP) just three […]
The longer you take, the longer it will take
The longer you take, the longer it will take It may sound like a tautology, […]
