Story 1: Checklists

This story is about how I started improving standard construction checklists from a user perspective and why I have questioned any spreadsheet with requirements and content since then. In "The Elements of User Experience" book, Jesse James Garrett mentions that for content requirements, related to the Scope Plan, making an inventory of content usually takes the form of a simple, but extensive spreadsheet. Anyone who worked in construction knows about all the requirements and content that have to be controlled and shared within a specific project. As a result, I have experienced in my career several spreadsheets that need to be updated and fed constantly. The problem with most of those spreadsheets is that people are not clear about why they are filling all those hundreds of cells. The most likely scenario is that an engineer, coordinator or manager once created it to store and remind themselves of pieces of information, and others only reproduced and followed the standard because it seemed brilliant then. But things change, projects evolve and sometimes the tools are not as thoroughly reviewed, because let's be honest, who has time for it?

Analyzing perspectives

When I was working with the design team of a construction company, one of the challenges was to understand and “debug” a tool called briefings. Those were comprehensive Excel spreadsheets with descriptions of requirements and standards (more than 100 of them for each type of project): an extensive checklist. Architects and engineers had to review, follow and ensure their designs complied with those checklists. Those documents were very well established and created way before I started to work for the company, but I decided to investigate them further because I soon realized there were a lot of issues with this procedure.

Most project coordinators and managers constantly complained about the deliverables not being compliant with those requirements. From their perspective, architects and engineers were just not good enough, lazy and did not follow the checklists just because they did not want to. There was constant pressure on the architecture and engineering design companies to fill those spreadsheets with comments and checkmarks that they were indeed following the rules. More than that, for the designers to receive the payment for a specific phase of a project, sending those spreadsheets with their considerations was mandatory and a requirement according to the contracts. In other words, if no spreadsheet was filled, there was no payment in their accounts.

When I asked the architects and engineers, most of them did not know how to answer why they were not complying with it. They just mentioned vague explanations and said they would try harder to submit those checklists with their review and consideration as soon as possible. I had an impression that they also did not think about why it was so hard, and were also afraid of stating their real impressions in a meeting full of directors and managers, the people that were paying for their services.I already had the clarity that if a tool does not work for any of the main users, it’s because there is something wrong with it. As I started poking around, people naturally got annoyed with questions and investigations of a young and recently hired engineer. However, I tried different approaches, like asking and checking with those professionals in one-on-one conversations and sending some forms with questions about that. I kept going until some hypothesis statements were defined, but none of this was very structured or a corporate project type of investigation.

Hypothesis

Once I came to the following hypothesis, I could start reviewing and testing them, because I did not want to present my manager a problem without some possible solutions.

• If the requirements in the spreadsheets were organized on different software, then would architects and engineers be able to comply with them?

• If the coordinators and managers pushed them harder, then would those architects and engineers answer more proactively to fill up those documents?

• If the spreadsheet was shorter, then would the architects and engineers easily fill them?

• If the spreadsheets were reorganized, then would those architects and engineers understand this document better?

Ideation

In construction, like several other industries, there is a common understanding that the project development should be divided into phases, each of those phases has specific requirements and guidelines that have to be followed, as well as decisions to be made. This applies to architecture, structural, mechanical, electrical design and any other scope that a building has. What those checklists were, in the end, were those requirements, but they were not ordered by phase, rather, they were ordered by a process the company had of preventing errors. Every time they found an issue that was serious enough and cost a lot of money, they would find the solution and add it to the checklist, as a rule, to prevent it from happening in future buildings and projects. As a result, the checklists were very hard for those designers to follow. If they checked all the requirements in the beginning, say the programming and feasibility phase, most of those requirements weren't yet decided and it would be a waste of time to analyze them. If they check them too late in the project phase, like when delivering contract documents and shop drawings ready to build, it would be too late to change the whole system.

Solution

After almost adopting a too-complicated solution such as a sophisticated project management software with those requirements (with tags, tickets and excessive status options), creating separate tabs on the spreadsheet for each project phase did the work. We also added conditional formatting to show both designers and coordinators the progress evolving while those documents were being filled, to create and give them "feedback" from the "system". We also accepted feedback from the designers when they thought a specific requirement should be put earlier or postponed in the project development, which helped us refine the tool.

With this simple solution, meeting the requirements turned out to be easier for all users and compliance with the company's standards got higher. But it's not just that, it's the time people spend trying to figure it out, that is really hard to measure and account for in big companies, it's the change orders from systems that were built wrong because a checklist wasn't followed properly, it's the time and cost of it all and not least important, the frustration of people involved and their disbelief in the tools that were supposed to help them.

Lessons

One thing I would have done better if I were to do this again, I would try to measure the effects of not using those checklists. In some projects, it was just too late, the checklists were never filled and the problems were solved in the end. Potentially more money and time were spent, but since this wasn't measured properly, I don't know for sure. The results I was using for starting this process was qualitative, because it was based on the complaints, frustrations and impressions of the coordinators and designers. I would have collected a more organized and structured set of data about how things were before and after to compare with the outcome after this simple solution was applied. However, I am happy that people had fewer issues and fewer tasks to coordinate after this improvement though.

In the other companies I have worked for, I also realized people create several checklists, and I keep analyzing them, just to understand if it is useful or not, but this is a subject for another story.