It can be tempting to create a very simple test environment where every accountholder has a checking account, a savings account and an auto loan on a fancy sportscar. The problem is, testing in this kind of environment will never catch any fringe cases – odd combinations that for whatever reason become problematic.

Your best bet is to use a broad cross-section of real accounts –scrubbed, of course, of all PII. Will you catch all the fringe cases? No. Will you catch many more fringe cases than testing with plain vanilla test data? Yes.

The bigger the tech project, the more third-party vendors are involved. Think, for example, of how many different vendors, all working in concert, make up your digital banking experience.

It’s imperative that you notify all affected vendors as early as possible of what’s going to be required of them. You also need firm scheduling commitments from every single vendor. You wouldn’t want to delay your digital banking conversion because the lead tech from your e-statement vendor went on vacation.

The core people on your project team understand the importance of providing timely, detailed feedback and they act accordingly. However, you need to remember that many of the people working on the project have other responsibilities that take priority in their lives.

It’s your job to make sure those people understand the importance of their feedback, however minor it may seem to them. Nobody wants to delay a big tech project. Everyone just needs to understand their role.

Most major tech projects require some sort of data dump from one or more vendors. In the case of a digital banking conversion, for example, your new vendor needs data from your old vendor to make implementation as smooth as possible.

Even if your new vendor has experience converting institutions from your old vendor, you can’t assume there won’t be any issues. Sample data dumps are critical. And as the steward of the entire project, it’s on you to make sure all data ends up in the right hands at the right time.

What you think your institution needs at the outset of a tech project is very rarely an exact match to what you realize your institution needs by the end of the project. That’s just a fact of life in the digital age. However, there’s a fuzzy line between tweaking things to make sure they’re right and insisting on everything plus the kitchen sink.

Keep a firm grasp on the difference between “must have” and “nice to have,” the difference between “need it at launch” and “need it in six months.” Most important of all, engage your vendor in constant, productive dialog. Remember, your vendor wants exactly what you want, namely a successful implementation that everyone can be proud of.