Table of Contents
Money loves silence; that axiom is especially true when it comes to the delicate matter of project budgeting. In the #consulting industry, especially in software implementation, it’s common for neither party to know the budget upfront. The nature of our trade implies tight competition, price dumping, unrealistic expectations, and other fun stuff created to keep us in shape all the time.
Best case scenario: an experienced client estimates the budget, and then an experienced provider makes their corrections, but they initially agree on the scale of the disaster.
Worst case scenario: an overconfident client underestimates the complexity while their greedy provider is taking advantage by inflating the project cost.
The best that both parties can do is to run the discovery phase together — that’s the only way the mutual expectations could be met.
Deceptive Simplicity of the Software Implementation
If It Was That Simple, You Wouldn’t Be Reading This
At the most physical layer, setting up Zoho CRM or, to broaden our example, any other software looks somewhat simple. There’s a person who clicks some checkboxes, wandering here and there across the settings and writing a piece of code from time to time. People call them “developers” or even “programmers,” but that’s just one side of the coin. The other side of the coin tells us that before one clicks an option or writes a custom function, one should know precisely why it is a good (or bad) idea. In other words, one should understand the business’s processes and the rationale behind them to implement anything. In the software implementation business there is no well-defined boundary line between the business process design and pure IT skills. The frontiers of one blend with the outside limits of the other, and this is why you need a team.Â
Nota bene: a "pure developer" mindset often isn't enough for implementing the software. One must think from a business process perspective, so the multi-faceted skillset that comprises business thinking and platform-level experience is a must. Most of the time, the software implementation process is teamwork. E pluribus unum, if you wish. And remember, even two people are already a team.
And yes, there’s another point of frustration for many customers. It can be a bitter twist of fate when a system that looked so simple suddenly becomes overwhelmingly complex — well, because it is complex, and so are your processes! Business isn’t a simple chore. Nearly 1 in 5 U.S. businesses fail within the first year. You, the business owner, already made it so far: you have brilliant employees and looking for a software to automate your processes.Â
This leaves you with a daunting challenge: either tackle the task of setting up Zoho or risk your business stagnating or worse. At this moment, you realize that you need professional assistance. Your next step is determining who can assist you and how to pay them.Â
Many entrepreneurs still percept the software implementation as a trivial process that can be executed within a month for the lesser price that some chain stores pays their greeters. By mentioning that, I am not saying that the store greeter trade is diminished in comparison with the IT people. Not at all: store floor greeter is a tough job, but that job is strictly quantifiable.
Nota bene: it isn't a metaphor. According to Glassdoor, in 2022 Walmart used to pay $25/hour for its greeters in Chicago. At the same time, any marketplace is full of software implementation jobs from U.S., Canada, and even Australia, offering $5-10 per hour.
But regardless of the hourly rate, the greeter’s presence on the store floor can be easily measured in hours. The hourly rate dilemma takes a different turn in the software industry.
The Curse of Purchased Time
Why You Shouldn’t Use Hourly Rate in Implementation Projects
In most scenarios, people only think they want to pay hourly. Truth be told: they want results and presume they can quantify the time needed to deliver these results. The reality is a bit more complex.
The whole paradigm of buying X hours to deliver Y results stems from the employer-employee relationship model, where one party sells a quantifiable amount of time in exchange for some fixed hourly rate. It presumes that the employee will be productively occupied 100% of their billable time, and sometimes it sparks the control measures like clock-in/out timers, time tracking software, and in most sick scenarios, even the automatic screenshots. But the client-provider model is a whole different thing.Â
For instance, when you bring your car to the shop to change the oil, it will spend some time in the shop’s possession, even though the oil changing procedure takes approximately 30 minutes on average. You will meet a few people: a receptionist, a service rep, and a cashier. However, you’ll never see an itemized bill that includes their time: you paid for the result in the form of oil change, and you’ll be billed precisely for that. It’s not the customer’s business how many people were involved and how exactly.Â
Nota bene: selling and buying time instead of outcomes always leads to a misalignment of incentives.
Still, the hourly rate is king for most jobs with quantitative metrics. Blue-collar, white-collar, hipster-pants jobs — the hourly rate rules supreme wherever the employer can measure the time and when the deliverables are a simple function of effort and time spent. It falls ideally into the waterfall model: get hourly rate, estimate the hours, and have the budget done. Sounds great as long as the initial estimation is correct. But what if it isn’t?
One of my customers once mentioned that they “ran out of hours” with their previous provider and decided not to pay them anymore because it took longer (read “became more expensive”) than they were expecting. It’s a textbook example of why bringing the employer-employee relationship model to the project-based business is a bad idea. If they had a fixed project budget divided by the small sprints with a flat-rate cost, it wouldn’t happen.
Nota bene: you always get what you pay for. When you are paying for time, you will get the time. Aim to buy the results instead.
Factors and Actors
What to Consider
In harsh reality, more or less precise estimation of efforts can be given for the processes with predictable factors and actors. The aforementioned physical labor is a textbook example: if I have a shovel and can dig at the constant pace of X CFT for Y hours, my supervisor could easily estimate the cost of digging a hole of a specific size. Sounds like a plan… as long as we are sure there is no concrete underneath the top level of the soil.Â
If we expand this metaphor into the software world, our brave digger can encounter a concrete slab, a bomb, and a Shai Hulud — all at the same time. This is why the discovery phase is a must for any implementation project. It takes considerable effort to bring all the parties on the same page — metaphorically and physically, in the form of a business process map. And yes, this is a billable time.Â
Another major factor to consider is the sheer market variability that has existed in the IT world since Sir Tim Berners-Lee introduced the World Wide Web. As long as people can work remotely, there’s competition between the providers situated in different economies, and it opens access to a broader pool of talent. These talents often operate on significantly different budgets. It is especially true for the marketplaces like UpWork and Fiverr, where an abundance of supply creates an illusion that one can automate a business with 200+ employees, seven branches across the country, and a turnover of $10-15M a month for the cost of a ten year old, low-end car within one month.Â
Nota bene: set realistic expectations and remember that today's business automation is complex. If that was simple, you wouldn't be reading this.
In 1903, the Wright brothers were self-taught geniuses and achieved splendid results. In 2023, would you fly a commercial airliner with a captain who just came from his bicycle shop? It doesn’t mean that the Wrights were thoughtless. It means that the world has changed.Â
Zoho Implementation Cheat Sheet for Clients
Pretty Simple Advice That for Some Reason Few People Follow
Here’s what I’d recommend — customers who are doing this are the most successful, both in terms of the implementation results and business overall.
- If you have time and want to cut some corners — don’t hesitate to contact Zoho support. Although support is not created to be your “free implementation team,” it can be helpful to answer your questions — if you know how to ask the right ones.
- Shop around. Create a short list of Zoho Partners you like for any reason and talk to them. Zoho offers a convenient interface to search among the registered Partners. Usually an hour-long meeting is more than enough to see if it is a match.
- Don’t limit yourself by time zone. It’s totally OK for a Chicago-based customer to work with a Partner in Seattle.
- Do your best to describe your goals. It helps everybody to understand where you are right now and allows your potential providers to see if they can help. After all, you know your business better than anyone else, don’t you?
- Don’t perceive IT work as “virtual” and cheap — it is not. Your business software platform is a nervous system of your business. If it doesn’t work well — nothing else will.
- Make sure that all parties involved understand the project’s complexity before you sign anything.
- Always sign a contract for any project with a budget bigger than you are ready to lose forever — a Master Service Agreement and a Statement of Work will reduce your risks. No, the NDA alone isn’t enough.
- Do not make presumptions like, “I know it’s only a few checkboxes; I just have no time to do it by myself.” It creates a false sensation of presumed simplicity on both ends.
- Consider using the Agile methodology. There’s no way on Earth to determine all the circumstances during a single discovery meeting. Leave some space for maneuvers for both yourself and your provider.
- Trust no one unless an agreement is signed.
- Whenever possible, do not reinvent the wheel. Sometimes it is better to change your processes than make a two-week effort only to do something that goes against the platform architecture.Â
Now, thank you for taking the time to read this! I’d love to hear from my readers, potential and existing customers, and the fellow professionals. Please feel free to comment over here (the form is below) or at LinkedIn.Â
