How to Issue a Data Call
One of the first tasks that junior project managers get assigned is to issue a data call to project stakeholders. The data call can be as simple as compiling a one-off phone list, or it may involve recurring requests for schedule and/or financial information. Most find the task of developing a data call unimportant or unexciting, so they carelessly cut corners to issue the request as quickly as possible. The outcome? Stakeholders get confused. They provide incorrect information that requires additional processing time or, worse, merits repeated requests for follow-up. While the task may not seem that important, suddenly it has turned into a time suck that slows down the pace of the project and has needlessly annoyed the requested respondents. Here are some suggestions for issuing a high-quality data call:
Clearly communicate the request for information. Have you ever received a data call email that’s three screens long, replete with red text and yellow highlighting, and the instructions clearly haven’t been updated since the data call was instituted? How about one where you read through five paragraphs of background and still have no clue what you are supposed to do? Focus on making your data calls succinct, with an initial paragraph explaining what is needed, why, and by when. If you state your bottom line upfront, then you can give additional details in the supporting paragraphs for those who care for more context. You might wonder why people seem to be incapable of reading their emails. Why expend this effort for something people should be doing anyway? The reason is simple. If you have an email in your inbox that’s five paragraphs versus one that’s two sentences, which email are you more likely to answer first? Combat human nature by artfully constructing your data calls to elicit a faster response.
Simplify data processing.
Create a template to intake the information. Design a template that ensures you receive the requested information in a consistent format. If you’re issuing the data call in Microsoft Excel, use protected cells to guard information that you do not wish to alter. Apply data validation rules to force your stakeholders to choose from a pick list of standard values. Use conditional formatting or versioning history so that you can confirm once your stakeholders have completed their inputs. In Microsoft Word, give examples of the type of information you are seeking to make it more likely that you won’t have to spend too much additional time formatting the inputs once received.
Use a file sharing repository. If you’re still issuing data calls via email and manually compiling the responses into a single file, please stop. Immediately. It’s 2019. File sharing exists! The software even lets you see what changes were made since the last version so you can readily tell when stakeholders have completed their inputs. I’ve had folks tell me that they don’t trust shared files because, sometimes, the file gets corrupted, and it crashes. If you’re really that worried, set the backup frequency at a higher interval and back up the file to your local drive. IMO the risk of wasting time and money manually compiling inputs outweighs the risk of your shared file crashing. How many times has a shared file crashed? How many hours are you spending on formatting when you could be spending them strategizing? If you’re truly trying to get out of the business of making “boring” data calls, you’ll want to make a change.
