Marcell LippIntroduction
As I’m talking with other software developers I really often hear the points from them like: we are just suffering due to the bad planning of this project, for sure the company is winning a lot of money from our work, I don’t know what the project managers are doing all they long etc.
For getting bit better overview on this topic I would like to write a short introduction to project planning and management, to clarify some unclear points.
There are several different working models, project planning models and situation. Since I’m a developer I also don’t have deep knowledge, so I really would like to show only on high level how all these things are working.
Planning
Before starting with a project the project should be plant. It needs to be decided what is the exact goal of the project and what are the so called included activities, like: is hardware integration part of the project? Which level of testing is required? In the next the used technologies needs to be decided at least on high level: which programming language should be used, which other software and hardware will be needed during the development?
Based on its results a skill analysis should be done: which skills are required from the team who will work on the project and on which level? Like if it’s a project developed in C++ with QT framework for GUI, tested with Google Test framework, it needs to run on both Windows and Linux then the team will require experience with GUI applications, knowledge of software architecture of GUI based applications, strong C++ and QT knowledge and experience with GTest and GMock.
Once it is done it is time to go a bit deeper into the project. The whole project needs to be splitted into smaller steps, so called milestones needs to be defined, like:
Milestone: GUI prototype, without backend functionality
Milestone: User handling related functionalities: login, logout, registration of new users, change password
Milestone: Working X, Y and Z functions
…
N. Milestone: Application with full functionality, fully tested.
It also a good practice to plan an N+1. milestone for bug fixes. The different milestones should have more or less the equal size. And this practice is the same for classically managed projects (V-model etc.) and for agile projects.
Estimation
The next point is the estimation of size of milestones. This is still a so called high level estimation. To be able to do it it needs to be listed on a high level what all should be done for one milestone and a rough time estimation needs to be added. The estimation can be done in manmonth, manweek, working day or even in sprints or story points. This estimation is the basis for calculating the due dates of the milestones and the needed team size and setup in different periods of the project. And this all will be a big basis of cost estimation.
How to calculate the price
Let’s see what all needs to be included into the price? Usually the biggest cost is the salary of the developers. Usually it is not calculated based on the actual salary, but based on an average salary of the given knowledge level. Take the example: based on the estimations the project will take 10 months and for the whole length we will need 2 senior developers and 4 juniors. The average monthly gross salary of a senior developer is 6000 dollar and it is 4500 dollar for a junior developer. The the whole costs of salary for the development team is 300k dollar. It also needs to be considered that there are managers, who will also work on this project. And usually there is additional stuff at the company: HR department, high management, sales etc. who are not working directly on projects, but the salary needs to be covered by the project incomings. These costs are usually called overhead and setup in a certain percent of extra costs.
Additionally a training budget needs to be plant for the project. You need to also think about hardware and software license costs. Probably additional travel costs needs to be also considered if the customer is not in the same city as your company.
You need to also think about office rental fees for the team.
Once everything is collected and estimated (based on the estimated length of the project and size of the team) you need to consider that the company would like to make some additional money from the project and the fact that if things are not going well and additional costs are coming into the picture (ex.: the project will take longer) the project should be still beneficial. So you should setup a price for the project which is pretty clearly higher then the costs.
Tracking of the project
Based on all these estimations the project manager will make a time and a cost plan for the project and he will keep on track the current project state. So if the team starts to be behind the estimated time the project manager needs to react to be able to keep the project beneficial for the company.
In spite of this there are still a lot of projects which are earning less money than the costs. In such cases the company needs to move budget from other projects.
Sometimes companies are starting projects where it is pretty clear right at the beginning the it won’t be beneficial. It has usually a strategic cause: they would like to win a new customer or build up knowledge base on a specific field.
If you need to plan the whole project in advance that is pretty risky. Luckily there are other approaches: the times based one, when the customer is paying after the real working hours done on the project. In this case there’s almost no risk, but of course the potential benefits are also lower. As an alternative you can use the agile approach when each smaller tasks has it’s on price and you can regularly decide together with the customer which tasks should be done and for which price.
