According to our project working model, there are two main project management processes: planning and implementation.
The project planning process transforms requirements into results, work, and resources, not physically, but informationally. Its main task is to overcome the uncertainties and risks of the project by analyzing and predicting future execution.
The implementation process is the reverse of the planning process. It implements two important functions: first, it converts resources into results and satisfaction of requirements, this time physically, and secondly, it monitors the compliance of execution with the plan. This process is usually broken down into two sub-processes: execution and control, which we will discuss in this chapter.
Here is the scheme of interaction of the project implementation processes:
According to this scheme, the main process of the project, execution, produces the results of work. The results of the work are the input for performance control, in which the current execution is analyzed and a performance report is developed. The result of the analysis can be a transition to urgent or early completion of the project. Another result of the analysis may be to identify deviations from the plan and decide how to eliminate these deviations. There are two main options here: corrective actions and changing the approved project plan. Corrective actions are any unplanned work that is carried out at the expense of project reserves and does not affect the project benchmarks. If the deviations are so large that it is not possible to avoid revising the benchmarks, then a revision of the project plan is necessary. This is done by submitting a change request to the change control system.
PROJECT EXECUTION
The execution process is, of course, the main process of the project, in fact, the process for which projects are started. It consists in the production of the results of the project, that is, it is a purely technological execution of work and specific to each type of work. Works are performed by professional performers who bear primary responsibility for the work and their results. The main task of management is to organize work and manage work – i.e. to make sure that the right resources are in the right place at the right time and function in the right way.
If there is a project plan, this task does not carry a special project specificity and is usually carried out by regular administration and management methods. These methods have no numbers. You can get acquainted with them in numerous works on business administration. Here we will consider only those aspects of execution that have significant project specifics.
PROJECT RESULTS
The main output of any project is its results, which are determined as follows:
Deliverable – a unique and verifiable product, service or result that is defined in the project planning documentation and must be produced or provided for the completion of the project
There are two important points in this definition.
First, the results, in addition to simply being produced, can also be provided. It's about internal and external results. External results are those that are transferred to the customer and other interested parties, they, of course, are the main predestination of the project, what the project is started for. Internal results, on the other hand, are usually either components, parts from which an external result is collected, or control, management results. Often these are purely informational results – technical and administrative documentation that is necessary for the project team, but does not provide significant interest to external participants.
Second, the results, to be the results, must be planned. Unforeseen achievements, discoveries and inventions can happen in the project. For example, in the process of software development, it suddenly turns out that some not the most important module can have an independent promising application. Or when carrying out construction work, a new promising technology is unexpectedly found. All such unexpected achievements are not the results of the project precisely because they are unexpected, i.e. not planned. The question is, what if the project team wants, say, to get a bonus from their achievement? There is only one answer – you need to include these results in the project plan! Enable retroactively. And this means the need to revise the project plan, i.e. submit a request to the change control system.
FACTS OF PERFORMANCE
Another important way out of the performance of work is the actual data on the performance of work. Here's the definition:
Execution facts are primary data from project operations that are constantly collected during the project. First of all, these are actual indicators of the fulfillment of deadlines, cost and quality.
Facts play two crucial roles in projects. The first role is to give an objective picture of the state of the project, a picture of what is really happening. The second role is comparison with plans for analysis and forecasting of execution, i.e. for control.
Gathering facts is always a difficult task. Agree, if the manager knew everything about his object of control, he would be like the gods. And he would not manage, but create! However, usually the situation is reversed – the manager does not know anything! It's exaggerated, but not much – the manager only knows what he will be told. Those he leads will report. Or those on whom it depends – customers, contractors, controllers, a vigilant public. And whose interests, to put it mildly, do not always correspond to the interests of the leader. The situation is still the same! But this situation is common for projects, and this is the situation in which the project manager usually finds himself. And must be able to manage the project effectively!
How can this be achieved? Only by knowledge! Knowing what usually happens, what should be specific, what can happen, what is happening realistically, in fact. So, you need experience. Need information. You need skill. You need to plan and analyze. And – learn, learn and learn again!
PROJECT CONTROL
Control of projects is complicated by the fact that the project is a production event that has many aspects, and, accordingly, many indicators. The complex issue is further complicated by the fact that in different projects the sets of aspects and indicators themselves can be different and, generally speaking, anything. Compounding the complicated issue is further complicated by the undeniable fact that all aspects that need to be controlled must be controlled. The point is that if you missed some trifle and because of this there were not minor problems - then naturally, you are to blame!
A natural question arises: what to do? I hasten to disappoint you: there is no comprehensive answer! But I can still reassure you: there is an answer to the main aspects and indicators. I can even make you happy: this answer is exhaustive, it is even automated and even easily accessible in applications!
What is the answer? This answer is quite obvious: among the many aspects of the project, there is a small set of fundamental aspects. And we have already mentioned and noted this set many times! This is the holy trinity of control: timing, cost, quality. To this trinity is usually added the fourth aspect of projects - the content (scope), i.e. the composition of work and results. How to control them is well known.
You can say that these four aspects are inherently four completely different objects of control and the ways of managing them, in theory, should also be different. Yes, they are different. But the management is the same! The same because we do not control objects, but indicators. Each of the listed management objects has its own main indicators:
- Deadlines – dates of works and events
- Cost – income-expenses in physical or monetary terms
- Quality – quality characteristics and metrics (see Quality Management)
- Content – either just a list of works and results, or more sophisticated – indicators of configuration objects (see configuration management standards, e.g. EIA-649)
- Despite the fact that both indicators and, moreover, sets of indicators are completely different, they have one good property in common: any indicator is a characteristic with a quantitative value. That is, the indicator is a simple thing!
And the principle of controlling indicators is also a simple thing. You just have to get into it. Let's move in!
BASELINE
We will analyze the principle of project control on the example of the development of a certain system - information or technological - it does not matter which one specifically. Here is a screenshot of the development plan from MS Project:
We see two milestones in the plan: "Start of Work" and "Completion of Work", and five works: "Development", "Testing", "User Training", "Trial Operation" and "Reserve". Each work has two bars in the schedule: the upper and lower. The lower gray stripes show the approved period of performance of the relevant work. We see the following approved work plan:
- "Development" – first week,
– "Testing" – the second week,
– "User training" – there is no gray bar, there is no work in the approved plan,
– "Trial operation" – third week,
- "Reserve" is the last fourth week.
Milestones have a similar thing, but for them - two diamonds, the approved date of the milestone is shown in black.
So, we clearly see the approved plan of work and events. But in projects, plans are not always followed. Rather, they are always not respected. So, we also need to monitor the current state of affairs. To control the project, you need TWO plans - approved and current! In the figure, the current plan is shown with upper strips for works and transparent diamonds for events.
We can clearly see the current execution. The first work "Development" has already been completed, all the others have not yet begun. But the duration of the first work turned out to be more than planned: 8 days instead of 5 approved. This led to a shift of all remaining work by 3 days. In addition, there was an unplanned work "User Training" with a duration of 3 days, which was included in the current plan, since in the process of execution it became clear that it was necessary. And everything that must be implemented should be reflected in the current plan. This resulted in an additional 3-day shift to all remaining work.
As a result, we have a shift in the control milestone "Completion of work" by 6 days! But. But these works were approved reserve - the last week. It's a quasi-job, it's just a margin of time for every firefighter. It can be reset. And then the 6-day lag will turn into a 1-day lag. But the backlog won't go away!
One more important note. The work performed automatically goes from the category of plans to the category of facts. The first work "Development" is already a fact! The current plan is always a set of facts executed and plans for the remaining work!
Resume:
To control the project, you need TWO plans:
Baseline – An unchanged approved plan
Current plan – variable plan for remaining works, including unplanned and cancelled
The basis of project control is the basic and current plans for:
It should be noted that the above four main aspects of the project (content, timing, cost, quality) are common to all projects. But this does not mean that in a particular project, these parameters are sufficient or even necessary for management to succeed. It is possible that the key factor of a particular project may be any other aspect – the list, generally speaking, is endless: risks, personnel, interested parties, contractors, ...
ANALYSIS OF DEVIATIONS
Analysis of deviations of facts from plans is a natural and basic way to monitor the implementation of the project. Facts here are understood as any actual indicators of the implementation of the project work. Plans are understood as relevant indicators from the baseline plan of the project. The difference in the values of the indicators is analyzed.
Above, we said that there is a holy trinity of work indicators: timing, cost, quality. So, the analysis of plan-fact deviations works perfectly to control the timing and quality. But to control the cost (read: resources), it gives unpredictable results. Therefore, in most cases, advanced analysis is used to control the cost, which we will consider later.
ANALYSIS OF EARNED VALUE
It has been argued above that a plan-fact analysis is ill-suited to cost control. Why this is so, consider an example.
Example: Analysis of plan-actual deviations of the cost.
I'm a project manager. At the end of the next month, I analyze the execution of the cost of my project, in other words, I analyze the costs.
Naturally, I have a basic (approved) cost plan for this month. Let's say 1 million rubles.
I collected all the facts of the costs for the month, summed it up, and received the total amount: 2 million rubles.
A plan-fact analysis shows an overrun of 1 million rubles. The basic question of philosophy is: is it bad or good? How to interpret this result?
From the point of view of the financier, we have a clear overrun and this is definitely bad.
But from the point of view of the producer, the situation is not so unambiguous. What if the overspending is caused by the fact that I (i.e. my project, of course) completed twice the amount of work in the reporting month as much as the plan? And spent twice as many resources? And is this what caused the doubling of actual costs?
Then maybe it's not all bad? Maybe there is no overspending at all?
If someone is confused by a twofold increase in productivity, then you can replace the fact of 2 million with any other satisfactory value, for example, 1.1 million – the main question of philosophy will not disappear anywhere.
The problem looks even more interesting if we consider the situation not with overspending, but with savings. For example, I summed up all the facts of the costs for the month and received 0.5 million rubles. actual costs instead of the planned $1 million;
From the point of view of the financier, everything is fine – on the face of saving. Yes, and decent savings. And from the point of view of the producer, everything is ambiguous again. "Savings" can be the result of different production situations. The first one that comes to mind for the production worker, it is the most nightmarish – the plan is not fulfilled. That is, they executed two times less than the plan, respectively, they spent half as much - that's the "savings". Another quite obvious situation is inflated plans for volumes and / or costs. Then the facts will naturally yield savings. Surely there are many other situations of economy, such as: lack of marriage, alterations, waste-free production, high logistics, nano-technologies and mega-management, ... - then everywhere.
But I seem to get carried away and distracted from the topic. And the topic is this: the mere presence of deviations of actual costs from planned costs does not tell the producer anything other than the presence of deviations. In order to assess the nature (harmfulness or usefulness) of deviations, the manufacturer needs to know the causes of deviations.
To summarize:
To control the cost of the project, simply having deviations of the actual costs from the planned ones is not enough.
So, cost deviations are not sufficient for management. Something else is needed. In the example above, this "something else" is quite visible. Let's take another look. For a certain period, say another month, we have:
The basic cost plan is the approved cost of the planned volumes of resources for the production of the planned volumes of project work;
Actual costs are the cost of all the real costs of the project.
Let's say the two costs are different. Look carefully again at what we compare. We compare the "planned cost of volumes" with "real costs". I am silent about the fact that "planned volumes" are the dream of the performer, and "real costs" are the fate of the customer.
I'm still talking about something else. I'm talking about a very simple thing. From the point of view of the customer, it would be nice to pay "real costs" not for the planned volumes, even if agreed in the contract, but for real ones. For actually executed at the customer's facility. And really accepted by the customer. Agree?
If you agree, then everything is simple. How to estimate the actually executed volumes? Preferably one indicator. And quite "simple" and natural.
Usually we observe the executed volume in physical terms – the amount of materials consumed, man-hours spent, money, and so on. All these indicators will inevitably be in different units of measurement. They must be brought to one unit of measurement, and to exactly the same as the unit of measurement of the two available indicators - the plan and the fact of costs. So, the natural indicators of the executed volume must be translated into value.
Conversion to cost can be made in two different ways – either at planned or at actual prices. The second option gives the actual costs, i.e. the already existing indicator. So, the only way left is to estimate the cost of executed volumes in planned prices.
We get the third missing indicator, which is called the mastered volume. Here's the definition of earned value:
The mastered volume is the planned cost of the work actually performed.
Now we have three indicators of the execution of value and we have a fairly adequate tool for analyzing the execution of value, which is called the analysis of the earned value. Let's see how it's used.
Example:
Earned value analysis.
There is work for 2 months worth 10 million rubles At the end of the first month, 40% of the work was completed and 8 million rubles were spent.
What can we state in this example?
The first is the plan: 10 million rubles. for 2 months The plan is shown by the blue line. This is an approved cost plan, i.e., in project management terminology, the blue line is a baseline for cost. From it we can see that for the first month the volume of 5 million rubles was approved. This is the planned cost.
Further in the example it is indicated that at the end of the first month, 8 million rubles were spent. This is the actual cost. It is shown by a red line. As we said above, the plan-factual deviations, which in this example are equal to 8 - 5 = 3 million rubles. overspending, do not carry useful information for the manager-producer.
But in the example, the third parameter is also indicated - the mastered volume in the amount of 40%. Which should be interpreted as "40% of the planned volume has been mastered". The main problem with the mastered volume is the natural units of measurement, which must be converted into a cost at planned "prices". In our case, the cost of the mastered volume is 10 * 40% = 4 million rubles. It is shown by the green line.
So, we have all three indicators of the analysis of the earned volume by the end of the first month:
PV (planned volume) = 5 million rubles.
AC (actual cost) = 8 million rubles.
EV (earned volume) = 4 million rubles.
Let's analyze.
The first question is overspending – is it there or not? There is a financial plan-actual overrun, we have already noted this, it is equal to 3 million rubles. But what about "production" overspending? "Production" overspending should be considered not from the plan, but from what has been done, mastered. In our example, it is equal to 8 – 4 = 4 million rubles. and it's even bigger than the financial one. It is important to understand that
There is no "production" overspending or savings only in one case - when the actual costs are equal to the mastered volume. That is, as much as they did, they paid as much. We did less than the plan, but spent proportionally less – everything is fine, this is not savings, this is according to the plan. We made more than the plan and spent proportionally more – again everything is fine, this is not an overspend, this is according to the plan.
The second question is whether something can be said about the fulfillment of deadlines? Can. We see that we have mastered less than planned, our productivity is lower than planned, and by an amount of 5 - 4 = 1 million rubles. If we do not improve the performance, then we will not meet the deadlines, see the green dotted line.
Summary:
The analysis of earned value for our example gives:
Lagging behind schedule: 1 million rubles.
Budget overruns: RUB 4 million
The last question remains: are these deviations large or small within the scope of the project? To estimate the scale of deviations, indices are used that are not absolute differences, but relative shares:
Timing Execution Index: EV/PV=4/5=0.8=80%
Cost Execution Index: EV/AC = 4 / 8 = 0.5 = 50%
Or:
Behind schedule: 20%
Budget overruns: 50%
Here are the basic definitions of earned value analysis:
PV (Planned Value) – Software (Planned Volume)
BCWS (Budgeted Cost of Work Scheduled)
AC (Actual Cost) – FS (Actual Cost)
ACWP (Actual Cost of Work Performed)
EV (Earned Value)
BCWP (Budgeted Cost of Work Performed)
BAC (Budget At Completion)
Deviations and earned value analysis indices
CV (Cost Variance), OST : >=0 is good, <0 is bad
CV = EV – AC
CPI (Cost Performance Index) : >=1 is good, <1 is bad
CPI = EV / AC
SV (Schedule Variance): >=0 is good, <0 is bad
SV = EV – PV
SPI (Schedule Performance Index) : >=1 is good, <1 is bad
SPI = EV / PV
Actually, this is all about the analysis of the earned volume. It remains only to discuss the standard report of the earned volume. Here's an example:
Comment:
The first column of "WBS Element" is the work of the project of any level of convolution, it does not matter, because the real calculation goes at the lowest level and then is simply summed up from the bottom up. In the example, groupings of top-level works.
No comments:
Post a Comment