Lessons from a Huge Project at Work

There’s probably an unwritten rule (and if not, there should be) that the amount of documents needed for a project is roughly equivalent to half the number of people working on the project. Our department alone is about 20 folks, and for a recent big project we need to work with other divisions, so at this point I can’t even tell you how many documents we need to keep track of.

Usually, I use org-mode for everything. But this time I was foolish enough not to…

In the beginning, there was one email and one spreadsheet. The spreadsheet was a list of inventory items that needed to be tested; the email contained a generic workflow for the testing that needed to be done.

Problems started when I tested the workflow and found it to be flawed for our work environment. That meant I had to communicate it to the department in charge of that workflow, going through the appropriate channels. Communication, as it usually happens when there are many people involved, failed. I should have picked on the inevitable signals right then as I have many times in the past, but I didn’t.

Instead of creating notes for myself in org-mode about what I encountered, why there is a problem, what’s my workaround, who are the people I need to contact and when to expect an answer, I just brought the issue up in a meeting and otherwise kept to my own devices.

We have many collaboration tools at our disposal at work. A note in Onenote or a reminder in Outlook Calendar could have helped, perhaps a follow-up in one of our generic project spreadsheets which describes roles and issues. The problem with all of these is that they are collaborative tools which we have been over-using already.

I’m not saying there’s anything wrong with teamwork or collaboration. I work in a unit of people, and we all count on each other. Integrating a new large product into our environment which we know close to nothing about has to include other people who understand it. Communication needs to happen so we can discuss the problems and find solutions.

The choice of what to collaborate however, what tools to use, how to communicate and when, that’s where there’s a problem. that’s because one person is used to emails, while another prefers phone calls; I like org-mode while one of my teammates still prefers to write by hand; management likes meetings and generic timelines while we prefer workflows and specific solutions. You can’t have one source of communication used by 20 people and have 20 people 100% satisfied with it. You are the only person who should organize your stuff, and it is up to you to bring your points to the agreed-upon public medium, whatever it is.

That’s why there should always a draft before there’s a report, an agenda before a meeting, an outline before an essay. No one should have access to your notes because if they do, they immodestly become “contaminated” by their thought process.

I should have used org-mode and I didn’t. So, here is a reminder for myself, and perhaps for you, too. My workflow for dealing with big projects, in steps:

  1. Create a task: this is the start of any actionable item, often before I know it’s going to turn into a project.

  2. Look at the task and realize it needs to be broken further down: The breakdown can happen as I work on it or before I start; either way I record what needs to be done or was done in sub-tasks.

  3. The main task changes its keyword from “TODO” to “ACTIVE”, this means to me it’s a project. It does no longer has scheduled time, but timestamps which I stretch from day to day or week to week, as I work on it.

  4. If the project is very large or involves a lot of people and meetings, I usually create another sub-tree without a keyword called “log” and keep it on top. This log contains non-agenda dates of when each entry was entered.

  5. If a project contains a log and several sub-tasks, I will create a separate org file just for it. This will keep it in context and possibly can be used later to export should I need it to.

Usually, my projects end at step 3. I later go in and change from “ACTIVE” to “DONE” when the project is finished. Steps 4 and 5 are reserved for larger projects which are usually measured in months, not weeks.