Project management is often more of an art than a science. While I do believe that statement is true, the particular turn of phrase can be very misleading. Many times, people use it to excuse general disorganization or a lack of discipline. But every good artist knows that without preparation, honed skill, and hard work, any piece is bound to fail. According to Michael O’Brochta, a senior project manager at the CIA, the art of project management is “about applying common sense with uncommon discipline.” In 1992, Democratic political strategist James Carville famously applied this type of common sense with uncommon discipline when he encouraged his candidate to stay on message by posting a large sign in their campaign war room that read “It’s the economy, stupid.” His plan worked, and come that November, his candidate was elected President of the United States. I think sometimes even veteran project managers (including myself) need just such a two-by-four-to-the-head reminder. When working on projects large and small, one thing is of vital importance. It’s the documentation, stupid.
Don’t Rely on Institutional Memory
There is a trend right now in agile software development calling for “barely sufficient documentation.” It’s a noble pursuit that strives to limit software documentation to just the bare minimum required to accomplish the job. Aimed at eliminating project bloat and unneeded paperwork, it’s very easy for inexperienced project managers or developers to fall into the “more of an art than a science” trap when subscribing to this philosophy. Of course, we should never create documentation just for the sake of creating it, but don’t ever let that be an excuse for relying on institutional memory to support your project. You might get away with it a few times, but sooner or later, it will come back to haunt you.
I’ve worked on many enterprise-level projects, and I can’t remember a single one where a stakeholder, developer, or some other crucial team member didn’t leave or get reassigned at some point before delivery. When that happens, and you have to ramp up new resources quickly, having the project well documented is an invaluable asset in your project management arsenal. New resources can be a pesky bunch. They always want to know what you are doing and why you made certain decisions along the way. They tend to second-guess tactics and often have their own way of doing things. This is good. A fresh set of eyes on a long-term project can be a godsend. But if those choices were made for specific reasons, then having that reasoning documented in a clear, easy-to-understand way will eliminate rehashing the same conclusions.
Laying a Solid Foundation
Project requirements are easily the most useful piece of documentation on any given assignment. On software development tasks, they are used by user experience architects and designers when deciding on how a user will interact with the software, they are used by developers when mapping out the system architecture and writing the code, and they are used by quality assurance analysts to test that the end product lives up to the original vision. In short, requirements are essential to any project, and having these requirements well documented, centrally located, and easy to understand will save your project time and money and it will save the project manager countless headaches along the way.
If you are a project manager undertaking a new enterprise-level project, I have a piece of advice for you: Find yourself a good business analyst and make them your new best friend. The project’s business analyst will save your bacon more often than you’ll want to admit. But don’t think that you can leave the requirements solely up to them. Project managers need to stay curious and engaged in order to understand the intricacies of their project’s requirements. Sometimes that means getting out of your comfort zone and learning new skills or educating yourself on new technologies. I’ve found that the mindset of a perpetual student is one of the most beneficial traits you can have as a project manager. And what did we all learn as students? Take good notes!
Think About the Next Guy
As a project manager, you can’t always count on being able to shepherd a project all the way to conclusion. Sometimes, for various reasons, you may have to transition your work to a new project manager. Even if you do make it all the way to the end, chances are that some other project manager will need to reference your project at some point in the future, either as a comparison tool for another similar project or to open a new project to make an update on the originally delivered product. In these cases, it’s good to practice the tried-and-true golden rule. Treat those project managers how you would like to be treated if and when you are in their position. The last thing you want is to have to spend time you don’t have digging through mounds of disorganized project artifacts looking for a method to the madness. So don’t put those who come after you in that position either. This is why closing a project is so important. Once you’ve shipped a product, it’s tempting to schedule a team happy hour and then sink into the blissful fog of completion, ignoring important documentation like lessons learned, finalized budget, and procurement reconciliation. All of these documents help the next person when they need to gain quick insight into how your project unfolded.
Also, likely as not, I find myself needing to reference one of my previous projects. Either I need to do an analogous estimate or create a similar project plan. There is something that I need to look back on, and having good documentation makes all the difference. Memory is a fickle thing, so don’t forget, sometimes the next guy might be you!
Projects come in all shapes and sizes. The Project Management Institute defines a project as something “temporary in that it has a defined beginning and end in time, and therefore defined scope and resources.” If we don’t adequately document the defined scope and resources, then we are dooming ourselves to failure. Some may think they are clever enough to hold all of this information in their head, but they are only fooling themselves. Just like the candidate needing to stay on message, project managers need to remember that to ensure an effective project, it’s important to remember what defines success or failure in the first place. It’s the documentation, stupid.
References
1. O’Brochta, Michael. “New Number One Reason Projects Fail.” Project Management Institute, Buffalo, New York Chapter.
2. Kennedy, Sheila. “A Forgotten Lesson: It’s the Economy, Stupid.” Research & Commentary, Inequality.org, November 12, 2014.
3. Bernstein, David. “Barely Sufficient Documentation.” Agile Zone, DZone, February 9, 2018.
4. “What Is Project Management.” Project Management Institute.
