Templates in project management. Breeding and keeping at home

Often the term "template" carries a negative meaning. Oh, these "template answers" ​​are excuses, "template thinking" is simplified, unoriginal. But in network planning, templates play a very positive role. I'll try to prove why.

But first, a definition. Template (aka "fish") is a typical schedule network schedule containing general information on the basis of which it is possible to develop a schedule network schedule for projects of a certain type. Thus, theoretically, the template can contain almost all types of data that are present in the schedule network diagram, except for the fact, basic plans and contractual obligations, and general project parameters. They are unique for each project.

Do you need templates? Not a fact. There are types of activities where projects are completely unique and never repeated. Or there is only one project and is not divided into standard blocks. Here, of course, there is no question of templates. But in most cases we had to deal with situations where the templates were relevant. Sometimes these are small projects with a couple of dozen lines, for example, describing the contracting procedure, sometimes real monsters of several thousand lines, with a complete description of the release of design documentation for a new high-tech product.

So what are the benefits of a template?

1. Reducing the development time of schedule network diagrams. Sometimes quite big. Once, at the request of the owner, we even had to compare the time it took planners to develop schedule network schedules based on a template and "from scratch." For projects with two hundred operations, the template on average accelerated development from 4 hours to 20 minutes. This was, of course, an extreme case, but the fact that the template facilitates the development of schedule network diagrams to one degree or another is obvious.
2. List of uniform milestones. How amazing it is sometimes that planners are able to name the same events in their own way. It would seem, for example, that the moment of signing an agreement should obviously be marked with the milestone "the agreement is signed." Well, no, the intensity of creativity knows no limits! Here you get "the contract is closed", and "there is a signature in the contract!", and simply "the contract", and much more. This whole zoo looks wild in a report on milestones for a portfolio of projects. In general, if all important milestones are formulated in a template, TOPs will have fewer questions.
3. Unified work structure. It would be great if at least the structure of the first levels of work has standard names. Of course, projects may contain unique work structures. But the general principle of organizing the structure of work, embedded in a template, for example, "First by type of work, and then by object," will help a lot.
4. Interchangeability of planners. There was a recent case when the planner interrupted the development of the schedule network schedule due to personal circumstances and there was no communication with him. We did not know which parts of the schedule network schedule had been developed and which had not. It took longer to check than to write again. As a rule, in a well-written template, it is clearly visible where the planner has already worked, and which parts still remain typical.

How to write a good template? It would seem that take a good completed project and use it as a "fish" for new projects. However, it's not that simple.

1. First the obvious. All traces of updating should be removed from the schedule network schedule - all actual data, time restrictions, interruptions, baseline plans. (If the Project Server platform is reporting performers through PWA, remove the damn information about assignment owners).
2. Clear project specifics - project-level fields, for example, with the contract number, clear deadlines for Project.
3. Carefully check the names of the operation and the hierarchical structure of the work for the presence of specifics from the previous project. Once I missed the task "Development of the KT37/09 block" in the template. Then, a year later, there was a terrible commotion - everyone was looking for the ill-fated KT37/09 block until they found out that it should not be developed in this project. Usually, when I get rid of specifics in a template, I don't make an omission, but draw the planner's attention with asterisks - "Development of block *******Enter the name of the block*********." Asterisks in the names of works and resources are generally a useful thing. If a lazy planner simply took a template, entered the current start date, a new name, and did not even bother to read the contents, the asterisks, or choose some special symbol yourself, will tell you that the schedule network schedule is not ready yet.
4. Replace regular resources with role-playing ones. No specific employees in the template, otherwise they will always receive new assignments from all new projects and lose their will from an unimaginable overload.
5. Breaking is not building. It is easier for the template user to delete a work package if it is not needed in the current project than to create one. Of course, here you need to know when to stop, but, in my opinion, if there is a 20% chance that a package of work should be in the project, I leave it. True, with a note - "Under such and such circumstances, remove the package."
6. Some redundancy of connections. The question is ambiguous. Usually you have to deal with redundant connections. For example, if 3 tasks are connected sequentially, it is stupid to also connect the first task with the last one. This only clutters up the schedule network diagram and does not provide useful information.

However, if there is a high probability of deleting the "Purchase of missing materials" operation, as in the example given, it is worth putting another connection between design and assembly. In this case, when a purchase is deleted, the project will not fall apart into two independent ones, and the extra connection will preserve the logic. (The example is simplified. In real practice, instead of individual operations, as a rule, there are entire packages of work). Of course, you shouldn't overdo it here. Personally, I have a simple rule. If, when checking the schedule network schedulers that used the template, I find a loss of logic a couple of times due to the removal of an extra package of work, I go into the template and put in a redundant connection.

1. "Are there many templates or one common one?" The question is often asked. We have several types of projects, slightly different in the composition of operations. "What is better - to create a universal template or to create your own for each type of project?". It would seem that it is easier for the user - use the template of the desired type and there are no problems. However, it should be remembered that if there is a need to change a part common to all types of projects, you will have to go through all the templates. Practice shows that it is not always possible to sift through all the templates; some templates remain unchanged, plus some existing planners rivet their templates and the mess grows, like entropy in the universe.
2. The template needs to be grown. It is impossible to write a template well right away. The technology for implementing the project or its scope, requirements for detail, resource, and financial planning may change. Integration modules or new reports may appear that require template changes. Often an idea just arises on how to simplify the schedule network diagram. One way or another, the pattern will DEFINITELY change. And this process cannot be left to chance. If the template is not modified, it will soon become obsolete and no longer used. If all users are given the opportunity to change the template, it will quickly be destroyed or a lot of copies will be made. The advice is simple. A template must have an owner. (It is highly advisable to place information about the owner in the template). The owner will be able to ask questions about the template, send comments and suggestions for improvement. The regulations must provide for a procedure for modifying the template. For example, the user had an idea to add a certain package of work to the template. The user sends a change request to the template owner, who approves the change, if successful, makes changes to the template, and notifies users about it.
3. The template must be understandable and accepted by users. This is an important factor. A client who had a project management information system (PMIS) implemented a year ago once asked me to write an integration module. And at the same time, see the current state of planning. I immediately saw that not all users use the template. It turned out that one did not know about the existence of the template, the rest did not use it because "everything is confusing there," that is, they did not understand it. The problem, of course, can be solved with an administrative order - "Everyone use the template", but this will not improve understanding. In order for the template to be understandable, it is necessary to write it together with future users, licking the wording of the names, the logic of the work, and discuss the template with the maximum number of users. I remember for one design institute I had to tinker with a template for several weeks, consulting with many employees. At the end of the cons, when I heard that among themselves they began to call the template "Our template," it became clear that there would be some sense. For those who were not affected by the discussion of the template, you should write an explanatory note to the template. Usually this is a small document describing the general structure of the template, itlogic, explanations of individual non-obvious elements, recommendations - what and where to remove and add when developing a schedule network model based on this template. I don't want to say that I write an explanatory note for all templates. The recipe is this: if the template is complex enough for a beginner to have difficulties or questions, I outline the answers in an explanatory note.
4. "Keyboard player" or "Subject specialist", who should write the template? Let a contractor or in-house IT department deploy a project management information system (PMIS). Made the necessary settings, built an analytical reporting system based on the manual's sketches. You can also entrust them with the development of templates. This solution has disadvantages. An IT department employee, and even more so a contractor's PMIS specialist, has a very general understanding of the subject of planning. We call such people "keyboardists." (Oh, and they beat me up with rags once because I mixed up the flaps with the slats in the wing of the plane). A "keyboard player," even if he has honestly studied industry standards, will make a lot of mistakes regarding the specifics of the subject. Besides, who among us has not been captured by professional arrogance? "Fee," the internal specialists will say, "what good could this computer guy write?" And they will defiantly ignore the template with all their might. On the other hand, a specialist in the subject area (we will call it a subject specialist) cannot always write a sensible template. Firstly, he is probably very busy with projects, and when he is distracted by additional work, it is not a fact that he will try. Secondly, the subject teacher recently learnedtool and, of course, will demonstrate the entire arsenal of mistakes of a novice planner. At the same time, spending a lot of time and effort. Thirdly. The main fun begins when the second subject teacher arrives and they begin to argue among themselves about how to carry out the work correctly. Here it usually turns out that GOST says it's not right, and in the last project we did it wrong, etc. The teachers who during the lesson tried to impromptu, at the prompting of the group, write a real case, I believe, understand me well. The battles are being played out in earnest. This is where it is important not to lose the initiative. The disputants must be brought to a compromise; no one should leave offended. Remember, the template will be implemented only when users start thinking about it "Our template". Therefore, the ideal option would be for the "subject specialist" and the "keyboardist" to make a template together. If this does not work out, then it is easier to teach a "subject specialist" the intricacies of drawing up schedule network schedules than to teach a "keyboardist" the intricacies of the subject of planning. At least here at PMExcellence, as a rule, employees from industries (construction, manufacturing, oil and gas, energy) are hired as planners, sometimes without experience as a planner.Then they fall into my clutches, where they learn to plan in everything they plan, after which they begin to work in teams in their specialization.
5. The template does not have to be similar to the project. The template is a planner's assistant. Feel free to write useful information for the planner in your notes. For example, "Create prescriptive control points here. Open the contract, enter all the obligations that are indicated in it as separate milestones. In the title of the milestones, be sure to indicate the item numbers from the contract. Enter the dates in..." Hyperlinks to sources of information, regulatory documents, and instructions for developing a schedule network schedule are completely acceptable. If I don't want the instructions to be in the schedule network diagram later, I place them in a task called "***Hint. Erase me ***."

Conclusion. Templates, if they make sense for your purposes, greatly enhance the viability and usefulness of your project management information system (PMIS). Give them due attention.