Evaluate the costs of a project


Even before the project is launched, the question that comes up on the table very quickly is “How much does it cost?” and “When will it be delivered?”. Some think the project manager has a crystal ball on his desk, others know they use special techniques to predict the future. What are these techniques?

Evaluate the necessary means

Ideas that become clearer, a target in sight. And this is where things go wrong … it is about determining in advance the budget necessary for the realization of the project and its delivery date so that it will be carried out in the future! It is necessary to integrate the purchases of equipment, subcontracting, the training needs of teams and users, without forgetting the number of man-days on the internal teams, that is to say all the means necessary to achieve the set objective.

In order to determine the needs, it is necessary to determine the useful quantities. To determine these quantities, without methods, it’s like making a cooking recipe in a completely intuitive way. It may end up being too spicy or salty, or not enough and either way inedible.

For the director or manager of the program or project

This entire inventory is in the hands of the project manager who must arrive from the opportunity study phase to assess all this to ultimately define the ROI of the idea and its chances of seeing the light of day. In other words, it is easier to assess the costs of a project than of a program … or at least, the cumulative costs of a program will be weighted with a greater coefficient to integrate the concept of due risk. the complexity of the interdependencies of each project.


Predicting the future without a crystal ball

The main thing and the purpose of the workload assessment exercise is to allow the sponsors to take a position on the commitment to the project. (Go / NoGo). Indirectly this leads the project manager, the product owner, to commit to respecting financial and time volumes. The exercise also makes it possible to lay down the roadmap, the organization of the work and therefore to steer and coordinate the teams who must carry out the work. Ultimately, assessing the costs of a project sheds light on “who does what when”.

Possible methods

In the IT world, there is literature on evaluation methods, some of which can be seen from another time. For example, COCOMO (COnstructive COst Model), which dates from 1981, which in summary determines the number of man-months) as a function of the number of lines of code, productivity (the number of lines of code per person per month) and a scale factor that depends on the type of project. A model that requires a calculator equipped with new batteries …

Or in 1979, the “IFPUG function points” (International Function Point User Group) method, which has an earned value assessment approach seen on the business side which is analyzed with GDI, SLD, DE. A model that requires a new box of aspirin at hand … Simpler, the Delphi method, which basically consists of soliciting experts in the activity to be evaluated and asking them for their opinion. Then cross-reference the values ​​collected to initiate a debate and a refining cycle. It seems more affordable as an approach, provided you have experts on hand … Another possibility when we cannot evaluate a load, the technique which consists in breaking down the work to be evaluated into sub-tasks. Thus, faced with things more broken down and simple to analyze, evaluations are facilitated.

Be careful, however, to clearly define up to which granularity of unit tasks to stop the decomposition, because we can quickly descend to microscopic notions that do not bring significant added values ​​in the precision of the evaluations. Indeed, let us not forget that we are in a theoretical evaluation of loads and that whatever the case, the reality of the realized will be different. Projects never really go according to plan do they? A more macroscopic approach can be based on charts.

The principle is that the loads of the following phases are determined from the values ​​obtained for the evaluation of the loads of the first. We can thus concentrate on the evaluation of the workloads that will require the definition of the specifications or the formalization of the specifications and determine the general weight of the project from this evaluation. At jobSkills.center we use the following abacus:


Project phase

Example Example

Functional specifications / Specifications

10% 10 18

Detailed study

20% 20 36

Models / Sprints

10% 10 18

Design and testing

50% 50 90
Documentation 10% 10 18

Total design (AT)

100 180

Release, support, debug

A * 10% 10 18

Transfer into operation / Closure

A * 1% 1 1.8

Support for user change

spécifique 2 20

Total Delivery (B)

13 40

Total Design + Delivery (A + B)

113 220

COPIL, COPROJ and coordination

A+ B * 15% 16.95 33

Total Project management (C)

17 33
Total Project (A+B+C) 130 253


Continuous improvement

The charts must be refined and optimized over the course of the projects according to the project typologies, the organization of implementation and the experience acquired. The model presented above corresponds to the model of organization and products produced at jobSkills.center.

Also, do not hesitate to send us your comments, adjustments, improvements to the above model according to your own feedback, especially on support for change, for example. Working together on the optimization of the subject, we will only apply, basically, the Delphi method seen above.

Useful bibliography

The mythical Man-Month by Frederick P. BROOKS Jr to read at least once in your life

Written by the jobSkills.center team