Blockers can take a tiny task and stretch it over days or weeks. Taking a moment at the beginning of a project to look for and prevent possible blockers can improve productivity. These examples of personal, team, and organizational levels show how gathering the right information and performing preflight checks can save hours of wasted time later.
Example 1: Personal productivity.
Two IT workers—Andrew and Bertie (not their real names)—were assigned the same task. While this task should have taken about an hour of hands-on keyboard work, it took Andrew four days.
Andrew’s story.
Andrew began the task one sunny Monday morning. Work went well until he hit a speed bump and needed to ask the requester (who we will call Roger) a question. Andrew tried to find him on the company chat system, only to learn Roger was out of the office. Andrew sent an email instead.
Roger replied on Tuesday. Tuesday was a very busy day for Andrew, who didn’t see the reply until the afternoon. By then, he was still busy with something else and didn’t get to work on Roger’s request until Wednesday.
On Wednesday, Andrew made some progress but had more questions. Roger’s request referred to “my database,” and Andrew, smartly, decided to contact Roger one more time to ask the exact name of the database rather than guess.
Andrew didn’t have the necessary access rights on that database, and it took a while to find a coworker who could grant him the required access.
Andrew finally completed the task on Thursday—about one hour of work that took four days to complete.
Bertie’s story.
Bertie also began the task on Monday morning. She reviewed the request and quickly realized there was a lot of missing information. She called the requester’s cell phone and interviewed him until she had everything she would need to do the task without interruption. While still on the phone, she verified she had the required database access. She didn’t, but the person was able to grant her permission while on the phone. In a few minutes, she had everything needed to get started. She completed the request shortly afterward, in about two hours total.
Same task. Very different levels of productivity.
Analysis.
Bertie understood the value of gathering everything required to do a task up front. Andrew was trying to get the information he needed “on demand” or as he got to each step. To Andrew, it felt more productive to dive in and begin right away. Sadly, Andrew was wrong.
As a general principle, people are more productive when they have all the information needed to do a task up front.
With this in mind, what improvements could be made?
On a personal level, at the start of a task you can pause to think through the entire process. Be pessimistic and ask yourself, “What could go wrong?” Verify that needed access is available. Verify the information required to do the task is complete.
On a team level, Bertie could teach the rest of the team what information to collect for that kind of task.
This can be done informally by casually reminding the team at their weekly staff meeting what information needs to be gathered before starting such a task.
It could also be done formally. If there is a process document, it can be updated to include a “before you begin” section. This would list information to collect, as well as other preflight checks such as verifying access rights, listing which software tools should be installed ahead of time, and so on.
By recording such lists in a way that others can use and reuse, Bertie boosts the productivity of anyone who does the same task in the future. Not only is she more productive, she makes everyone more productive.
Am I Allowed to Do This?
I suspect some professionals reading this might work in environments where they do not have the latitude to create such preflight checks for peers. In these environments, process improvements are a management responsibility, and it would be presumptuous for a subordinate to try to improve anything. This may seem counterproductive—because it is. Process improvement is everyone’s job, and when managers create roadblocks that prevent the people doing the work from making improvements, they do a disservice to the company.
Such restrictions are counterproductive, yet I suspect they are more common than you would expect. In such environments, the creation of preflight checklists like Bertie’s might take months of bureaucratic wrangling and approvals. It would be faster to do it unofficially, by just passing notes around or setting up a shadow documentation repository. Doing this unofficially, however, might upset the political apple cart or agitate an overly zealous manager.
My advice is to do it anyway. A good manager will reward such initiative and a bad manager will simply reveal yet another reason why you should be sending out your resume.
One of the reasons I like keeping procedure documents under source-code control is that improvements can be proposed, reviewed, approved, and merged just as we do with code changes. For example, Git’s PR (pull request) process, normally used for code changes, works well for documents and affords the same review, tracking, and accountability.
Readers who work in highly regulated environments might be thinking that they cannot just change a process on a whim, and it is easier to live with a broken process than go through the steps to fix it. But no regulatory body requires you to keep buggy processes. In fact, they usually have requirements that broken processes be fixed in a timely manner. Git PR provides a way to make a change with approvals, tracking, and accountability that enable you to comply with regulations more efficiently.
Example 2: Transactional requests.
Receiving a request by email is convenient for the requester, but it is prone to not collecting all the information needed to complete the request.
In the old days, there were paper forms that people filled out with a technology commonly known as a pen (kids, ask your grandparents). The form collected the pertinent information up front.
Some companies had dozens or hundreds of forms. When I worked at Bell Labs in the 1990s, the stockroom had a huge shelving unit with a compartment for each form. “A form for every occasion,” we used to joke as we walked by it on the way to lunch.
There was even a form for ordering more forms! I always wondered what would happen if we ran out of that form. I suppose the company would have simply ground to a halt and ceased to exist.
Today, a typical helpdesk request is submitted via email or a Web form with a single huge text box. The requester is free to format the request in any way and include as much or as little detail as desired. This is particularly frustrating and anxiety-inducing for users. I’ve seen countless helpdesk tickets begin with an apology for not knowing how to ask what they’re about to ask. How toxic is it that we create systems that, by design, make its users feel ashamed of themselves?
There is comfort in being told what to do by a form. It does not judge you for not knowing what options are available and instead, lovingly provides checkboxes and blanks that hold your hand through the process of making the request.
Modern helpdesk systems solve this by providing an electronic form facility so that the correct information is collected up front. Creating an electronic form for every occasion is difficult, however, and most IT teams I’ve seen use the form feature sparingly, often only for a few standardized requests such as asking for a new laptop. (Logophiles might appreciate the fact that these free-form requests are a result of the system being form-free.)
The easier it is to create forms, the more likely they will be created. Sadly, this feature is typically locked down so that only high priests of the system may create forms. I think it’s best to make it easy for anyone not only to suggest a form, but also to create one.
Github.com makes creating forms as easy as creating a text file. I know this because many open-source projects have created forms to guide users through the bug-reporting process. It’s amazing how many community-driven software projects have better practices than industry.
Rather than having many specialized forms, some helpdesk systems have one monster e-form that changes dynamically as the user is guided through a series of questions. These never work well for me. I find my request either doesn’t fit into their categories, or the categories are proxies for an internal org chart that is unknown to the end user, or the system insists on requesting irrelevant information. Years ago, I found myself using such a system to request that the facilities department replace a dead fluorescent light in my office. I had to list which operating system I was using and whether the problem could be reproduced on the previous version of “the software,” whatever that could possibly mean.
You can tell if your helpdesk isn’t providing the right forms when the typical first reply from any ticket is a list of information needed to proceed. “Thank you for submitting your request. To proceed, reply with the name of your computer.” This adds an additional “round trip” before you can get the assistance you need. This delay could be prevented with a simple form.
Some helpdesk systems connect to inventory and personnel databases to reduce the amount of information humans must collect. For example, why ask a user for their phone number when it is in the corporate directory? Why ask for their computer’s name when it could ask the user to choose from a list of host names associated with the user in the inventory database?
Not all IT professionals work at a helpdesk, but most work in a system where they receive transactional requests from others. Likewise, there are plenty of ways to convey to coworkers, partners, and customers what information is needed to perform a particular request. Where I work, we have an internal Stack Overflow for Teams instance. I assure you that many procedural questions have answers that begin with a list of information to provide to assure smooth sailing.
Example 3: A pre-engagement questionnaire.
While some software as a service (SaaS) products can be activated in a self-service manner, more complex ones require an onboarding process where a “customer success team” helps with initial setup. Typically, the customer is asked to answer several questions, usually in the form of a Microsoft Excel spreadsheet. The questions include the company’s domain name, various security-related settings, and so on.
Recently, I was involved in a project where the questionnaire had grown quite long. Originally, the questionnaire was a godsend—the chaos of emails flying around was replaced by a spreadsheet. Over time, however, the number of questions increased. New business requirements led to more questions. Each time a customer was permitted even the most obscure customization, that customization would soon be offered via the questionnaire. The logic was that if one customer needed something, future customers might need it, too.
Thus, the questionnaire had become long, complex, and full of obscure technical terminology that not every customer could decipher.
Now this godsend was becoming a scourge.
Where it used to take minutes to complete the questionnaire, it was now taking customers a week or more. The more questions, the more people involved in completing the form—and each new person added delays.
The other problem was an increase in requests for customizations that were difficult and laborious to implement. Yes, we can provide some obscure HTTP technobabble feature, but it requires a subject matter expert to step in and manually engineer it, delaying setup. What had been a special request from one or two customers with rare and unique requirements was now a “feature” visible to all customers.
Many customers would feel compelled to find technical subject matter experts who understood the question. Finding the right internal person could take days—so much fussing just to realize the feature was not needed. Salespeople would beg customers, “If you don’t understand the question, go with the default,” but that didn’t help. In enterprise computing, no option is left unconsidered. Worst of all, customers who did not need such features would request them more out of curiosity than need.
Many items in the questionnaire had become obsolete and should have been removed or rewritten. Unfortunately, there was no process for removing questions.
Restructuring the questionnaire.
Eventually, the team reworked the questionnaire. They divided it into three distinct sections: required answers, optional answers, and the secret menu.
The first section contained information that was always required. Lacking any of the required items was a blocker for the customer success team. When all was said and done, it was surprising how few questions remained in this section. Many questions could be moved out of this section once someone asked, “Are you sure it’s really needed?”
For example, as is the case for many SaaS products, the customer’s company logo is displayed in various UI elements such as the top navigation header. Conventional wisdom is that this logo is required. How could we possibly launch a new customer’s installation without it displaying their logo? It turns out, however, that is not a blocking requirement. In the absence of a customer-provided logo, a default generic icon is displayed. The customer could easily change the logo post-setup via the control panel on their own schedule. It was not a blocker.
So, the question was moved out of the “blocker list” and rephrased to say that “the logo is to be installed by the customer post-setup, but if you happen to have it now, attach it here and we will take care of it for you as part of the initial setup.” This sounds like a minor thing, but it was a big hurdle. At some companies, anything having to do with using the company logo requires weeks of approvals. You must meet with marketing, get approval from brand management, receive sign-off from legal, get a note from the CEO’s mother, and more, depending on the company. These approvals were a common source of delay. This delay, however, was removed because someone pushed back and asked, “Are you really sure the logo is a blocker?”
The second section of the questionnaire was a list of “typical options.” The team revised the questions to be clearer and more concise. All of them were constructed so the default was the preferred option. Someone could leave the section untouched and still be a satisfied customer.
A few of the questions originally targeted for this section were removed when we realized they reflected what was contractually obligated. We don’t need to ask how frequently a report is generated if the contract requires us to generate it every 30 days. The customer success team had been prefilling these fields to reflect what was in the contract, but that did not stop customers from trying to make changes. The ensuing confusion wasted time for everyone.
The remaining questions were for extremely rare options. Most of them required manual engineering to implement. While we could fulfill these requests, we wanted to discourage them.
Originally, we thought we would list them in a section with a disclaimer that discouraged customers from selecting them: “Please use the default unless you have a special need,” but that seemed rather unsociable.
Instead, we adopted a model used by some restaurants. Certain hamburger chains have a “secret menu.” These are items that don’t appear on the menu, but if you ask for one, your server will give you a knowing nod and deliver it to you. (A Web search for “restaurant secret menu” may surprise you with how common this is).
The remaining questions were removed from the questionnaire and placed on the “secret menu.” Employees were trained not to offer these customizations unless the customer raised the issue. The secret menu listed alternatives that could solve the customer’s problem in ways that the product could more easily support. “You need X? Would Y suffice because it is built into the product?” If the alternatives did not suffice, the request would be granted, although approval was required in some cases.
Restructuring the questionnaire into must-haves and options, plus having a secret menu, has greatly improved the team’s ability to set up new customers in a predictable and trouble-free manner.
Summary and Conclusion
Knowing what information you need before you begin a task, and having that information, is key to productivity.
On an individual level, it is the difference between Bertie completing a task quickly and Andrew requiring multiple days.
On a team level, it allows a service desk to start on a request right away, and not be delayed by many round trips of clarifying questions.
On an organizational level, it streamlines and clarifies complicated processes, improves communication, reduces confusion, provides a focal point for optimizing processes, and looks much more professional.
An analogy can be made to functional programming languages or anything that encourages code to be free of side effects. In simple terms, the easiest way to reduce side effects in a procedure is to assure it has all the data it needs passed to it from the start. This often requires a little foresight and taking the time to structure, and possibly refactor, code to make this easier to achieve. Similarly, whether you seek to improve on a personal, team, or organizational level, it can be valuable to pause, reflect, and refactor, so that you have all the information needed before you begin.
Gathering all required information ahead of time is not always possible. A task may be ill-defined or require ad hoc solutions. Even then, you can make sure the knowable elements are known before you begin.
The better you get at this, the more you can be like Bertie.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment