For the bulk of my career, I’ve been in the technology field. And the past decade I’ve focused on Salesforce, working in a wide array of industries: from finance to energy, retail, healthcare, manufacturing, to nonprofit, and a whole lot more.
One thing that bridges my experience no matter who it was for, or what industry they were in, is that there are projects that go smoothly, and projects that don’t.
I’m a consultant (that nasty four-letter word), and I would like to share with you some observations that I believe drove those successful projects to be so. And while my firm’s focus is on Salesforce.com and integrations with Sage Intacct, these principles apply to just about any technology project your organization may embark upon.
1. This is your project we’re taking part in.
Realize that you are ultimately responsible for the success of the project. Yup, I said it. You can hire the most expensive, acclaimed team of consultants this green earth has to offer, and the project can still fail.
It’s ok to let the consultant lead the effort and drive the process, but it will take a commitment from you to get your team on the same page, garner buy-in, and drive a constant vision for success. Your consultant should be able to expertly configure/customize/integrate your systems, but when the project ends and your consultant moves on to the next engagement, you have to own and run with the system, and ultimately live with it.
2. It’s a two-way street.
I’m going to say something that may make it harder for my firm to win new deals, but I would much rather have a realistic set of expectations up-front.
Your responsibilities don’t end after the kickoff meeting.
There will be points in your project where members of your team may feel like they have two jobs—one being the normal day job, the other providing critical inputs into the project. There’s no end to what this can mean, but to give you some ideas, you may have to chase down people or departments to get answers to important questions, or spend days, weeks, or longer combining and cleaning data (more on that later).
3. Define what success means to you.
Before you engage a consultant, map out what you want—what success will look like. I can’t tell you how many times we have been approached about an engagement where the client says something like, “I just want our systems to work.” While we all want that, that very vague notion is impossible to convert into success.
And on a related note, we all want our systems to be “user-friendly.” I promise you that your consultant wants to deliver a “user-friendly system” that “works.” But in order to deliver both of those, you have to be able to articulate what that means to you. Yes, your consultant should leverage their experience, ask good questions, and help you along the path, but you have to provide a starting point and fill in the gaps.
4. Don’t be afraid to make decisions.
I have seen projects delayed and delayed and delayed because it’s easy to get stuck in analysis paralysis. Every project needs an Executive Sponsor that makes the final decision when there are differing opinions. Nobody wants to make a wrong decision, but making no decision is often as bad, if not worse than making no decision. While there are some decisions that can paint you into a corner, or be costly to undo, it may be more detrimental in the long run than standing still.
5. Crawl, walk, run.
In some ways this ties into the previous thought, but with some distinction. One of the best projects I worked on had an Executive Sponsor who’s guiding principle was “we can’t go backward.” That was it. As long as we weren’t taking away from what they had before, it was considered progress.
Don’t get me wrong, there was a wish list a mile long (probably closer to 10 miles long now that I think about it). And it was so refreshing to work with someone that understood the mantra “don’t let perfection be the enemy of good.”
If you have to have everything on day one of phase one you’re never going to go live. It’s more than ok to break a project up into phases— crawl, walk, run.
6. Get buy-in from the top.
You’ve seen me reference a project’s Executive Sponsor. Regardless of whether that person is an executive or not, or they are different people or groups of people, or they’re one and the same… a surefire way for a project to fail is go into it without the top brass’ full support.
Adoption is critical to the success of any system, and if the top of the organization isn’t fully on board and believe themselves in the goals it should accomplish, I’ll guarantee that, in the end, the lower ranks won’t use it.
Buy-in can be demonstrated in many ways: it’s incredibly powerful for the staff to see their leaders using the application themselves and running meetings using its reports and dashboards.
7. Your data is YOUR data.
But I’m not talking about possession of your data—of course you own your data, it’s yours—I’m talking about taking ownership of the data. No one knows your data like you do. When it’s time to migrate data from your legacy application to the new one, it’s your job to make sure that the data is clean: accurate, complete, and free of duplicates.
Chances are that you don’t want your consultant making the decision to merge records that will result in loss of certain information—data can be nuanced. For example, one client I worked with years ago needed to track a particular customer as both an individual and a company. If I had been asked to take charge of their data, I would have spotted this as a clear duplicate and merged the records. Not good.
8. Don’t expect an order taker.
A good consultant isn’t a “yes man.” A good consultant processes input and requests from a client and draws on their experience to guide the project to success. Sometimes we see requests from our clients that aren’t in their best interests or could cause problems down the road. And we let them know in uncertain terms what the realities of projects like these are. Don’t be surprised or offended if your consultant pushes back and/or suggests alternatives.
Polite push back is often the mark of a great consultant.
9. Test, test, test.
I’m not saying that your consultant won’t or shouldn’t test things on their own—they absolutely should. But that said, it’s easy to get myopic about something you build on your own. Forest for the trees and all that.
Additionally, sometimes we find that a client’s requirements aren’t well defined (revisit number three above). You need multiple eyes reviewing what has been built with volume to ensure the system is production-ready. Client testing and data cleanliness are hands down the most frequent cause of delays in a project’s launch.
10. Expect bumps along the way.
“This ain’t rocket surgery.” But it kind of is. Anyone that tells you the entire project will be smooth sailing either hasn’t had enough experience in this space, doesn’t have a real understanding of what you need, or worse, is just straight up lying. Let me be straight with you: these projects are difficult. Any kind of technology project worth doing involves a lot of change. Processes have to be discussed, documented, and often times refined. Every software application on the planet has its warts and you’re almost certain to find some sort of limitation or something that doesn’t work exactly the way you expected it to.
To my consulting brethren, what would you add? Clients, what do you wish we knew?
.jpeg)