The Power of Project Documentation

Working in the Tech industry, I noticed that a common problem which frustrates all developers is the lack of Project Documentation.

Starting to work on a new project with less or even none information about what the software should do, has a negative impact not only on the quick ramp up of the technical team but also in the future of that project.

There’s no doubt that project documentation is a vital part of Project Management. That`s why, the Project Charter, Requirement Specification, Design Document, Work Plan, Traceability Matrix, Test document, etc. build a great project documentation, which ensures that:

• project requirements are fulfilled
• every change in the system is tracked: What has been done, Who has done it, and When it has been done.
• the project is built faster and better because the business logic is well known and documented
• businesses save money and time on long run  
• you`ll always have a reference point, especially if the original team is not working any more on the project or new people join to it.

To operate efficiently, it is important that the project manager stays focused by setting priorities and keeping project data organized. 

I also understand that from the business  perspective,  every  owner want  their  product to be delivered faster, that`s why avoiding some steps during development it`s  something normal in every project.

But sometimes, too many processes are viewed as useless and the belief is why waste time on planning when you could start  immediately build  the  product.

That`s why in big projects this situation gets out of control, and the owner ends up with a sophisticated product that no one knows entirely what is doing and starts to spend more money on maintenance  and bug fixing than on the actual development.

During the life cycle of a typical project, a project manager can produce up to fifty different types of documents to facilitate the planning, tracking and reporting processes.

But of course, no one likes to read hundreds of pages in order to do a 10 minutes bug fix.

That`s why the documentation should be:

• Clear – The information must be organized logically, avoiding long explanation that may confuse the reader.
• Easy to understand – Format and layout must be easy to scan and read.
• Effective – The documents must contain only relevant and accurate information, especially User requirements, System Architecture and Design.
• Up to date – The team should always have the latest version .

The fact is, the way project documents are managed by project leaders can either be the driving force behind a project’s success or the bottleneck which leads to delays, exceeded budget, over-engineered products or even worse, a useless software.

And one last bit of advice :

It doesn`t matter if you are a Developer, a QA, a Project Manager or anyone else, as long as you are involved in a project, and you care about it, try to keep at least some notes/comments related with what you`ve build/tested/planned and let the others know about that.

In the long run, even simple and cheap techniques can make a big difference.