Over the course of my career, I’ve had the privilege of working with several awe-inspiring developers and building some pretty cool proprietary tools before I arrived at One Model. Every project was unique, and I experienced first-hand the rub between business, development, and internal end-users. From working toward MVP (minimally viable product) and beyond to switching away from proprietary solutions, I’ve seen both success and failure along the way. Here are just three failed IT projects from my trove of stories that I feel everyone could learn from. I hope that my experiences can help us all consider the possibilities and rethink building a proprietary people analytics solution.
At a previous company, we had a special, custom report generated for all of our clients that we built from two data sources: publicly scraped information and connected account-based search engine data. We had two critical needs that made a proprietary solution very appealing:
We evaluated what was needed, created the MVP, and worked through a series of sprints to create enhancements and fix some minor bugs. MVP took us about half a year, and we worked on enhancements for another few quarters. It worked great - For a while.
About two years later, our development team was busy implementing some exciting new clients, building advanced features on other systems for our bread-and-butter clients, as well as making new in-house software development enhancements for other parts of the org. At this time, our reporting tool was working as expected… until it wasn’t.
The data source broke, and we had to find and code a new solution. All of a sudden, an item non-existent on the roadmap became a big problem that we needed to fix asap. It created a strain for both the business and the development team.
When it's proprietary, you own it. It may seem easy to build something, but companies often fail to plan for ongoing maintenance and prepare to fix major issues. It's too easy to neglect a tool that seems to be working for the team.
I worked for a company with an efficient CMS proprietary system that we used internally to manage our clients, including some of the most recognized brands in apparel, sports equipment, and toys. When I joined the company, this tool had been used for nearly a decade. The development team often compared the code to a giant Band-Aid ball — so many patches had been put in the code that it was now almost impossible to update something without causing a lot of problems in other places.
After I had spent several years working directly with this tool, the founder of the company, who was one of the original developers, had a new concept that would revolutionize how we managed our clients’ content. We assembled a small but mighty team, with seasoned members specializing in ideation, development, project management, and end-user experience. We laid out a three-week Scrum process that would keep the project on track.
The board cut funding after seven months. In this case, the board paused funding, the lead developer left, and the project died. It was really unfortunate because the permissions, data structure, and communication mechanisms between different parts of the tool were in the final stages of development. When other top developers were brought in from other parts of the company to review it, they were impressed with the quality of work and how much was there. However, the support, both to build and from the board, was gone.
The process and concept were really cool, but ultimately, I learned that the boring stuff is often what takes the longest to build and funding can dry up or be shifted towards a new project. Like building a house, the bones are the most important part and can eat up a huge chunk of your funds — even though that’s not the part you actually see. People can also optimistically underestimate the effort it takes to get the backbone of any project stood up.
I was brought into a company specifically to work with their proprietary marketing automation platform. It allowed me to put all clients into the same strategy but use their own unique messaging from their unique email addresses and phone numbers. It had safeguards to reduce the possibility of client branding cross-contamination. It created scalability with a measurable/adjustable strategy while still allowing for highly customized messaging.
However, there was a problem, the proprietary tool was built without reporting. Also, working inside the tool was cumbersome and increased the risk of human error. To counter this, there were multiple checks involving marketing and development before anything could be updated within the tool.
Change requests were worked into a queue for the development team, and they worked on some enhancements as they had time against other business needs. The problem was development was already spending a lot of time just helping with day-to-day operations in the tool, and it became harder to justify additional time commitment for the tool. Often if the tool broke, it required our top talent to figure out and fix the issue.
The company ultimately decided to buy a flexible platform that provided a proven starting point and empowered us to build customizations within it. We brought in consultants, evaluated companies, and noted requirements. We needed a custom implementation, but we wanted to see if there was an option that would allow us to do the more complex projects we always dreamed of creating. We purchased and stood up enough to start the existing automations in the new environment. Then over the next year, end-users and developers worked to make customizations in the newly purchased CRM and Marketing Automation tool to meet our needs.
In the end — success! We were finally able to build the strategies that we wanted, and the tool was regularly updating and becoming better. We also had a support team beyond our development team, and our capabilities exponentially grew.
Sometimes it seems like a good idea to do it on your own, especially when you have such amazing talent internally. However, your team is ultimately interpreting end-user needs who may not have the full vision for all their needs. Also, while your development team is good, they may not have the exact experience to build that specific type of solution, and therefore the code may not be as flexible as it needs to be to accommodate future requests. So while it will work (because your dev team is amazing), you’ll quickly discover that MVP is not really MVP, and you are stuck with something that needs a lot of Band-Aids. Buying and then building upon that tool — now known as build+ — set us up with a flexible solution and high-quality support team.
Building your own HR analytics software is really a funny concept when you actually stop and think about it. You wouldn’t have your field workers build their own cars to go to each event. You don’t have IT build computers for your company. You buy the cars and the computers. You wouldn’t ask your team to reinvent Microsoft Office either. It is unrealistic to expect your developers to create something great when comparatively non-DIY, 3rd party solutions took thousands of build hours from people who have spent decades working in their fields.
Data transformation and machine learning are the same when it comes to people analytics solutions. Compared to a DIY solution, One Model accelerates time to value in an organization and becomes usable in just a few weeks. Plus, One Model acts as a strategic partner with a skilled team of data engineers and experienced customer success practitioners who share the people analytics journey with you. Learn more here.
1. Your HCM may handle data differently than you expect and, therefore, you’ll have to do work to put that data into an analytics-ready table format. For example, Workday combines your data with business logic. Therefore, most of its data is in the form of snapshots over time. To answer any question related to time, or filtered by a period, you need to pull every possible snapshot and stitch them together into a proverbial “flipbook”.
2. In order to connect old data sets or pair them with complementary systems, like surveys or learning management tools, work will be required to merge the data with appropriate keys to ensure dates align for proper analysis.
3. You did your best creating the requirements, but your HR team is not a tool designer. It is more likely that factors will not be considered and key requirements missed. This is the number one reason your IT team will never be finished building this solution. After something has been built, a seemingly simple request, like a breakout or grouping, can require significant rebuilds. You’ll be saying, "Technically it works as designed, but every new question requires a rebuild and takes so much time. Our HR analysts can't even do a voluntary turnover graph."
Your IT team wants a solution that offers the best of both worlds, so you can buy the right starting point and then easily customize within it.
One Model offers a best of both worlds approach and lets you bypass all the headaches and start making people decisions based on your data. With pre-built storyboards and step-by-step predictive analysis tools built-in, you own the transformed data and your development team can use One Model as an HR data consolidator for all your HR tools. They can own the transformation logic while your team works on answering the questions currently burning a hole in your soul. Plus, One Model is flexible — so your teams can build and customize within the platform to fit your organization’s unique needs. Read our whitepaper to learn more about this best of both worlds approach.