One of the serious problems in projects is exceeding deadlines and budgets. We can even say that there are no failed projects at all, but there are those whose term has been extended indefinitely, and the budget has yet ended. It is noteworthy that both the contractor and the customer suffer from exceeding the deadlines.
The customer does not receive the expected result, and the contractor - the expected money. It would seem that a common problem should unite, but it often only creates additional problems between the parties. How do you make sure that deadlines and budgets are always met? We have achieved something in this direction.
Before I talk about my experience, I would like to answer a few fundamental questions: what does the customer want and what does the contractor want when implementing projects? We will proceed from the fact that the customer really wants to make a project.
He has a certain budget, and he is not going to "throw", but is ready to pay the agreed money for the result. It's clear that he wants to do as much as possible for his money. And when you're renovating a house, don't you want that? And like every owner hiring a construction crew, the customer may suspect that the contractor will inflate him to inflate the budget. What to do, this is our reality.
What does the performer want?
In the vast majority of cases, the project team wants to do the work, and management wants to get contract money. But since an experienced performer knows what the customer wants, and knows that the budget tends to end in the midst of his desires, the performer seeks to inflate the budget as much as possible.
Each of the parties, in its own way, is right. We have to put up with this and in such conditions, without finally agreeing, start projects. But the initial misunderstanding, as a rule, in the course of the project only increases and leads to ...
let's not talk about the sad. I will tell you about the principles and methods of project management used by us, which, in one way or another, are related to meeting deadlines and budgets. Perhaps this will help someone to improve the quality of their own projects.
Scope of the project
The first key point is the development of the framework. The project framework is a document in which the customer's requirements for the system are written, but not as fundamental as the TK. The functional framework of the project is made up of a consultant / analyst - an employee of the contractor's project team - based on interviews with key specialists of the customer.
The project framework is a complete understanding of all the tasks that need to be solved during the project, but without detail. This is also a list of tasks that will not be solved during the project. This question takes one to two weeks. The same amount can take coordination and clarification.
Please note that at this point there is no contract and no project. And that's a risk, the project may never start.
Who will pay for the work of the contractor for the preparation of the framework, evaluation, planning, preparation of the budget?
I suggest that you answer this question yourself. I can only say that the assessment of the project, its timing and budget, obtained without working out the framework of the project, are fantasies that have nothing to do with reality. There is nothing surprising in the fact that in the course of the project, the budget and deadlines creep, go, fly.
Architecture development
After agreeing on the functional framework with the customer, the consultant transfers them to the architect. The architect who will later make the project. The architect studies the scope of the project, asks questions to the consultant and thinks through the architecture of the solution as a whole and the implementation of each specific requirement - this is the second key point.
The result is a couple of paragraphs of general architecture text – which technologies are supposed to be used, and a couple of sentences for each requirement – which components are proposed to be developed and what the expected complexity in days is.
Sometimes we make a separate document "Project Evaluation", in which we record the assessment and the intended implementation. This is sometimes done in the form of comments to each requirement in the Project Framework document. An architect's evaluation usually takes two to five days. The questions that arise in the architect may reveal the aspects that are not worked out by the consultant and require additional elaboration.
This is excellent, because the risks of these problems during the project are reduced. The architect can work out the architecture and form the questions independently. But the final meeting on the discussion and evaluation of the requirements is held by the project team together, at least in the composition of: consultant, architect, project manager.
The architectural constraints of the system that result from the solution are also documented in the Project Framework document. In addition, the document records events that are significant for the project - the necessary resources that the customer must provide, the timing of the preparation of equipment, training classes, etc.
Work planning
After working out the requirements and understanding their implementation, preliminary planning of works and resources is carried out - the architect determines which performers can be involved in the implementation of certain requirements, in what order critically the requirements are met, what inter dependencies exist between the requirements. All information is accumulated by the project manager, transferring it to the project plan.
At this point, the timing of the project is born. At first, all the work is lined up linearly. Next, the tasks are distributed by resources. Based on the wishes expressed by the customer on the timing, as well as on the optimal combination of attracted resources, the duration of the project is determined.
By "the optimal combination of attracted resources" I mean a simple idea - the timing of the project should be minimal, people should be attracted as little as possible, but they should be used as much as possible. This is how estimates of the length of stay of people on the project appear, which are the basis for drawing up the budget of the project.
We do work planning in MS Project. In the work plan, we put the laboriousness of performing a particular task. Estimates issued by an architect can only be used in conjunction with an understanding of who will implement these requirements.
We should have specific names of people. And on who exactly we involve in this task, the adjustment of the assessment of this task will depend.
To adjust the score, it is important to know the productivity of each particular developer. This is the third key point. The same applies to other works – installation of the system, preparation of technical specifications, testing, etc. To know how much work will take, we need to know who will do this work. In fact, to plan and evaluate a project, we have to assemble a project team.
Budget estimate
As a result of work planning, there are roles and people involved in the project and the duration of their stay on the project.
As a result, the project budget appears. Planning and budgeting take about two or three more days.
The fourth key point in budgeting is that we are moving from the complexity of the tasks set out in the plan to the duration of resource mobilization. The logic is simple. The main item of expenditure of the contractor is the remuneration of personnel. If people are on the project longer than the paid time, then the contractor's company incurs direct losses.
Therefore, it is necessary to plan and control this parameter. If the budgeting of the project and its control is carried out not on the basis of the terms of stay of people, but on the basis of an assessment of tasks, then you can be sure that the rates of specialists are too high risks not to worry about real resource planning.
Clarification of the framework, deadline, budget
As a result of the work done, we received the following documents:
- The scope of the project agreed with the customer.
- Evaluation of the project with the intended architecture and the complexity of implementing the requirements.
- Project plan.
- Project budget.
- It's a complete understanding of what needs to be done, how it's supposed to be done, how long it might take, and how much it will cost. All four results must be presented to the customer.
The project budget and deadlines are the parameters on the basis of which the customer will make a decision. Requirements are a parameter that will be managed by the customer and the contractor to adjust the budget and deadlines.
Since the budget estimate is completely transparent, you can only throw out or reduce the requirements to reduce the time and budget. We do not have a valuation of each claim, so we focus on the laboriousness of the implementation, estimated by the architect.
After reviewing the requirements, the project manager makes a re-planning, guided by the same principles: minimum terms - optimal resource utilization. After re-planning, the budget is adjusted. The framework, timing and budget are the substantive part of the contract. All the work on the formation of the framework, planning and evaluation takes us two to six weeks.
Have you already answered the question, who pays for it?
In my opinion, both the contractor and the customer should pay. The willingness of the customer to incur the cost of evaluation indicates the seriousness of intentions in the implementation of the project. The contractor's expenses, or rather the performance of work at or below cost, indicate his interest in the project. This motivates him to make an assessment in the shortest possible time. This is a job at a loss now, but with maximum elaboration, because these are his risks in the future. In each case, the situation may differ.
Manage deadline and budget
We have completed the assessment, agreed on the budget and deadlines. Ready to conclude a contract and perform work. But it is necessary to answer one more question - what does the contractor sell to the customer? On the one hand, he sells the result - the contract contains the scope of work that the contractor undertakes to perform.
This is a fix price contract. On the other hand, it sells resources – the budget is drawn up on the basis of the duration of the attraction of resources, that is,"time & materials". They're different types of relationships.
But we must understand that the thoroughness of the assessment, the customer's fears about exceeding the budget, and the contractor about a possible change in requirements, have not disappeared. Certain agreements between the customer or the contractor on the principles of change management can help to remove fears and resolve contractual contradictions.
Their essence is as follows:
- The Contractor guarantees the implementation of the project within the agreed time and budget, in case the scope of the project is not changed.
- The contractor guarantees that in case of performance of work ahead of schedule, the contractor's employees, if necessary, will continue to work on the project within the paid budget on additional tasks.
- If during the course of the project there is a change or non-compliance with the scope of the project, but they do not entail changes in the timing and budget, then the obligations of the parties remain within the framework of the contract.
- If the changes made to the project framework entail additional attraction of resources, then an additional agreement is drawn up and the customer pays for work that exceeds the original budget.
With this approach, the contractor cannot get additional profit by saving the budget, since he is forced to work it out to the end. At the same time, the customer has an additional clear incentive to keep the framework.
In case of their change, and accordingly, exceeding the terms of the project, he will pay for the additional time of the contractor's specialists. If the contractor honestly fulfills his obligations to allocate resources, then the qualification of the contractor's specialists becomes the main criterion for customer satisfaction.
No comments:
Post a Comment