And So It Begins From Prototype to Production

We were working with a client on professional ladders and market-based pay back in 2015. The ladder designs were stored in fairly large and somewhat complex Excel spreadsheets. Then the client asked for something that was going to be difficult to represent in spreadsheet form.

So, we created a software prototype -- over the course of a weekend -- to show the client the following Monday. It was called the Professional Advancement and Competency System, or PACS.

The Problem With Spreadsheets

The spreadsheets we used were functional and quick to create, based on templates developed over the course of many years.

  • Each ladder had at least one spreadsheet.
  • The criteria to be assessed was represented as a tab.
  • Assessment data could be included and tallied.

The spreadsheets we were using worked fine for the purpose of describing a professional ladder. But there were several challenges that we overcome with raw labor:

  • Common content was repeated -- and had to be updated -- across multiple files.
  • The sheer number of ladder files, even in a small organization -- were hard to wrangle.
  • While assessment data could be stored with the ladder file, it had to be compared using brittle cross-file features.

Not A Bad Weekend's Work

So PACS was born. In a weekend. How could we do that? Well, because part of our consultancy still included development skills from the by-gone days when we built custom software for clients.

We were so familiar with the requirements and the content that building out the prototype in three long days was pretty straight forward. Our platform of choice was Django and some third-party resources to spruce up the look. After designing the data models, we were able to get a decent user interface almost for "free". Most of the remaining time when into the business logic of performing level calculations for employee assessments.

The result was a form-driven interface that provided everything one needed to:

  • Define content for ladder criteria in one place.
  • Design a ladder.
  • Perform an employee assessment.

The client was happy and used the prototype as is for more than a year.

User Interface Challenges

While PACS worked a lot better than spreadsheets to define criteria and create ladder designs, it was still difficult to use. Users complained that it was hard to find things or even know where to start. We observed that:

  • Designing a professional ladder is a repeatable process.
  • The steps of the process easily lend themselves to a wizard-based approach.
  • Certain content included in the ladder must already exist or the design process will stall.

Performing assessments followed a similar pattern and could also benefit from a wizard-based approach.

It also occurred to us that PACS solved a problem not only for us when engaged in talent management consulting, but also for organizations seeking an alternative to performance evaluations.

When our client demonstrated the tool to peer organizations, there was a sudden interest in competence-based assessments.

This month, we returned to the idea of PACS. We mapped out our vision of what a talent management tool might look like and created some wireframes detailing how we could improve the user interface.

Conclusion

We decide to pursue PACS as a salable product, although Professional Advancement and Competency System doesn't exactly roll off the tongue, and "PACS" is pretty much meaningless.

Since so much of an organization's success is based on the people it employs, we chose Basis HR as the name of our tool. We aren't necessarily fond of the HR, but felt that it was needed to successfully identify the product in the marketplace.

We'll keep you posted on our progress.

To be continued ...