I periodically reread the classic texts that shaped my education and my work. The reasons vary; I’m curious about how they’ve held up over time and what I find now with over twenty years’ experience. One of those texts is The Mythical Man-Month: Essays on Software Engineering by Frederick P Brooks, Jr. It was a classic on project management when I first read it in 1999.
After growing fuzzy on some of Brooks’ assertions, I reread it this month. I like to see how my experience has changed my view and understanding of the text. This time I was also curious how my reading would change given my focus on teams of one.
One paragraph made me pause and it became the focus for this post. For today we’ll ignore the rest of the chapter and the book. There’s a lot to unpack within the text!
In chapter 7, Brooks explains his reasoning as to why the tower of Babel failed. The tower had everything a successful project needed: a clear mission, plenty of workers and materials, no time constraints, and technology to fit the design.
What went wrong? Lack of communication and organization.
The solution Brooks proposes is that the team should communicate frequently using multiple methods — informally with quick calls and with regular meetings. All communications should be organized into a formal project workbook. This will hold everything from specifications to documentation and administrative memoranda. Now I know where I first acquired some of my methods.
How can you solve communication and organization issues in a solo project?
It requires dedication and determination. I will admit I’ve often skipped this claiming “well, it’ll only bother me so why bother, I have things I have to do” and I know that it is a key reason why projects have gone sideways.
I’m not one for calls of any sort, however, I am not shy to admit that I often talk to myself while working. Does that count as informal communication with myself? Yes and no. I like this to all be in writing so I can review it later. I keep paper on hand to scribble small notes and refer to them during my review sessions. Sometimes I keep a text file open to paste in URLs or copy whole chunks of text from a webpage — “check how XYZ works” “ABC is updated, that changes function PDQ!”
Regular meetings for a solo team happen in two forms: scheduled review sessions and status updates sent to the client (if applicable). During these I answer the following questions: Where am I on the project timeline? Have I failed to meet a deadline? Why?
The formal project workbook takes a different form than how Brooks initially envisioned it. Files are now digital, so they no longer have the same gravitas a huge ring binder of notes and documentation did — but they serve the same important purpose. Each project I work on gets its own folder in my file system and I automatically crate at least three additional sub folders. The first is “admin” which stores a copy of the contract, the spreadsheet of my time record, copies of invoices, etc. Next is “docs” and here is where the documentation I write specifically for the project resides. These are often what are created for clients’ use. Finally, the “notes” section stores copies of key emails, meeting notes, and my working notes. Yes, I copy and paste the text of critical emails to a file and store the information there. In notes is where I keep a document that records items I don’t need a direct copy of, for example — a list that shares URLs of files I don’t need to keep, such as links to software or plugins.
Three ways to organize your project communication:
1. As you begin a working session, keep scrap paper handy to scribble those thoughts you need to check or want to explore in detail later. It’s ok to keep this as a digital file too, I like to use plain text as it prevents me from falling into a formatting trap.
2. Schedule a regular review time for the project and put it in your calendar as a legitimate appointment. I keep my general time blocks as a separate calendar I can filter at need. Experience is that it makes it very easy for me to ignore review sessions.
3. Store all information related to the project in one place — or as close to one location as your digital ecosystem allows. Create a main list for items stored elsewhere.
I hope these three tips help you to begin to plan and organize your project communication.