Humanlytics

View Original

4 Keys to Prevent Your Data Project from Failing

Lessons I learned from a recent IT failure in my family business

You spent so much time on your IT project, don’t let it fail.

Recently, I took on a side hustle advising my family business, a large health and weight loss enterprise in China, with their project management as well as the implementation of their first enterprise resources planning (ERP) system.

The company hired a team internally to build the system, however, a year into the project not only was the ERP system missing many key features, but the project manager was no longer in the picture, having abruptly left the company about a month ago. This incident left the company without anyone knowledgeable enough to take over the project.

While running project autopsy with the CEO of the company, I realized that the failure of the project stemmed from a lack of basic knowledge regarding both the business cases as well as the project management process for data systems.

The purpose of this article is to present you with four lessons we learned from this failure so you can avoid them when building your data infrastructure.

1)Know what system is best for you and base it on your business objectives

I know it is almost a cliche to say that strategy and objectives should come first when building anything data related, but failing to hold that true throughout the project became a huge t problem.

More specifically, our first pitfall was the fact that we didn’t know what we wanted to build.

After multiple conversations with the CEO, I began to realize that the functionality of the data system she desired was far beyond what an ERP system can accomplish.

In reality, she wanted an ERP, CRM (Customer Relationship Management), and E-Commerce system all in one., However, due to her lack of knowledge about IT, she thought an ERP system could do it all.

After conversing with the CEO, we distilled the business cases of the data needs into four major components.

  1. Improve interaction with customers through services like online scheduling and personalized profile management.

  2. Expand our products’ digital reach through the introduction of an online e-commerce store.

  3. Improve internal management through the construction of a robust analytics system to support the decisions of store managers.

  4. Optimize the internal financial and operational processes of the company.

After examining these four needs based on the current IT infrastructure of the company, I recommended the company first implement a CRM system to support both a robust store manager decision support system and a customer profile management system.

The reason I made this priority is that its implementation would provide the company with immediate benefit by facilitating better customer interactions and, as a result, lead to a better customer experience.

To satisfy the need to increase the company’s digital reach, I suggested it first use an existing e-commerce platform such as Taobao.com or JD.com to test traction. Then, if the volume justified building a specialized system, the company could then migrate the previous system to the newly constructed e-commerce platform.

That way, the company would not waste money nor effort on building an e-commerce presence that wouldn’t have any traction anyways. This would also give more development muscles towards the CRM system, ensuring its on-time completion.

In regards to internal processes optimization, we decided that it would be a low priority. This is because the processes an IT system can optimize do not immediately increase revenue or decrease costs. Therefore, we decided to build an ERP system once the two steps explained above were completed.

2)Decide to Build or Buy Before Anything Else

Another reason our project ended in failure was the fact that we decided to build the system instead of pursuing alternatives such as contracting or buying an existing platform.

The decision was made rather rashly because the CEO did not know that outside contracting or buying out-of-the-box software was even an option.

Additionally, the internal build team was improperly constructed as it only had one project manager and two programmers on the team.

Furthermore, the IT team maintained a strange position in the company in which it was only able to secure buy-in from the executive team. This fact further prevented the development process from proceeding efficiently.

The bottom line is that project managing a large-scale IT project is not a simple feat. It requires knowledge of the users’ requirements, the ability to lead a build a team, and communication skills that allowed you to talk with all departments of the company to make sure that everyone buys into the new system.

Through discussions with the CEO, we decided that even with the ERP system already built, pursuing an out-of-the-box option or a customizable software was perhaps still the best option. due to sheer amount of effort it would take to maintain the current custom built system. Therefore, we decided to halt the further development of the ERP platform and began reaching out to software vendors.

When considering whether you should build or buy, you first need to consider whether or not you can fulfill one of the following criteria. If you can’t, buy or hire a contractor.

  • You Can Do It: Your company has expert project managers and software engineers on hand.

  • You Must Do It: Your company has special needs that cannot be satisfied by current software offerings.

  • You Should Do It: Your goal is to make your company’s data system the unreplicable competitive advantage of your firm.

Even if you are hiring a contracting company or buying an existing solution, you will still need to communicate with the contracting or the software company to make sure that 1) the solution offered by the company truly satisfies your need, and 2) you have enough buy-in from your company to ensure effective adoption of the solution once it is implemented.

3)Always start with a robust data system so you can scale in the future

One common misconception people have about data systems is that they should remain separate in business.

The fact is that all data systems in your organization should be as closely integrated as possible. Ideally, all of your systems, whether ERP, CRM, or OA, should all take data from one centralized source and utilize databases organized to accommodate data of various structures and input/output needs.

Related to my family business, another reason that caused the recent IT project to fail was that the company was having some issues with IT governing in the first place.

It currently has an Office Administration (OA) System, an Enterprise Resource Planning (ERP) System, and an accounting system.

However, each system has a distinct data structure governing it, and there are no built-in mechanisms for those systems to communicate with each other.

The biggest problem we encountered when building and testing the new ERP system was that the database supporting the system did not leave any room for accounting integration and there was too much additional work that needed to be done to either integrate or replace the existing accounting system.

Before this ERP system, we already had to rebuild our core database twice while replacing the previous systems and now the company will, more likely than not, need to start from scratch once again to construct another database that fully captures all departments of the business.

Therefore, my recommendation is to always construct and provision for a database system with an eye on all potential future functionalities and systems you might want to incorporate within the next five years.

This means that, even if you just want a CRM now, you should leave space and provisions in your database for additional functionalities such as ERP, or, at the very least, you should leave a few API endpoints open to ensure easy integration in the future.

Many out-of-the-box systems such as Salesforce already have such endpoints in place — this is another benefit of buying software over building a system in-house.

4)Scrape something together that works first and then fill in the blanks.

This suggestion seems to be in direct contrast with the previous one, but that’s not the case.

In the end, the biggest challenge for our IT system was not the system itself, but rather the adoption of the system by both its internal users and our customers.

The ERP system was built over the course of a year and all behind closed doors, and since the release of the first version a couple of months ago we have received multiple reports about the company’s employees not adhering to the data entry standards because they don’t see value in them.

In retrospect, what we needed for our system to succeed was constant interaction with the users when building out the system, and an agile development methodology to enable rapid iteration.

For this reason, even though it is important for the database system to be robust and provision for scale, it is also crucial to keep in mind that the development of your tools needs to be fast, scrappy, and to constantly adjust based on user feedback.

In the end, the ultimate value of all data systems is to create value for either your employees or your customers, and neither will be accomplished if your end users do not use the tools or cannot get value out of them.

I hope these recommendations and tips help you implement your next data system. If you have any questions about your data system, I am more than happy to get on a call and discuss, simply schedule with me at calendly.com/su20yu1919.

To stay updated on future blog posts, please follow us on Medium at analytics-for-humans or on Twitter and Facebook. If you have any questions about this article, please feel free to email me at bill@humanlytics.co.

This blog is produced by Humanlytics. At Humanlytics, we are making tools to make Data Analytics easy, compelling, and valuable for all businesses. If you want to learn more about Humanlytics, please visit our site at humanlytics.co.