Strategic Project Management

 

Companies delaying the release of the promised version by a year resemble a sticky F8 key, when any desire to use such a version is erased. Companies that break deadlines and can't keep up with the budget are like the blue windows screen, when all the work is lost due to someone else's mistake. They can be understood. They can't be justified – they don't want to learn how to manage projects.

You can buy the most advanced system of configuration management, version control, modeling and testing, but the project will still not meet the deadlines. Why? Because such systems are aimed at automating the work of programmers and middle management, but do not affect the highest level of management. Real productivity and the real amount of work are not linked to the schedule and budgeting of the project, without which control over the plan loses its meaning. Therefore, the first task of the head of the development company is to monitor the overall progress of the project based on the correct indicators. Problems in the process of work should be solved not as they arise, but try to anticipate and nip in the bud - this is the second main task. Let's consider them in more detail.

Monitoring the implementation of the project

There is such a wonderful technique – Cost / Schedule Control Systems Criteria (C / SCSC), developed in the mid-60s of the US Department of Defense to monitor the progress of work by contractor companies (in non-computer areas). It allows easy ways to track this process and was originally based on 35 criteria. In the future, C/SCSC was improved several times, a number of new methodologies were created on its basis, but it does not lose relevance today, especially with the growing interest in such developments on the part of software companies.

In the most simplified (but still useful) form, with the help of C/SCSC, you can monitor the progress of the project according to the two most important criteria – deadlines and budget. The U.S. Air Force Logistics Center in Oklahoma (the first U.S. government organization certified in 1996 for the fourth level of the CMM), which has 600 employees, has been using this methodology since 1985, and in 15 years none of its many projects has exceeded the deadlines and budget. And among his projects are, for example, the creation of a weapon control system for B-1 and B-2 bombers.

To properly control the work on the project, you need to know the capabilities of the staff, write out the work plan in detail for each employee, determine the cost of each block of work and methods for calculating costs. Then, in the most general case, the scope of the project will be characterized by its budget.

The progress of the project is tracked on a graph with normalized "deadlines - budget" axes.

(The C/SCSC recommends applying several evaluation criteria. The Logistics Center started with four criteria, specifically various performance indices. Today it uses 10 criteria, with plans to increase the number to 64.)

The green area defines the allowable combinations of due date/budget values. Straight 1 shows the perfect progress of the project. At the red point, the project should be completed.

Suppose that at some point in time (today) the amount of work performed (proportional to the spent budget or labor costs) is checked. The corresponding point is marked on the line "today" and a line 2 is drawn through it. This value is slightly lower than planned (the point of intersection of the line "today" with a straight line 1), which indicates a slowdown in the pace of work. Where a straight line 2 intersects with a line that defines the project budget (the upper bound of the green rectangle) will indicate when the project is completed. According to its deviation from the planned value, we will get a predicted delay in the term.


The real cost of the amount of work performed (included in the budget), as a rule, is more than planned. Having put the corresponding point on the line "today", we draw line 3 through it. Where it intersects with the date of the protracted completion of the project, the real size of the budget and its overrun are calculated.

In such an elementary, but very effective way, you can determine how much the project will eventually deviate from the set values. It is important, of course, to remove the indicators when forming line 1 with a reasonable frequency - at the beginning of the project, significant fluctuations are not uncommon, which are then smoothed out.

Calculated on the basis of time/budget indicators, the various indices according to C/SCSC can be in the green (normal), yellow (dangerous) and red (critical) zones. In our case, there are two indicators. If only one of them is located in the green zone, then the project can still be completed on time and meet the budget; when the indicators are in the yellow and red zones, the project is likely to fail. Both indicators are in the red zone - the failure of the project is guaranteed.

According to the values of the planned and spent budget and the real costs of the amount of work performed, you can judge the nature of the problem - failure to meet deadlines or overspend the budget - and, based on information about the productivity of employees, determine what needs to be done - increase the number of employees (disrupting the budget), or lengthen the deadlines (disrupting the plan) in order to fulfill the main requirement of the customer (as practice shows, he is more concerned about the timing). You can still try to increase productivity, find additional financing or reduce the customer's requirements for the system being created. Given that a reduction in the timeline leads to an increase in the budget, and, conversely, a decrease in the budget leads to an increase in the timeframe, it is necessary to focus the adjustment strategy on one specific direction (or timing, or budget).

By tracking the project even at such a simple level (it is best to post such a schedule in the company's central office), the manager will quickly be able to understand the basic principles of strategic project management. At the same time, the more parameters are under control, the easier it will be to manage the project, promptly identifying the causes of emerging deviations.

In pilot projects conducted using C/SCSC, it is recommended to make significant reserves for each of the criteria (timing and budget). In the future, on the basis of accumulated experience, the value of this reserve can be reduced.

Risk management

In the course of creating software, there are necessarily many pitfalls - various risks. For example, the customer may put forward new requirements, employees may not cope with tasks or quit, etc. The problem of risk management is inextricably linked with the management of the entire project as a whole.

The only way to deal with risks is to learn to anticipate "punctures" and try to make available to the whole team as much information as possible about each risk. For example, the quality of the requirements put forward by the customer at the initial stage can often be judged on how well he understands the task; according to the moral climate and the level of salary in the company - about the efficiency of employees, etc. And adjusting the plan on the go, when the risk has already become a reality, is a disastrous business. As a rule, one unpleasant event in the project usually generates a series of risks, and uncontrollable risks themselves begin to manage the project.

The CIA's National Reconnaissance Office, in collaboration with the SEI Institute for Software Engineering (the author of the CMM methodology), decided to improve the quality of projects related to the creation of distributed control and control systems for the US Department of Defense, numbering millions of lines of C++ code and running on hundreds of servers. Extensive work was carried out to analyze and identify the most important and common risks according to 77 criteria. Here is a short list of them (in descending order of importance):

• incorrectly formulated requirements;
• problems with employees;
• insufficient testing and poor software integration;
• system design errors;
• errors in the planning of work on the project;
• poor-quality implementation;
• poor management;
• wrong choice of commercial software;
• poor communication with the customer;
• inability to conclude contracts.

Based on the results of the analysis, SEI developed a number of recommendations. To effectively combat risks, it is necessary to:

• formally define the concept of risk and not confuse it with similar problems that are not risks;
• determine by which criteria to monitor the development of risks (usually the impact that the risk may have, the duration of this exposure, the cause of the risk and its probability);
• train staff to identify and deal with typical and inherited risks as the most dangerous;
• keep records of risks and analyze old projects;
• reserve time in the project to combat risks.
• At the same time, it is necessary to manage risks continuously, constantly monitoring their dynamics. Senior managers of the contracting organization should prioritize the identified risks, allocate resources and monitor the progress of risk management. On the basis of these strategic decisions, metrics are determined by which risks will be identified and measured, a plan for combating them is drawn up and monitored, and strategies for this fight are developed. Project managers (middle management) analyze risks in detail, decide how to act in each case, and regularly report to management, providing him with information for new solutions - when each participant in the process has his own specific role, and management is a closed system with feedback, the management will not begin to work on the principle of a simple "distribution of CU", and the middle level will help subordinates willingly, not through force.

The most important aspect of risk management is complete openness of information. A conspicuous graph of risks along the "possible impact/probability of occurrence" axes indicating the trends in the development of each risk over time and personal responsibility for the elimination of each risk is useful.



Solid line: "The customer will delay payment (comm. Director Budkin)". Line with short dotted lines: "Errors may occur in the system due to poor organization of the testing process (hands. project Dubkin)". Line with long dashes: "An uncorrected error in module A will lead to problems in the operation of modules B and C (programmer Pupkin)".

It is desirable to make such graphs of different types - visual forms of visual information give a more complete picture of the structure of risks and quickly help to find ways to eliminate them.

What's next
We have considered the two most important areas of strategic project management – project progress management and risk management. Now let's imagine a situation from life: a novice project manager, having read the articles of a certain Simeon Bobrikov in the international publication of confectioners "Pishchevik", in which for some reason publications on the topic of project management began to appear, finds materials on CMM and C / SCSC, diligently studies them, draws a wonderful schedule "deadlines - budget", comes to the boss, and he says: "Yes, a great plan, everything is fine, only ... The term should not be 12 months, but 8, and the costs are not 50 thousand dollars, but 25". From this moment begins the familiar real project management. What to do in such situations?

To do this, you need to understand what the project management methodology is, be able to correctly determine the size of the project, coordinate your own interests with the interests of the customer, know the principles of improving the software development process and many other equally interesting things.