"It is not the strongest of species that survives, nor the most intelligent that survives. It is the one most adaptable to change." - attributed to Charles Darwin (for the quote investigators among us, no, there is no evidence Darwin actually said these words - but it will do for our purposes here).

"A process of change in a certain direction" - Definition 2a of Evolution - Merriam-Webster dictionary.

Sustained change is a long running process, progressing roughly in a single direction, with many side tracks and dead-ends to retract from. Sustained change, therefore, is rarely revolutionary - where many things are fundamentally changed at once - as too many of those will lead to inherent roadblocks in dependent processes, causing the whole system to collapse.

What truly baffles me is that we all know this, yet we still embark on large business transformation programs, hoping that our efforts to direct sustainable change in this revolutionary process will actually work (this time).

We learn in small increments

When in school, we do not start with complex calculus, trigonometry, or elemental particle physics as the objective of the whole course from the start. It starts simple, adding, subtracting, then multiplying, dividing, and so on. Not every pupil will go into the field of particle physics, or quantum mechanics; they will adjust their course along the learning pathway. Why is it that in business transformations, we expect the "Big Bang Miracle" of transformation, when in reality, these are very rare, and even more rarely conducive to a successful outcome?

Revolutions do not bring in the Utopia - evolution does bring progress

Our history is riddled with revolutions, and never has one ushered in the promised utopia. Same for digital transformation - a revolutionary approach (change everything, change it fast) simply has too many moving components, it is impossible to rule out the unintended consequences... worse, it is all but a guarantee that this is exactly where you'll be mopping up the mess after the revolutionary approach.

In conclusion

Small changes allow the team to see rapid incremental progress, while keeping the steps small enough that they will adopt the changes more naturally.

Small changes also allow for mistakes to be made and corrected quickly - it is easier to adjust the direction when small increments are delivered and tested in practice, as opposed to a large transformation with a significant delivery at the end of the project.

Finally, small changes allow for smaller teams working on them - the larger the teams, the less productivity you get out of them (Price's law: the square root of all people in a domain, deliver 50% of the work).

Small and steady increments of good stuff is better than a giant leap into greatness.

The key word in Digital Transformation is not digital - digital merely refers to the enabler - it is transformation. This post is not advocating whether you should jump aboard this train - you will determine the timing that is right for you. The objective of this post is to make us all look more critical at those that are claiming to be experts in delivering Digital Transformation, and charge accordingly. Some are doing fantastic jobs, and many others have not succeeded in putting a meaningful transformation in place at their own company. Especially when companies get larger, the mantra "we are totally transformed" usually holds no water in practical reality.

Cool or Kool-aid?

Digital business platforms, the 4th wave of industrial revolution, digital transformation - it is hard to escape these terms. We may well be on the cusp of the 4th wave of industrial revolution - but I would hesitate to call this out before the event. Let the historians judge us. For now, let's focus on what is actually practiced, versus what is preached.

Let's take a moderately large to very large company offering this "digital transformation" services. How have they transformed themselves? Would the credibility be impacted if they have actually not transformed anything themselves? Just moving an application to the cloud, does not mean you are doing anything different. Just having a new tool, does not imply a different way of interacting. Some examples: Uber has significantly impacted the personal vehicle transportation industry. Their model? Not to employ, but to match demand with supply via an app. The taxi industry has followed by adding applications to book a taxi, but the model itself has not really changed. Similar with the music industry. Spotify has put a model forward where you can listen to (almost) any music from (almost) anywhere, for a flat fee per month (equivalent to the price of 1 CD per month). The rise of streaming services saw a decline in music piracy, which in turn caused a decline in music sales. Cool, right?

Now for the Kool-aid - Uber and Spotify have yet to turn a profit. Is their model flawed? Inevitably - otherwise, the market would reward them with profitability. But that is not to say that they don't have any value - the question is, can companies like these, or their successors (I can't help but think of the adage: "the pioneers get the arrows, the settlers get the land") transform the business model further into a profitable one?

The Product Factor

Back to the issue at hand- how can you trust your digital transformation provider, if they actually have not transformed anything themselves? Case in point - an IT systems vendor claims that with their software and platform, you will be more collaborative, have real time data insights, and you can respond to the market with agility. The same vendor provides you with pricing that locks you in for a year (agility?), and proposes a three year "transformation program" that is executed in a "waterfall" method. For this project, the traditional project pyramid is constructed, with lots of people doing lots of things - but you will not see the benefits until the first (or second) release is in production - usually after a year. This is how we have implemented business software for the last three decades. Why? Because the traditional business software is so complex, with so many interlinked and interwoven functionality, you cannot just simply turn it on.

It is difficult to imagine that using the same product features (yeah, we moved them to the cloud - big deal) will bring about such never seen before transformation.

If your service provider still operates with separate project files, and excel files to "collaborate and communicate", it is difficult to imagine how they are going to bring about transformation to your business.

The Service Bench Factor

Service providers make money when the "bench" is cleared. As they primarily invoice time, an hour not billed is an hour lost. The delivery of product is less relevant to the service provider's bottom line. Capacity drives the solution - not your business. To put it in other words, sales people sell what is available. 

It also is an incentive to do the project as it is always done - scare prospective clients with risk, and pad the project with resources to mitigate this risk. Just like space in your cabinets in your home - it does not matter how much you have, it always finds a way to fill itself. Projects are no different, tasks have a way to consume the time that is allotted to them.

With the availability of tools, and the enlightenment of collaborative and iterative delivery, it is difficult to justify the lack of change here.

Be the Transformation you Sell

I hold the belief that you should drink your own Champagne - if I buy a car, and see the car salesmen drive a different brand than what his dealership sells, I get suspicious - doesn't he believe in the product? Why is the car he sells me good enough for me, but not him? Same with software companies. If you are a vendor delivering an ERP system to your clients, but don't use it yourself... well... what does that say about the system? Too hard to implement? Not easy to use?

I am proud to say that my entire business runs on Zoho. And Zoho runs on Zoho. As such, I have no problems recommending it to my clients, as I know how it can work for their business, as it works for mine.

But that is not all.

It is not just the product - Zoho One has the ability to truly transform the software applications market. It is a comprehensive suite of products to run your business, without the complexity. You can implement it in small steps, iterative with benefits delivered in an almost weekly frequency. As such, I have decided to go along with this disruption (the commoditisation of business applications), and change the way that services are delivered. This is paying dividends.

The model is based on the premise "teaching how to fish" - meaning the client builds confidence and competence in the solution - where the consultant is not doing the work to them, but with them. Where possible, with the client's appointed super-user at "the wheel".

The second change we have made is the method of delivery itself. Instead of long term releases with all features packed into them, we offer first a brief analysis of the business capabilities in a capability map, and appoint potential solution components to these. Then, on a weekly basis, small, but with measurable impact, features are delivered to the users. This increases adoption, reduces the demand for training (small features are easily adopted), and decreases the implementation budget by 50% to in some cases even 80%! It can be done - it should be done. If we want to truly commoditise the business applications, it should be simple and relatively inexpensive to implement - with rapid value delivered to the customer.

Go and ask for a quote for an IT solution delivery, and the first thing you get asked is: "What is the scope?" Seems fair - if you want to get a price commitment, you will be asked for a functionality boundary. But what does this actually do to the delivery of your solution? Nothing good, I'm afraid. You have exchanged uncertainty and risk for limitation and disappointment. How? And more important, how to prevent this? Read on.

How scope creates a prison

In the traditional project delivery, where the solution is a complex set of features with many interdependencies, setting a scope is essential. As a customer, you get some clarity of the functionality you get, and as a vendor you get some understanding of the cost and effort it takes to deliver that functionality. However, simply because there is nothing better, does not make it a good system. Just look at the number of projects that go "over budget". There are many articles written about Scope Creep - the worst kind of creep you can have on any project. But is it?

Consider that the customer does not always know what is being asked. Typically in these projects, the delivery is a much newer solution, newer technology, than what the customer already uses. The further along the project, the clearer the delivery becomes. That is a problem when the scope is set at the beginning of the project.

It creates a prison for both the customer and the vendor. From the vendor's perspective, the scope is the MAXIMUM delivery as agreed with the current budget. Ask the customer, and then the perspective is the MINIMUM features delivered. If you were to draw a Venn diagram, the circles only intersect at one single point - no room to maneuver.

Scope on a Time and Material Project? - we need to talk

There are two main contracting mechanisms in a traditional waterfall project. Time and Material, and Fixed Price. Other machinations, such as Time and Material Cap, and Flexible Scope are nice inventions, but they create more problems than they solve.

Engaging on a Time and Material project? You have to understand what you are buying. As the name implies, you buy time... and material. In other words, your bill constitutes of the time spent by your vendor, and cost made. Regardless of what has been delivered - A statement of work is the initial guidance to the focus of delivery effort, not a contractual agreement to what will be delivered against what cost (typically, you do not see the cost or time budgets in a Statement of Work for a Time and Material project - at least, not if your vendor knows what they are doing).

Why we are convinced it is not a game

First of all - it just isn't fun. That is just a matter of perspective. Some like strategy games, others love a first person shooter, and then there are those that love the simulation games, and so on. So, I am not going to say: "Of course it is fun!" - as personally I don't find any computer game all that entertaining, I know it comes down to the basic elements of learning, and motivation through progress.

That brings us to the second, and possibly the biggest obstacle with regards to the gaming analogy: it isn't easy to learn, and mastery seems unattainable for us "mere mortals". Only the anointed few (the solution architects and principal consultants) can ever master the implementation of such behemoth of complexity.

There is some truth to that statement - in particular if your software is built on older (read: ancient) architecture, and the design stems from the 80's and 90's from the last century (in business applications, that is analogous to opening a library and deliver your books in clay cylinders filled with cuneiform script). If the last two decades have brought us anything, it is simplification - a simplification that has been enabled by more powerful computers, and more recently, the onset of Cloud. Simply said, the cloud commoditises software - all software. What does that mean? It means that all software is on a trajectory to become easier to implement and easier to use.

Strategy and implementations

What is key to every strategy? Execution. And the key to effective execution? Measurement to adjust. Now this is fundamental to every game, from the very simple shoot 'em up like the good ol' Space Invaders - to the more complex and interactive world of World of Warcraft. How do we know we execute well? We tally the score while playing. How do we know if the strategy is sound? We measure our progress towards the desired outcome - and see if the score is predictable along that path. For example, in chess, you keep score on the number of chess pieces captured and lost - but you track along your strategy if this is according to your plan (i.e. you expected to sacrifice a piece, versus an unforeseen action that resulted in an unexpected loss).

But before we measure our progress, it is very important to realise what the actual objective is. And this objective has to be unequivocally clear with all actors and stakeholders in your project. Typically, these outcomes are all defined differently - the project owner wants the functionality on time, and on budget, the implementation partner focuses on the scope line-items and budget, and for each actor there are different interpretations of "functionality" and "scope". The objective of the implementation is the outcome that needs to be achieved - whatever that measurable outcome may be (more customers, saving costs in the supply chain, increasing inventory turnover by x%, etc).

Shared outcomes make allies out of adversaries

By having a shared objective that is outside of the scope of the delivered functionality, the entire project team has the opportunity to collaborate to that desired outcome. The objective of the implementation is achieving that outcome, or to reach a state that both parties agree is satisfactory (i.e. the additional time and resources required to get to the "perfect" state are outweighs the incremental improvement against the current achieved state). The "Statement of Work" no longer is the guiding document - the delivered features are adjusted based on the measurements of incremental progress.

Key takeaways

I have been in the business of implementing business solution for over 25 years. During this time, I have been amazed at two things: 1). the incredible speed of innovation in this sector, and 2). the incredible inertia of silly requirements that keep us from utilising these innovations. No - this is not an advocacy to just blindly implement whatever shiny new thing that is concocted - I am merely implying that a number of the requirements put up are designed to maintain the status quo - intentionally or unintentionally. Typically, the technical restrictions of the current solution become the most restrictive requirements of the new. Read on for tips how to recognise this.

Where do I put the horse?

Imagine, late 19th century, at the onset of the invention of the Automobile. What if the requirement to be able to harness a horse was maintained? We now know that this would be completely unnecessary, but if the concept of the Automobile is completely new and alien to you, it is a reasonable assumption.

Do you have any "harness" requirements?

Culprit no. 1 - Finance

For the uninitiated, finance is the area where magic happens. Somehow, the finance department makes sense of all the operations of the business, and quantifies that neatly in a profit and loss statement and balance sheet. For sure, you don't mess with that! However, not all requirements are affecting the production of the statements and reports required to run a business - some are just... there to keep things running as they were for years.

Example - booking time in 10 units per hour

Those that are booking time, in the "old days" did so in 6 minute units. This is driven by the invoice not dealing in time, but units (base 10 instead of base 60). With the introduction of actual time sheets, that are able to capture actual time (either as duration, or as a from - to record), it is now possible to capture actual times, and these are converted to base 10 units in the invoice (yes - in most systems, you can set 6 minute intervals in the conversion). And what was a requirement at an organisation I did some work for a while back? You guessed it: we do not accept writing time sheets in actual time, please modify this to reflect our 6 minute units...

Example - operational reporting from the general ledger

Before the 1990's (yes, integrated systems have been around that long), the financial system was used for reporting, and the operational systems (as far as they were not paper-based in the organisation) were used to drive the process. Both financial and operational reporting had to come form that one system that had all the data consolidated into one reportable database. Before a decade ago (or so), creating reports was quite complex and expensive. Since the turn of the millennium the complexity and costs have gone down considerably, and now it is almost "end-user" work to create meaningful reports out of multiple data sources. Yet, in quite a few organisations, there is a very complex ledger structure, split out with a ledger account almost on product and customer level (I have seen an organisation with a general ledger containing 21000 ledger accounts, split by customer(!)). The cost and complexity to map all ledger accounts to operational activities is significant - it is also highly error-prone requiring regular reconciliation verification activities. In modern (anything from the last 20 years, really) systems, collating financial and operational data into a meaningful report is considered a given - yet the requirement for such detail in ledger setup remains at some companies.

Example - after-the-fact purchase approvals

Every company needs to control the purchases and bills. Especially when the systems are not integrated between finance and operations (see above - operations used to be mostly manual), a purchase invoice needed to be verified prior to payment. With the onset of integrated systems and approval workflows (mid-2000's), any invoice that comes into the business is either an expected non-purchase invoice (i.e. utilities), or the purchase order is somewhere in the system. These orders are pre-approved as a purchase, and in case of a physical good, matched to the receipt of the product (so-called three way matching - where the invoice, the receipt, and the original purchase order are matched for consistency). It makes little sense for these purchase invoices to go through a separate workflow yet again prior to payment, increasing activity (cost), complexity, and a delay in paying suppliers (supplier relations). Instead of separating the unexpected non-purchase order related invoices from the pre-approved invoices, many times I see companies adding the double workflow on the purchase invoice for approval for these expected invoices. The outcome? 100% approved, or if there is a rejection, it is due to a discrepancy found in the three way matching.

A new system is not "magic"

New software systems enable a more streamlined and efficient process. That implies that it facilitates doing things differently. What no new system can do is make a convoluted, outdated, and inefficient process work smoothly. It actually costs you more money in implementation, and modification of the system, to make it adapt to poor processes. It is a fallacy to expect a new system to bring in the process utopia, when you do not change your process.

How to establish the true nature of requirements

In most cases, the list of requirements for a new system is composed by people that know the current system (because they use it). It is therefore not a surprise that the requirements read like a summation of activities performed with the current system, plus a wishlist of things that would make it better. Often you hear the phrase "at the very least we want all features we have now, plus some more". Given the old system has been in place for 5 to 7 years (or sometimes even over a decade), and the rapid innovation in the business application space, it is no surprise that requirements tend to hold you back in the status quo.

Here are some steps to establish the true nature of your business requirements:

• instead of compiling the list what people do, establish what outcome they need to achieve
• for each outcome, ask what benefit this outcome brings (or what "disaster" is averted) - try to quantify this
• establish if the new solution can achieve the outcome - identify if it does so in the same, or a different manner
• assign a classification to each requirement (MoSCoW - or Must have, Should have, Could have, Won't have (now)) - is a great tool to manage expectations
• use stepping stones, not a big leap forward analogy - make every release slightly better than the last, instead of aiming for perfection and never delivering anything to production

I would like to share with you two different experiences I have had dealing with support - in both cases the respective companies were represented by courteous support agents, willing to do what is necessary to resolve a ticket satisfactory. Yet the outcome and experience could not have been a bigger contrast. What was different? Why in one case, things got resolved above and beyond expectation, and in the other - much simpler - case the resolution proposed and committed by the agents seems to stumble into one roadblock or another and the whole process halts until I, the customer, follow up. Is it the people, the systems, the process, or the culture that drives this difference in experience?

The Companies

The first company is Zoho - not a surprise - I deal a lot with Zoho for my business, and do log cases on behalf of my customers. Setting up support for Zoho is complex - they have over 45 products, and a multi-tier support system between partners, general customers, and customers that pay for premium support. What increases the complexity is that Zoho with high frequency rolls out updates to existing software, and releases completely new applications as well - with a roll out schedule that has timing differences across the data centers.

The second company is Telstra - the largest telco in Australia. Telstra is a big company, with many departments, and processes like you expect from such large organisation.

The Cases

A great example of a Zoho case is one where I needed additional functionality in the product for a customer. It was not a bug (but in some cases where I did stumble upon a bug, the resolution process was comparable), it was just something that the software was not designed to do, but one could see the benefit of this solution. 

The example at Telstra is regarding a faulty product (hardware), and the process of getting it repaired or exchanged under warranty. Simple enough, right?

The experience

With Zoho - I log a case via their partner portal. In order to get as few clarification questions as possible, I try to be as clear as possible on the request - describing the situation, the software's behaviour, the requested behaviour, and a general case for useage. Usually the support agent responds within the same day, mostly with an acknowledgement of understanding (sometimes a clarifying question), and a suggested resolution. In this case (I apologise, but until the actual feature is released to the product, I cannot go into any detail to what the particulars of the case are), a resolution for this particular situation was provided within 2 days (it was complex enough to warrant a longer period) - but I knocked it back as it was a solution to a current situation, but was not maintainable - i.e. with any change in (in this case) the pricing structure, the fix would not work. Zoho agreed, and now they have added the functionality to the backlog, and I get in my test environment the functionality early access to test with my customer.

Telstra was a different experience. I have been a Telstra customer since I moved to Australia. I do not have many support interactions with them, but when I do, the experience has been very consistent. The easiest way to get support from Telstra is via the web chat. After wasting time with a bot, you get transferred to an actual human being, and I must say, the Telstra support agents are professional in their demeanor and pleasant enough to work with. But that is where it ends. 

Attempt 1: the support agent on the chat eventually understood the issue, and told me to bring the faulty device to any Telstra store, and they would replace it - I just needed to show the ticket number. Going to the Telstra store, the representative immediately became very interested to get me out of the door, as I was not going to buy anything - the device was not in stock, he could not order it, would not take the faulty device and call me when it was in - he suggested I'd try my luck in another store, or go back to online support so they could "sort things out". 

Attempt 2: Since the second nearest Telstra store is about 45 minutes away from where I live - I opted to contact the online support again. Provided the ticket  number, and had to explain the whole thing again. Online support suggested I'd go to that other store, and try out (yeah, right) - eventually after back and forth - my mobile phone rang - it was Telstra. Awesome! the support person actually called me. We had a pleasant enough conversation, and the agent understood the issue but was not empowered to do anything. She would transfer me to her supervisor. After about 8 minutes waiting, I was surprised to be connected to Telstra's IVR (interactive voice response) system. This is the computerised telephone response system that responds to your voice... If Dante Alighieri were alive today, I wonder which circle of hell he would exchange with Telstra's IVR system. I never lose my cool on the phone - never ever - with this one exception: Telstra's IVR system (never disrespect the support agent - they are trying their best).

Attempt 3: After retrieving my cool, back to the online chat. No - I could not be transferred to the agent (whose name I have gotten), so had to go back to step one - explain the issue. Again, Telstra called me - and again I got transferred to a supervisor... Great! After 10 minutes waiting indeed a human picked up the call... "Hello this .... from Telstra, how may I help you today?" -sigh - You guessed it - it was not the intended supervisor who would resolve everything, just another random agent picking up the call from the queue... But things were looking up - the agent understood, empathised and simply said: "I am going to put this device on order for you - you will receive the replacement within the next 5 to 7 business days. Just have the faulty device ready, we will provide a satchel for you to return it". GREAT! Faith restored! A few details were taken (most notably my drivers licence number) and the order was placed!

Three weeks later - a follow-up: Nothing arrived, so I went back online to follow up. The agent was good, read the history, and then investigated on the order.. but there was no order in the system - which the agent could not explain either, as the notes were clear. Not to worry, the order was placed then and there. Again, I had to supply my drivers licence number, and this time I was assured the order was in the system. I even received an order number in the chat. My mistake - I did not send the chat transcript to my email... but the order was made.

Follow up 2: So I thought... Because two and a half weeks later, nothing... So back to online chat. The agent could not understand either. She offered that I would go to the Telstra store, buy a replacement, and then she would ensure Telstra would reimburse the cost... A bit of a flawed solution, as the reason I was not successful at the Telstra store in the first place is that they did not hold the device in inventory. Second, I noted, given the experience so far, I would not put a lot of faith in the process of such a credit ever happening. So a new order was created (two days ago), and we'll see what happens.

Outcome: nothing, other than me exploring the competition - I am not expecting better support - but there is a price differential. Telstra's prices are higher than the competitor, and in return one would expect better service. Now I am actively looking at alternative providers - I may or may not move the service - a risk that has been introduced by this very poor support experience.

What drives this difference in outcome?

Both companies have support systems in place - Zoho uses (obviously) Zoho Desk to capture tickets to resolution. I am certain Telstra has a support ticketing system in place as well - it does not really matter which one. Both offer support via chat (although my preferred channel is email) - Zoho offers email and web channels as well - which is a plus for Zoho - but not the deciding factor in this case. Both companies employ (or contract) agents that are professional, and courteous. So on the surface, everything is the same... 

...except...

The aim of Zoho is to increase "Profitable Customer Satisfaction". Closing a ticket to resolution is a consequence of the actions applied - not the core metric. The support agents are empowered to think with the customer, and share the ticket with representatives in other departments to come to a resolution (collaboration is a key feature in Zoho Desk). It is not about the volume of tickets handled and closed, it is about the customer satisfaction. As both a customer and a partner of Zoho, I note that their take on support - although not flawless in execution - focuses on truly understanding the issue, by looking at it from both the customer as well as the engineer's angles. Consistently - with small and simple, as well as significant and complex requests - Zoho's support team has been able to come through with a satisfactory resolution. The contrast with my experience with Telstra could not have been bigger. 

Conclusion - the deciding factors in effective support

• Implement a support system that allows for collaboration within various departments - not just support agents and supervisors
• Establish a culture where the goal is to delight and amaze customers with support (mere satisfaction is tolerated)
• Set a process where customer requests are managed like a backlog in the agile process, and the resolution has to be a usable resolution (either a fix, a work-around, additional functionality that is added to the product backlog, or a pointer to a different solution altogether)
• Create an agile work environment where the support agents and anyone else tagged with the support ticket is empowered to work to a resolution (work on the basis of INTENT and CONSTRAINTS, not following a strict process or playbook)
• Measure customer satisfaction, measure it often.

I would like to applaud Zoho for their efforts in the area of support - so far they have not only ticked all the boxes, but also set a very high bar for other vendors to aspire to.

Albert Einstein needs no introduction - the creative mind that transformed our understanding of reality, allowing us to progress form the deterministic Newtonian physics to a world where Artificial Intelligence, Quantum Computers, and our every day tool such as the GPS are a reality. I have taken a few famous quotes attributed to Einstein, and applied their relevance to the business systems in use today - and the relevance is remarkable, considering Einstein made his fame before the computer, the Internet, CRM, or Digital Marketing. I hope you enjoy reading this as much as I have enjoyed compiling this.

Time travel permitting - would Einstein have used Zoho as his business suite of choice? Of course that is an academic and moot point. But does Zoho follow the principles laid out above?

1. Keep it simple - Zoho One is a comprehensive business suite - but instead of one giant monolithic application that wants to do everything, it consists of many smaller applications that are very good at a limited number of things - and because they are integrated in a sensible way, there is no need for complex custom integration points to negate your efforts to keep your process running smoothly.
2. The right resource for the job - Zoho One gives you access to over 40 different applications, each designed to execute the tasks in the most efficient and effective way. A CRM for your Customer Relationship Management needs, an Accounting package for your bookkeeping, and specialised applications for project management, inventory management, social marketing, email campaigns, etc. Zoho One also provides you with a website builder and hosting, website visitor tracking and engagement, website optimisation, as well as office productivity (email and calendar server, word processor, spreadsheet, presentations). To top it off, there is a full-fledged analytics suite at your disposal, to make sense of all your transactions.
3. When things don't go as planned, learn and adjust - Zoho constantly releases improvements to the applications, and keeps adding new applications to the Zoho One suite as well. So you are not purchasing the applications as they are today, but also subscribe to the future enhancements of the suite, opening up more possibilities for you to simplify your processes.
   
4. Ground yourself and stay humble - Zoho has maintained a simplicity in its application suite that allows you to implement the software with relative ease. If you know the domain (i.e. Accounting) then the applications are simple enough to understand and implement. Of course, there are excellent manuals available, and even videos to walk you through the set up and configuration. By keeping the scope of the individual applications appropriately sized to the application's purpose, you do not need to concern yourself with unforeseen consequences that implementation choices can have on down-stream functionality. And if you do need help, there is a partner ecosystem ready and willing to engage with you to resolve your issues (and Zoho also offers great support for their applications, if you find yourself stuck).
5. Do, Act, Execute - As a Zoho One subscriber, you have access to all the applications in the suite - at a price that is very competitive (AUD 45/ USD 35 per employee per month, based on All Employee licensing - minimum 5 employees) - combined with the easy to understand scope of the applications, at this price there is a very low barrier to start using the applications to facilitate your business processes. Further - to test the waters, there is a 30 day free trial, which allows you to evaluate Zoho One for your business for the duration of 30 days - no commitment, and free of charge. Even if you start with only two or three out of the 40 plus applications, you'll be challenged finding a better deal for these applications with the functionality provided. The applications you don't intend to use (yet) can be considered a bonus. Use the button below to sign up to the free trial.
   

Wiise is a new integrated business application aimed at small business launched in Australia - it comes forth from the collaborative efforts of KPMG, Microsoft, and CBA (created by KPMG, built on Microsoft, supported by CBA). You may have seen the press surrounding the launch of Wiise - not in the last place containing critique of the link between KPMG and CBA, as well as the (perceived?) lack of understanding these large corporations have with the actual needs of small businesses. If you are expecting a post with an indepth review of Wiise, or a scathing critique of the consortium, I can be brief - this is not such a post. But if you would like to read about what would make a great integrated business application for a small but growing business, then read on. I am using the claims made at the Wiise published website as a guideline (www.wiise.com.au).

Build your business with an integrated solution

"Move from online accounting to an integrated suite." This is the title of the Wiise webpage - and there is merit to the statement. Small businesses often start with accounting, and then add a myriad of disconnected applications to manage the business. The challenge that an integrated suite overcomes is the disconnected experience, and facilitates a healthy data flow. 

The flipside of a fully integrated suite is the complexity it introduces. A fully integrated suite is difficult to separate across the functionalities. Implementation choices can affect the functionality up or downstream in the data flow - implementation planning is essential, and a professional implementation partner is probably not a luxury you can afford to omit in the implementation.

The alternative: a suite of applications that can work independently as well as integrated. This limits the complexity and contains the consequences of "trial and error". It also allows for central user management, unified security, and a standardised "look and feel".

Get advanced analytics on your business

A business wide analytics suite is valuable - especially in businesses that have experienced growth. In order to stay on top of the business, all transactions generated in the course of the business should be feeding into a business intelligence and visualisation application. Once again, Wiise hits the right button, with the business intelligence built in and (assumed) pre-configured. 

But - what is needed for business wide intelligence is not just the tools for analytics and visualisation, it is the availability of the system to generate the transactions to all within the company. This means the value of the system increases by the number of users (or is limited by the lack of these numbers). This can be a significant factor in the overall cost of ownership - from license cost per user, to implementation complexity and training costs to get adoption across the organisation.

The alternative: a suite of applications that are simple enough to be implemented quickly, where the individual applications are targeted to specific users to keep the scope per user small, yet integrate to keep the scope of the suite enterprise wide. On top of this, a pre-configured, yet further configurable and extendable business intelligence suite included in the price - such suite will have the full business generating transactions, and consuming appropriate and targeted business intelligence.

Link Wiise to your Microsoft Suite

For users of Microsoft Office 365 (and there are a lot of them), this is a good thing. Getting the business application to work with the Office suite that most people are familiar with helps with the adoption of the business suite, and proliferation of usable data within the organisation.

There are a few things to consider. First, Office 365 may have a substantial market share, but not every business is an Office 365 user. How will this work for G-suite users? Second, there is the licensing implication to consider. On the one hand, you will need to be licensed for Office 365 to be able to take advantage of the integration. On the other hand, will you also be required to licensed to use Wiise if you only access some of the data through Office 365? 

The alternative: Many business applications can be linked to a business productivity suite, such as Office 365 or G-Suite. There is nothing new here, it is not a unique selling point. A real game-changer would be a suite of applications that gives you the choice between Office 365, G-Suite, or even brings its own productivity suite included in the price.

Connect your banking and accounting software

Bank feed integration into accounting software is a "must have". You'd have to look very hard for an accounting package tailored to the market in Australia that does not have the capability to take the feeds from the major banks. Wiise offers this as one of the key pillars - this is not really a point of differentiation.

How about credit card feeds for the expense management? Does Wiise offer expense management with approval workflows, and receipt capturing? And what about payment gateway integration, such as Stripe, Square, and Paypal? And is Wiise able to process subscription based payments (as more and more businesses are moving away from the transaction based model as the only way to buy into a subscription model)?

The alternative: any self-respecting accounting package will integrate with the major banks for the bank feeds. For small businesses, a suite that offers this integration, as well as integration with credit cards, payment gateways, and offers the possibility to have both the transactional as well as the subscription based business model would be a true differentiator, offering small businesses a means to serve customers with the flexibility they demand.

Conclusion: Is Wiise the revolution in business applications for small businesses?

No. 

Oh - it needs a further qualification... Ok, let's judge Wiise on its merits. It is an integrated suite aimed at small business. Check(really, Oracle, SAP, and Dynamics 365 are too expensive and complex for small businesses). Wiise offers comprehensive functioality. Qualified check. Wiise comes in various plans, Wiise Lite, Wiise Business, and Wiise Premium. Each plan has a significant increase in functionality, as well as cost. Wiise lite, the entry level Wiise plan, starts at $49 per user per month with a one off joining fee of $99. Sounds good for an integrated suite. However, for the Business plan the price jumps to $119 per user per month and a $990 joining fee. The Premium is the most complete Wiise offering, and will set your business back $199 per user per month, and has a joining fee of $2990. Since a productivity suite is not included, Office 365 will need to be licensed separately (currently plans start at $7.04 without the Office applications to $17.49 per user per month for the full suite) These costs are prohibitive of getting Wiise everywhere in your organisation, limiting where the transactions are generated and consumed.

The alternative: I have put the various Wiise plans against the Zoho One plan below, so you can compare the various options. Note: all Wiise features are taken from the Wiise pricing page (https://www.wiise.com/au/pricing) and may change over time. It is recommended you check the features of each plan in the below table. 

Comparing the chart above - you might have another look if the Wiise offering is the right one for your business. If you are not a manufacturer, you should consider taking a look at Zoho One. Zoho One allows you to scale your business, as it has been used in organisations with a single employee, to organisations with thousands. Zoho themselves run on Zoho One - that is approx. 7000 employees - so there is room for growth. Zoho One is priced in such way that it is not prohibitive to get everyone on board. The value of an integrated suite and business intelligence grows exponentially in relationship to the exposure to users.

Start your free trial of Zoho One today - there are no hidden costs, no joining fees - just a simple to understand monthly fee of $45 per employee per month (Australian dollar, exclusive of GST). If after the trial you are not satisfied that this is the solution for your organisation, then simply let the trial lapse - you do not have to provide any credit card details during the trial. 

Market economics is guided by a set of systematic forces that can be somewhat modelled and predicted. Somewhat, as the market system is so complex, that the models are understood retrospectively, but prediction is mostly thrown off by one or more obscure factors not considered. And then we come to business applications - aside from the attempts of all vendors to make comparisons between competing products difficult, there is also a not so small amount of emotion involved.

 Comparable alternatives

The price we are willing to pay for goods or services depends on the cost of alternatives available, including the alternative of doing nothing. Easy, weigh up the benefits, and compare those to the cost, right? Well, yes and no. The model is not that simple. Take the automobile industry - if a car was compared only on the utility of getting a person from A to B safely, and in comfort, then the choice would be made on price versus specification only. Yet, we are willing to fork out considerable more money, for vehicles that on paper have less to offer in the form of features, specifications, or even reliability. There is an emotive factor at play. In business applications, a similar process applies. Especially in larger organisations, where more people are affected by (perceived) change, the choice seems to lean towards the "familiar", or at least, something not too radically different. The alternative is compared to what is already there.

For smaller businesses, or entrepreneurs, there is another dynamic at play. Especially when considering the solutions provided via subscription to a cloud service - there should be an easier way to compare. This is, unfortunately, not true. There is a huge difference in the solutions provided by the various vendors. And the price is not at all directly related to the features, or support levels.

What you don't see is what you are not getting

For small businesses and entrepreneurs, the business applications reflect a very simple solution to a very core need: to save time. Saving time doing administration, saving time by proactively managing the customer communications, saving time by managing the sales pipeline. Time saved is time spent on growing the business. Sounds simple enough, but how do all the various solutions out there help with saving time? And at what cost?

Is there a monthly cost? What is the offered functionality? How many users? What are the limitations? For example, a popular financial (accounting, accounts receivable, accounts payable) solution for entrepreneurs charges $25 per month - this covers also payroll for one person. That is great - not too expensive. However, the limitation is only 5 invoices and quotations per month... And additional users will incur additional charges. But what other functionality is supplied? Customer Relationship Management? Project and Time administration? Expense management and reconciliation? Does that cost extra? So, there is a per user cost, and a per module cost... Still, relatively inexpensive for the value it represents. Now let's add productivity and collaboration. Microsoft's excellent Office 365 business premium will cost around $18 per user per month. Google's G-suite starts at $5 per user per month, but a comparable offering to Office365 is $10 per user per month (most notably, you get 1TB of cloud drive for $10 per user per month, compared to the 30GB on the $5 plan).

What do you need as an Entrepreneur or Small Business?

Need is a difficult definition. entrepreneurs and small businesses have been doing just fine with spreadsheets, or even paper-based systems. However, in a high speed, highly competitive market, this is not competitive. Also, how much time do you really want to spend doing administration, versus spending time growing the business, or tending to the family life? I found the following to be essential to keep a lean administration:

·  Accounting

·  Accounts Receivable

·  Accounts Payable

·  Bank integration

·  GST/BAS reporting

·  Expense management (via mobile phone)

·  Inventory management (if you sell items)

·  Hours administration (if you invoice time)

·  Subscription and Retainer invoicing

·  Payment gateways (i.e. Stripe, Square, or PayPal)

·  Customer Relationship Management with Pipeline Management and Sales Forecasting

·  Productivity tools such as Word Processor, Spreadsheets, and Presentations

·  Online Meeting facilities

·  Email and Calendar server

·  Cloud storage (1TB per user is desirable)

·  Team collaboration sites (for knowledge workers)

·  Website design and hosting, with integration to sales and booking tools (where applicable)

·  (Payroll)

If you assemble your solution with these components, it becomes quite complex, quite fast. Some elements are based on a per user per month basis, others are charged based on other more functional metrics (such as number of projects, or number of invoices). Plus, you will have to deal with different vendors, different terms and conditions, and additional cost for integration (if applicable). Entrepreneurs and small business especially are served with simple systems that allow them to grow, and predictable cost structures.

I have placed payroll between brackets, as that is a bit of a different animal - a good payroll system is integrated to your business systems for the relevant data (hours worked, etc), as well as the general ledger and banking transactions (to reflect salaries and taxes paid). Payroll itself, however, is best outsourced completely, as there is advantage of scale.

Summary - selecting your system

Basic economics dictates the choice to spend resources (money) for goods and services against the available alternatives. For instance, do I spend $25 per month on an accounting package, or do I spend 4 hours per week getting the administration in order (if it can be done that fast). But that is only one alternative (buying a service or doing it yourself). The question is two-fold - 1). Does the service provide added value (i.e. there is a net positive monetary effect), and 2). Is the cost of this service reasonable against other, similar services, now and in the near future? Most will decide only on question 1 - it solves a problem, and the fee is reasonable for that solution. It does short-change your business, as other solutions may do the same for less cost, and/or provide cheaper options to facilitate growth. The last thing you want to do, is lock your business in an application where it is difficult or expensive to keep the applications in line with the business growth. Especially when you add employees, the need for collaboration tools increases. This could impose additional and unexpected costs. Ideally, the same per user per month cost will provide more and more value, based on the number of employees added.

Originally posted: 12 February 2018 

Einstein described the dilation of time in his Theory of Relativity - two different observers experience a difference in time elapsing, based on their difference in velocity and/or experienced influence of gravity. In projects, a tongue in cheek analogy can be made: measuring the velocity of elapsing time by minutes of accomplished tasks, the passing of time seems to slow within a large program. Of course, there is no physics at play, just program dynamics caused by increased complexity with increased team sizes.

The larger the size of the project, and the closer to the centre of activity you are, the slower things tend to get done.

The "slack effect"

Any good project schedule has slack strategically placed in the plan:

·  Scheduling contingency - actual time spent on tasks tends to be in round figures - i.e. 2 hours as opposed to 1 hour and 45 minutes, 40 hours as opposed to 37 hours, etc. 

·  Risk contingency - slack built in to reflect risk in certain tasks taking longer before completing, therefore keeping the program completion date fairly stable independent of these risks occurring

·  Dependency slack - risk contingency applied to dependencies to the critical path, minimizing risk that slippage will slip the critical path.

Slack tends to behave like storage space in a home - the space available tends to get filled with things, and the average value of the things occupying the storage space is in direct, but inverse relationship to the storage space available. In other words: if you have slack in the program, it tends to get filled with activities, and the more slack there is, typically the lower average value the activities return to the program. This is the "slack effect". 

No slack or low slack planning?

Having no slack on the schedule is just asking for trouble - things will go wrong. The question is: where will things go wrong first - at customer end, or at the implementation partner? It is like the proverbial escape from the charging bear: you don't have to be the fastest runner, as long as there is at least one slower than you! In other words, this tends to create a situation where customer and implementer each look for dependencies on "the other side" and use those to build slack in their own schedule where needed. Although it does not exclude it, this is not conducive to a cooperative environment. Planning slack is something that simply needs to be done. but there are some guidelines to follow to keep it under control in both scheduling and managing slack:

·  Schedule slack in sequence - beware of compound slack. Start with the largest slack, scheduling contingency, and then work down to the lower level detail risk contingency and end up with dependency slack. This prevents scheduling contingency being applied over risk contingency, which in turn is applied over dependency slack.

·  Schedule slack separate from the task - if a task is scheduled for 8 days, and you add a day of slack, do not just add the day to the task, as that will be seen as a normal schedule. You can either schedule a day of no task between this task and its successor, or schedule a task called "slack" without assigned resources between the task and its successor (assigning a slack task allows for easier measurement of slack and its use into he program).

·  Using slack should not be "business as usual", nor should it be excessively difficult to apply. There are two actions that need to be taken at the end of each task completion: first, update the time with actual - second, set the slack hours to 0. 

·   Manage activities like slack does not exist - the team should be encouraged proceed according to plan without slack. This means that once a task is completed, the next task moves forward.

·  Schedule slack in grouped tasks - wherever logical, group tasks together and apply the slack task only at the end. This saves a lot of administration work!

·  Manage slack both from customer side as well as implementer side as one. The slack is not a commercial instrument for contracting, it is a mitigation on scheduling risk.

·   Manage and report both duration of task, as well as program timeline.

The complexity in managing contingency and slack is proportional to the complexity in the program - a program with 10+ streams running over 2 years is tremendously difficult to manage by itself, adding contingency and slack management to this is a monumental task. In such cases, it is highly recommended to cut the program up in smaller task-sets - ideally between 6 to 13 weeks in duration. Each task set can then be managed as a separate project within the program from a slack and contingency perspective.

A final thought - in order to arrive on time, it is essential to leave on time. In my personal experience, large programs are difficult to contract, there are a lot of T's and C's to be negotiated. In one particular example, the negotiations went on over eight weeks, eating four weeks into the schedule of the first milestone, which had a duration of six weeks total. This is not setting the program up for success! Allow for complex negotiations to complete, and where necessary (in case of a time-sensitive compelling event) allow concurrent execution on letter of intent - but be aware that negotiations are a dependency in the program, and appropriate slack there is not a luxury.

Originally posted: 29 January 2018