Everyone knows Excel, everyone can operate Excel, and everyone has Excel installed on his or her workstation. Creating tables is easy, as is using worksheets and adding formulas. There are many good reasons to use Excel. I use Excel, too. Privately. But it would never occur to me to use it professionally. I’ll give you 3 reasons why I never missed Excel in my own project work. And why you won’t miss it, too.
1. Excel Is Not Made For Team Work
Imagine you are working in a project. Each team member has different tasks and skills, different roles and rights. The project has been running for a few months now. The goal is to develop a product, e.g. a coffee maker that features software and a display showing water and coffee quantity. To-dos are agreed on quickly and recorded in an Excel file. A second file lists all requirements to be realized. Previous projects have been organized this way.
When you are working in a team it is of utmost importance to know who has the latest version of an Excel file. Yesterday the file was sent via e-mail, then a colleague changed something in the file, another colleague has accepted a new requirement from a client and you are still using the version from the day before yesterday. Of course, sending Excel files via e-mail is not the ideal way to approach projects. You can always store it on a common server with shared access for all team members. But this poses problems, too.
How is access to an Excel file stored in a central database managed? How do you know if someone else is making changes to the file at the moment? If two people are making changes to the same file whose changes will be saved? Do files have to be merged?
Let’s look at rights management of files in Excel. Is everyone allowed to make changes to the file? Maybe the file should be secured by a password. While you’re at it, why not lock individual cells. Accidental deletion of would be a thing of the past. But what happens in case you forget your password?
You see, working in a team with multi-user access can be difficult.
2. Excel Does Not Establish Traceability
Requirements in our coffee maker project change frequently. Naturally, the Excel file is versioned on a regular basis, producing file names such as “2014-08-18 Requirements Coffee Maker with Grinder Version 1.5.xls”. But is this the latest version or is there already a version 1.6? And how are changes to individual requirements documented in this file? Should we add another line for new requirements? Should we delete the line containing the original requirement? Should we just overwrite the requirement? How many lines can we add without losing overview? The problems don’t stop there: How do you know who made the changes? Well, you can always add another cell and note down the author (and the date) but the e-mail address of the client would also be helpful and…well, you get the idea.
This is all very complicated and definitely not intuitive. And there are industries that rely heavily on meticulously documented processes, e.g. the medical field. Excel should definitely not be an option there.
3. Standardization and Typification
Have you also created tables in Excel with links and functions? Can you remember how exactly you did it months later? Of course it is not just a problem of working with Excel if there are no standardizations in projects and different priorities are used in the same project, e.g. “critical” and “normal” vs. absolute priority values vs. none at all. In addition, typification of information managed in Excel is in most cases not existent. Typification provides for unique IDs and provision of names. You avoid misunderstandings, facilitate compliance with project standards and automate operations.
No capacity for team work, no traceability, no standardization, no typification. Anything else? What about relationships between requirements and test cases? If requirements change, so do test cases. Do you manage test cases in the same Excel file? Do you approach changes to test cases the same way you approach changes to requirements? So a test case can be found in the same cell as a requirement? How do you group test cases to test operations and how do you record individual states of test cases?
Displaying complex information in Excel is difficult. Not to mention including additional files such as pictures, drawings etc. as references. The amount of information per object is simply too big to display them in a useful way in Excel.
The result: Unneeded communication, less project work
If access to information is difficult, if traceability is not existent, if relationships are unclear and no standards are set the need for situational communication grows. In this case, communication is a bad thing because it does not lead to anything. It does not add to a project’s success but serves only to fill information gaps when really content should be the focus. Also, missing information leads to bad decisions that endanger the success of a project.
Can you think of other reasons not to work with Excel? Do you have a different opinion? Let’s discuss it …