Wes’s Wednesday Wisdom

Don’t ask for what you don’t need! Recently I received a bill from a doctor’s practice. The bill provided a website for paying online. So I went to the website and the first thing it asked me for is my account number. This is good because the bill they sent me has my account number on it. […]

It is never done – so celebrate! A client of mine recently had their official “go-live” with their new AMS. On the day after go-live, my client said “I still have a whole list of things to do. We’re not done at go-live, we’re just getting started!” And she’s absolutely right! There is really no

MDR (Minimum Data Required) I’ve written about minimum viable product (MVP) in software development in the past. MVP means getting the product out into the market with the least amount of features, in order to get customer feedback and to just get something out there. A related concept in data management is minimum data required (MDR)*. The purpose

Simple and Faster is Better Earlier this week I was fortunate enough to attend a session at ASAE’s Annual Meeting entitled “No Analyst, No Problem!” presented by Bailey Kasten and Meagan Roloff. Their session was essentially about creating data visualizations on a shoestring budget. They presented several “case studies” of how they took relatively complex

Patience and grace A past client of mine recently told me: “You inspire confidence and calmness which people need when going through an AMS transition.” This got me thinking about two behavioral attributes that I think are absolutely critical to success when going through any major technology transition: patience and grace. Technology transitions, no matter

Sometimes you just have to try it and see what happens The single greatest key to happiness in data management (and life!) is to seek success and not perfection. A corollary to that could be “Try it and see what happens.” Part of my work with clients is helping them make decisions about business rules and business

Training and testing I’ve written before that the best form of training follows this process: Tell them what you’re going to do, tell them what you’re doing, tell them what you did. When working with your software company to report bugs or other issues, you should follow a similar process: Tell them what you were

How to save a “failing” project It is not unusual for me to receive a call from an association that sounds something like this: “We implemented a new AMS in the past year, everyone on staff hates the new system, and this whole project is failing. What can we do to save it?” While every project

How to avoid the “IT black hole” Going all the way back to my days as an association staffer (more than 30 years ago) I’ve encountered what I call the “IT black hole.” The IT black hole is where technology issues go to die. Perhaps you’ve experienced this. You report an issue to your technology staff

The “People” are important! I’ve written a lot about people, process, and technology over the years. This is the three-legged stool of success for any technology project (and these days, for any project at all!). My writing has focused mostly on process and technology because process and technology are usually easier to change. But I