The technical concept is to the solution architect what the project order is to the project manager. Why some projects falter here as well.
Project managers often find themselves in situations where they have to manage a project which is not the first of its kind in this organization. As befits a good organization, there are of course more or less formal lessons learned from previous projects.
A very popular – and sometimes dangerous – lesson is: „We need better documentation“.
He who writes, stays
The topic of documentation always becomes dangerous when „good“ documentation is equated with „detailed“ instead of „appropriate“. There are various tasks that documentation must fulfill, but none of them should be:
There must be as much documentation as possible.
The project phase in which documentation is primarily generated is the development of the target concept (design). Here, the goals of the project are first translated into requirements for the solution, and then, in the second step, the future organization, processes and technical structure are defined.
Accordingly, we normally have 2-3 concepts that need to be created one after the other:
- organizational concept – contains target specifications for future organizational framework conditions, responsibilities, resource requirements (process-generic)
- functional business concept – contains target specifications for future processes, the interaction between the participants and process inputs and outputs (implementation-independent)
- technical concept – contains target specifications for technical implementation, often based on existing development guidelines (system-specific)
All three should contain the necessary content to build and test the solution and finally transfer it to productive operation. But that’s all.
The right measure
In the course of a (multi-year) project, vast amounts of information naturally accumulate, and this should not be lost if possible. This ranges from meeting notes to training documents. However, the official project documentation as a project object (new German: „deliverable“) should only deal with these topics to the extent that it is absolutely necessary for the performance of the project tasks.
Of course, the company-specific requirements should also be taken into account here; a small startup may have different ideas about methodology and scope of documentation than a global pharmaceutical company. Apart from these organizational framework conditions, however, only the functional requirements should determine the extent:
- in the context of the build (solution implementation), it should serve as a guide for the developers and decision-makers as to what the future solution will look like
- during testing, the built solution is compared with the documented solution
- during cutover (go-live), the documentation is then used as the basis for communication (basis for training documents, process instructions, etc.)
If, in addition, form or content is required, it must be vigorously questioned what added value this additional effort is worth. After all, your project team has other tasks than writing text.
A legitimate question might be: „Be specific, Mr. Scharr! How extensive should it be?“. The answer is not easy to give, since the company, project and process are of course very individual. However, I do not want to withhold one house number from you:
- for every averagely complex process, a documentation volume of 1-2 DIN A4 pages has proven to be reasonable
- Possible contents of the documentation can be
- Process diagram for graphical representation
- Process requirements, process input and process output, process participants, process steps
- Technical implementation, interfaces, authorizations
- The terms can be abbreviated and technical, it is about an efficient and precise description of the target.
- Prose is to be avoided as far as possible, just as redundant representation in graphics and text.
- Ergo: Project documentation is not user documentation, but project documentation by experts for experts with a limited life span.
- Project documentation can later be extended / transformed into solution documentation for operation
And the exceptions?
Of course there are exceptions, and every project team would do well to align itself with the individual organizational and legal framework conditions.
In the best case, there are binding project guidelines from an internal PMO organization that very clearly specifies to you as the project manager what level of documentation is expected. If this does not exist, develop a proposal together with the team and submit it to the sponsor for a decision. Once this has been agreed, you will at least have reached a consensus within the framework of the project organization.
Ultimately, every attentive project manager with a penchant for de-escalation is advised to agree on this topic and look for sensible solutions without falling into dogmatism.
However, if your project goals are in danger due to spontaneous ideas of third parties, make this clear very early on so that no surprises arise.
Good luck with this,
