Excel, and the spreadsheet applications like, are incredibly versatile tools. In addition to the regular tabular math, you can generate all sorts of diagrams, apply logic to cells in order to modify their appearance and basically create and manage all sorts of workflows around table data. These tools are veritable swiss army knives of corporate data wrangling.
And, as it usually is the case, if a tool is flexible enough then people will try to use that tool for just about everything. I'm an Emacs user, so I should know.
So, therefore it's now surprise that Excel (and even PowerPoint) have become tools that software project and product managers use to handle things like release planning, task tracking and various checklists. And of course rarely do all of those things go into a specific Excel spreadsheet, but instead they are spread across a dozen or so Excels, many of which get cycled out after a release in order to product new ones for the next.
Hell, when I was doing my software engineering project course in university, we used an Excel spreadsheet to keep track of our user stories and the number of story points assigned to each one. I even wrangled it to produce a burndown chart for each sprint to keep track of our team velocity.
However, this approach is problematic for a number of reasons. The first reason being that Excel is not a standard, acceptable ticket tracking system. Especially in the corporate world there are some things that you as a software engineer are just expected to use. In my case for ticket tracking it would be Jira. I would have to use Jira even if the project manager decided to do everything with Excel or PowerPoint (and trust me, it took a while to convince them to move off of using PowerPoint as a status tracking tool), because there are teams we have to interact with that mandate use of Jira. We have a bunch of internal processes that absolutely require using Jira.
Secondly, keeping track of those Excels becomes really painful, unless you somehow manage to get everyone to agree to one God Excel, where everything project management-y goes. Otherwise developers are endlessly digging through an ever-growing pile of spreadsheets to try to find the right bit of info or to update the correct field. Presumably you could somehow structure the Excels into a directory structure that follows a pre-defined system that makes it easy to locate up-to-date information, but considering I have yet to even see a properly organized Confluence site, I have my doubts about how reasonable that expectation is.
It's also really easy to mess up an Excel like that, because although you can add some logic to somewhat guide the user to populate all the mandatory fields accurately, in practice people are rarely that good at making Excels. And the more complicated the Excels become, the more likely they are to eventually collapse under their own weight, because nobody can figure out the cell spaghetti to fix something that broke or to recover a formula that somebody accidentally pressed delete on. Excel just isn't designed to make software and sometimes what you need is software.
So, what does this mean for the daily life of a lowly software engineer? Well, often times it means that we have to deal with duplicated information and sometimes are required to duplicate that information ourselves into rickety spreadsheets and slide decks, because PMs either don't know how to Jira, or they just find it so much more convenient to shadow IT their own systems on top of Office 365. Release requirements require memorizing and/or bookmarking the right files that were probably sent to via email 2 months ago in order to figure out what the release requirements even were, which you then have to transcribe into epics and user stories into the ticketing system so that you can actually declare your dependencies, get them into your team backlogs and eventually push them through your sprints or kanbans.
It's an utterly frustrating experience and it basically guarantees that PMs aren't looking in the right place for the right information. How many times must we go through a weekly status check of going ticket by ticket to figure out if the task is done or not? It's all in Jira! Hell, if we are particularly clever we can even tell GitLab to close the ticket for us when the relevant merge request is merged in! But that doesn't help one bit if I then have to find a damn Excel so that I can manually find the right requirement item, which probably wasn't even properly broken down into a story-sized chunk, and then figure out how to mark it as done there.
And I am sure this kind of shadow IT is providing cover for real issues. I have a few guesses why people insist on making Excels rather than filing things in Jira, but instead of making sure our Jira isn't full of garbage and doesn't run slow as a snail, we are pretending everything is fine by working around the problem. I bet the same applies to other fields too, where insufficient software support and poor quality IT systems are being worked around by employing industrial levels of hacked-up spreadsheets to as pretend-software, with the above caveats of information duplication, information loss and poor user experience.
The number of management spreadsheets ought to probably be close to zero, especially in a software project developed by a software company that already has software for managing software projects. If that software is not usable for that purpose then at the very least buy or deploy a new one and make sure the entire project uses that one and only that one.
The Excel must die.
>> Home