In this series, we explore the types of surprises that can derail a project and what you can do to avoid them.
We started with Schedule Surprises. Next up: Solution Surprises.
If you’ve ever been involved in a software implementation project of any complexity, you’ve probably found yourself asking questions like “How is this functionality not out of the box?” or “How can we be the first customer to ask for this?” The fact is, there is almost always something with the software you’re implementing that doesn’t work the way you’d like or even doesn’t do something you want at all.
What makes this even more frustrating is finding out about it at a point in the project that feels too late. How is it you got this far into the project only to find out there is a requirement that the software can’t satisfy – at least without costing considerably more than expected?
Here are the most common sources of solution surprises and what you can do to prevent them:
Poorly Vetted Product
“See how it works. Dig into the details. Ask lots of questions.”
When you are evaluating business software, you should prepare a thorough list of requirements along with a priority rating – something like ‘Must Have’, ‘Strongly Desired’, and ‘Nice To Have.’ As you are reviewing demos, focus on the HOW of each of your Must Have requirements. Don’t take the vendor’s word for it that their software meets those requirements. See how it works. Dig into the details. Ask lots of questions.
On one of my projects, my client learned that the software I was implementing for them didn’t have a feature that the client considered critical. Later, I asked a colleague for advice on how he handles that situation, and his response was, “I ask them what they saw in their demo before they bought the software.” Of course, they didn’t bring it up before they bought – they made an assumption. If you’re not being diligent about documenting your Must Have requirements, this can easily happen.
After you’ve selected your software, your implementation team will need additional requirements to configure or customize it to support your business process. Here again is another opportunity to miss requirements. Good consultants will have a way not only to capture your main requirements but to tease out the exceptions and hidden scenarios that are easy to forget. Good consultants will also help you identify how to improve efficiency or areas of your process that are based on limitations of your old software, but that’s another topic.
Here you should insist on thorough documentation of your requirements. This can be a tedious exercise, but as they say, hope is not a plan. Just because your consultants have assured you they understand your requirements does not mean you should believe them. And once you have documentation, you should pour over it carefully, thinking through what is missing, inaccurate, incomplete or unclear.
This doesn’t mean you can or should freeze all requirements early in the project, or that your implementation can’t be iterative. But catching problems with requirements that can be caught early in the project is much cheaper and much less frustrating than catching them later.
Lack of Testing
The worst time to find out your solution is incomplete is after you’re live. Sadly, this happens more than you might think. We see this most often when people assume everything is simple. The requirements are simple, and the software is simple, and after all, how hard can it be? So rather than testing thoroughly, they run through a few scenarios and assume everything is fine. The problem is when the new system is in production, and the real world of your business is not always so simple.
To avoid this, recruit as many people as you can to test, test, test. Some people are natural testers – they enjoy it, and they think of scenarios others don’t. If you know who these people are, pull them into your project!
Just as important, you should have a good way to document your testing activity. It not enough to hear from testers that they completed everything. Make sure each test result is clearly documented, and you retain all the testing documentation. Good test documentation will include who the tester was, when they tested, the steps they took and the details of their results.
“Incompetence can come from anywhere…“
So you’ve vetted the product, documented requirements and tested thoroughly. Yet, you still are faced with bad news in the project that it’s not going to work for you after all – at least not without spending more money. The most likely cause at this point is inexperienced or incompetent implementers.
Incompetence can come from anywhere – internal employees, consultants from the vendor or 3rd party consultants. Even with the best of intentions, sometimes people are in over their heads. A good implementer won’t necessarily be able to tell you how every last feature works in perfect detail. These days, a lot of software is just too big and complex for any one person to recall every detail on command.
Here are some things to be on the lookout for to make sure your implementation team won’t steer you off course:
- Trust but verify. Start with trust, but ask for details. You can ask questions like “What are our options for this feature? How does it work?” The idea is to gauge their familiarity with specifics of the product you’re concerned with. If you’re not satisfied with the answer, be sure you ask for follow up quickly to get a good answer. If you don’t get this, escalate with their manager. You should have confidence in your implementor. That said, it’s not helpful to treat every interaction as a new round of interviews. If your implementor is demonstrating competence and following through on commitments, you don’t want them feeling anxious about working with you. This can lead to them hiding things and making matters worse.
- Know who you’re working with. Understand the background of those on the implementing team and their roles on the project. It’s common to have a mix of more experienced consultants along with new consultants. Not every task on a project requires a lot of experience. However, you do want to make sure the more junior team members have enough resources to address more challenging requirements. If your primary contact isn’t giving you enough confidence, ask to speak with their more experienced backup and understand their role on your project and their time commitment.
- Plan for iterations in the implementation process. Whether you’re using an agile process or some hybrid, software is made better by working on it iteratively. Not only do you benefit by reviewing the software as it’s being configured to help you provide feedback, but you have an opportunity evaluate the quality of the product and team relatively early. If your testing isn’t going smoothly, and you suspect it’s in part due to the competence of the implementers, it’s better to know that early so you can do what you can to bring in stronger resources.