Management of projects carried out for government organizations. Small conclusions

This post is intended for novice project managers and project managers who first begin working with government agencies who intend to conduct projects more difficult than a business card site and plan to continue working with a government agency, which will require not only completing the project, but also creating a favorable impression. Projects in which money is being cut for air are not considered in this post.



These are small conclusions made on a small personal experience with government agencies, and do not claim to be true. In the near future I plan to switch to work at a government agency, so wait for another post about building work from the inside.

0. Prior to work

If possible, try not to take up image projects that are not profitable for your employer. In such projects, the company is involved in making connections and obtaining future contracts. This is fraught with severe cuts in resources, and even with the project’s initial estimated profit of 0, any change in requirements will result in a review of everything and everyone. And the project is carried out within the framework of Fixed Price. The other side of the medal - the positive completion of such a project with a correctly constructed model of behavior with the customer brings you, first of all, +100500 to the reputation and respect from the customer. (Example from life: PM with a good reputation from a large state organization in the future was regularly involved as a consultant, which gave him a sour profit in the form of money and professional connections).

1. Getting Started

Signed a contract, you must start work. Your first step should be signing the rules of engagement. This document should describe:

')

• the composition of the working groups on both sides, indicating the position and role in the project;

• persons entitled to sign documents, indicating which person signs which document;

• rules for organizing meetings, conferences, etc .;

• the order of access of the Customer’s employees to the internal documentation and other resources of the Contractor (for example, the customer may request access to the versioned source code repository or bug tracker);

• deadlines for consideration of correspondence of various importance;



After signing the rules of engagement, you can begin the survey and collection of requirements, i.e. launch analysts in the work. TK and specifications prepared for the competition (unless of course they were not prepared by you or your company;) let the analysts, but you cannot rely on them. A new TK must be prepared. And here is a simple rule - the more detailed the TK is, the cleaner the ass will be, it will be easier in the future to enter work with the Customer. In my small practice there was a positive experience of a bad (and their) good analyst. One analyst can participate in the project on the side of the customer (to represent it). The same person should work on the project with the thought that he will hand over / implement / support this project. The motivation for this analyst can serve as enrollment in the customer’s staff with a small salary (assuming good relations with the body), the likelihood of project development, accompanied by career growth (a real opportunity from the analyst at PM), obtaining a good initial managerial position in a government body (if the key project for the state body).

It is also necessary in the company Customer to find people who are really interested in the project. Most often, these people work as simple specialists or, in contrast, as heads of departments and departments. Heads of departments - rarely your goals. Interested people are people whose work will be simplified and becomes more efficient. More likely you will find one such person. Ask to familiarize you and your team with the history of the information system or an order for it. Orders do not appear by chance, they are preceded by any regulatory documents, lowered from above. Therefore, you will understand the basic business requirements that are necessary for the state, and not what a person assumes who may not understand this at all.

2. Signing technical specifications

The terms of reference, despite current trends in management, planning and development, should as accurately as possible describe future development. In the case when, according to the rules, a person who consciously or unconsciously demands to include or exclude information in the TZ written by you (the company-performer) should sign the technical task, agree. Send the original TK by official correspondence, in the modified TK at the end we attach a version history sheet, which indicates why the TK was changed.



This method can also be used in the coordination of CTZ, if you have the resources for all this clerical work, and your development and project management methods allow you to use this method.

Remember, if you did not take into account any item in the TK or wrote very vaguely, but this item is in the specimen of the contract during the competition, the customer can love you on this issue as he wants.



Also, the work schedule should be attached to the TOR. Will it be a Gantt chart or just a table with points and an indication of the start and end of work - you decide. But it is advisable to sign a Gantt chart to further visually explain to the Customer the consequences of the changes. Consider that the schedule for the customer and the internal schedule of the schedule are two different things. In the schedule for the customer deadlines should be at least until the end of the contract. This will allow you to receive fewer requests for changing functionality, plus having a time buffer for all abnormal situations and delays. And remember, when you send a modified schedule to the Customer, see what you are sending so that there are no unpleasant incidents.

3. Project implementation and reaction to changes

What development method to use and how to manage the project is your own business (or of your company). I want to touch the reaction to change more. In the case of working with government agencies, one cannot think only about the quality of work performance and product sales. From the point of view of your employer, you must fulfill all obligations under the contract and make a profit for the enterprise. And try to justify it, even if you have to lie to steal, kill for this. To any official request to change the functionality immediately reply with an official letter that you will immediately begin to consider this request. Even if you have a buffer in time and resources, do not accept the application to work. Collect several applications, if possible, and assign a meeting to a working group (imagine that you are taking revenge on officials for bureaucracy). At the meeting, your policy comes down to the following: you, as a project manager, see that:



a) this and this application must be implemented, and we will reluctantly do this in the name of good relations. But please be more kind to us. (In this place we hang up a good analyst, in theory)

b) this application needs to be worked out, but we do not have the resources to implement it, so let's decide what can be thrown out of the non-critical functionality so that these resources and time can be released

c) this problem cannot be solved within the framework of this project. Therefore, plan funding to refine the system.



Try not to overdo it. You have to look for compromises in all situations. It will take a little bit of a psychologist to keep the customer satisfied with the work and you, but stay within the budget.

And yes, back to the past. Recall the first version of the TK, which was killed by the red-faced fat cat, if there was one. In this case, I advise you, starting the design / development, still think about what will have to be redone. It can save time, and maybe not. But the risks will reduce.

4. Implementation

The implementation phase of the newly developed solution will consist of deploying the solution, training and supporting users for a period.



Before deploying, take care to write quality documentation, it will still be required when closing the contract. It is better to use any wiki autogenerator. Wiki only have to fill in the guest. With long-term work mast hev. To the maximum, try to use a full-time system administrator, so that later he would be less fooled. Immediately require the allocation of resources under the test site.



Training. Send in advance an e-mail notifying you of the training and user documentation. The letter must indicate the requirement for the room, technical equipment. In the schedule of works (TZ), indicate that only one day is allocated for comprehensive training. This will not allow the rape of your implementers by repeated requests for demonstrations. Some time before this, hold an unofficial show for interested employees, so that when they train, they can help the instructor with something and try to limit the perturbations and desires of students (if you could earn the loyalty of the interested employees).



User support, in principle, does not have permanent key features (or I have not noticed them yet).



And finally. Remember that you are working with a giant bureaucratic machine. For comfortable work with this machine, you must have a bunch of documents, because there is a chance to close the project in court. Cover this machine with a bunch of papers to reduce your risks.



And be human , make the product so that it really helps your state, because you are its citizen.