Best practices for backing up the documentation of an IT project

There are good practices and best practices for backing up the documentation of an IT project; just as in everything else.

In the first two posts of this series about IT project documentation, we dealt with the “what” or what to document and the “how” or if you prefer the format you should use.

In this post, we will not discuss the “why” but the “where” to save the documentation.

If you think this post is the poor little brother of the two previous ones, think again. Too often, the IT Project documentation is not consulted because it is not easily or readily accessible and, for the same reasons, the documentation is often out of date.

To determine the right place to save your IT Project documentation, there are 3 factors to consider:

  • What documentation must be made available?
  • Who are the users or readers?
  • What is the frequency of consultation (reading and updating)?

(more…)

IT Project documentation format; best practices

What is the most appropriate IT Project documentation format? And, what are IT Project documentation best practices in terms of format?

The question may seem strange because, for many, this question does not even arise. But on closer inspection, it deserves to linger; how should I document an IT project and with what type of format?

To highlight the challenge of an IT Project Documentation format, there are three factors to consider:

  • Object of documentation
  • Who is it for?
  • Who is it produced by?

(more…)

IT Project Documentation best practices; the object of documentation

IT Project Documentation Best Practices are not simple because the purpose of the documentation is not always obvious. First, in an IT project, you can find a lot of different documentation; the famous user manual, the requirements documentation for the software operator, the architecture and design documentation for analysts, designers and developers and the technical documentation or software documentation for programmers are the main ones examples.

In short, Documentation is like insurance, you need it but you must find the right balance.

As far as we are concerned, we will talk about the architecture and design documentation and the technical documentation of an IT development project. So, what should we document?

In this series of posts, we will address the following points:

  • What should be documented in an IT project?
  • How should we document it?
  • Where should these documents be made available to different readers?

(more…)

Process Performance and Innovation, a bond of heart and reason

Process performance and innovation create a bond of heart and reason within any flourishing business or, at the very least, any enterprise must become innovative in order to flourish because innovation almost always leads to a gain in performance on one level or another.

Thus, the company that wants to perform must innovate and the innovative company will perform… most certainly!

(more…)