Great, the company has received a new project! Certainly everybody is full of energy and enthusiasm. Nobody thinks about a failure. Everyone is convinced that this new project will make a contribution in the form of new experiences to the team  and will strengthen the company’s reputation. However, is it really so?

Why is planning so important?

Regardless of what kind of a goal is set, the inseparable part of the preparation is to plan the entire endeavour. For instance, if the goal is to attack the peak of Mont Everest, the preparations will obviously focus on training, buying the proper equipment and checking weather conditions on the route. While looking through the map and searching for the right trail, depending on the alpinist’s condition and performance, he will choose the one, which in his opinion, is possible to achieve.

A similar approach should be adopted when it comes to setting targets at work. Remember that you cannot estimate deadline for project without the exact analysis of the presuppositions and the determination of the client’s needs.

The worst possible option is to create software in accordance with the ‘big bang method’, that is jumping to the conclusion that you have sufficient knowledge in all aspects of the presuppositions, and get to the creation of software, excluding the client from this process.

Although it is understandable that most valuable thing for the programmers is the opportunity to work in absolute peace and quiet, which is actually depriving, either totally or partially, the possibility for client to express his opinions on the condition or usefulness of already completed part of the software. This only leads to a dead end. Moreover, the team, convinced that they took the right direction, can get of the track that was set by the client’s needs and aspirations.

The consequences of such a state of affairs will not only be unpredictable, but they can even lead both sides (company and client) to an irreversible financial collapse. It’s all because of the lack of real plan of action and systematic verification of the current state of project in terms of the client’s requirements. Therefore, before you get to writing the first line of the code, it is crucial to dive in much deeper than just software.

Brainstorm, or rather, heads in the clouds

There are a few clients, who are able to precisely define their needs. Furthermore, while defining them, they are in fact defining their own clients’ needs. In the majority of cases this stage requires specialized knowledge in the area of design, usability, electronic marketing or for instance, psychology of purchase. You cannot demand that the client will possess all these skills or at least scarce knowledge about all of them. Since his knowledge and skills are definitely slighter that the expertise of the specialists, to whom he is going to commission the work, it often happens that the specification presented by him is incomplete or chaotic. In the first phase of the considerations he is not aware of the consequences, that might come from selecting certain solutions, and most of all, he will not be able to predict time and financial frames of individual tasks.

It is necessary to present your client the widest variety of opportunities as possible. Therefore, you should organize brainstorm. At this stage, it’s important to describe everything with a simple language, which won’t cause any embarrassing confusion later in the topic. The more ideas are written down, the bigger is a chance that we will achieve the quality our client expects. The reception of the software for usage starts the moment target audience become interested in it. You should allow this group to express their opinions at that point. The entire spectrum of presuppositions and the presented opportunities, verified with the client in terms of functional holes, might become a departure point for setting priorities.

Time estimation and prioritization

It is significant to transform those so-called users’ stories into tasks and take into consideration the team’s potential effectiveness of work or rather their ‘speed’. This variable is made more and more precise throughout the entire project, where at the beginning it is safe to estimate it’s on the level of 0,7 (max 1). It means that within 10 working days there will be about 7 productive days. While setting your ‘deadline’, you cannot forget the days free from work, private time of the team members and, for instance, technical factors such as a backup system, the repository configuration, error detection and repair, etc. It’s estimated that for 30 calendar days there are 20 working days, which means that 15 days are for effective work!

You cannot underestimate or overestimate the time frame. Priorities should be defined.

To set the priorities you should use the scale from 10 (the highest priority) to 100. It might be good to ask the client to use the multiples of 10. It will allow you to put particular tasks in the right priority group.

If it’s not possible to find an understanding between the time that is necessary to complete the commission and the time and budget that the client has on his mind, it’s better to let the competition take the project, rather than endanger both companies to the loss of time and money.

Iterations, or let’s fulfill the presuppositions!

Once the goal has been set, and the team has no doubts or questions, the only thing left is to get to writing the code. However, you cannot forget that the big bang method is a trap! In order to avoid those snares you should confront the client with the versions of the software for the purpose of ‘artistic flow’ correction.

The particular versions of the software will make sense when they contribute at least one efficient and complete functionality. Taking into consideration the priorities set by the client, you can divide all the functionalities into groups, whose individual completion should not take more than 20 work days. If particular functionalities require more time you can add another team member. As a result, 40 days appointed to 2 members can be executed using half of this time, but you should remember that it’s still 40 days.

Towards the end of each iteration team effectiveness should be checked, to calculate the estimated completion time. The constant update of this variable will allow for the more precise estimation of completion time for the next iterations. While defining a new software version, you should consult it with the client to confirm its accordance with the expectations and to determine how many tasks have already been executed, as to have constant control over what is happening within the project.

As a matter of fact, to accomplish this, we do not need fancy software, an ordinary board will suffice, with the three-column tables:

TO DO – the tasks which we have to do;

IN PROGRESS – the list of tasks which are being executed;

CLOSED – the list of the closed tasks.

There may be more columns but these three constitute the basis for the team management. In the case of larger completions, you can try adding columns connected with the process of software testing, if some other person or a team is responsible for it.

Sometimes the client might suddenly came up with a smart idea or a need to provide a presentation to the company’s board, whicj will crash our plans and organizational presuppositions. This situation can be solved in two ways. The first one is to reorganize the tasks to take into account the time needed to add a new task. However, if it is absolutely impossible and there is risk of missing the deadline, then the client needs to be aware that adding a new task/presupposition to the schedule will make the completion time longer. We should remember who the dissident is, that is a client :-) and who pays for the fulfillment of the specified presuppositions and tasks.

Not every task is the key one!

While breaking the presuppositions into particular tasks, which will be assigned to specific team members, you cannot forget that too many task within given functionalities, may lead to delay in handing the entire project. In order to avoid it, you should set the priorities. Firstly, those tasks are determined whose fulfillment is absolutely necessary for the proper performance of the given functionality.

Having listed all the basic tasks and their estimated completion time, if the sum is smaller than the total calculation of the execution of presuppositions, you can add additional tasks, improving the final result of the operation of the functionality. It might seem quite complicated, but it’s really all about knowing what tasks are the most important and urgent, and how much time you need to fulfil them.

Stand-up, a practical tool during iteration

The first task of this faze is to sort work by priorities, but also to intercept possible deviations form the original direction. Undoubtedly, the board organizes work, but it’s still just a soulless written word. And even if it contains humoristic elements in the form of interesting magnets with faces or colourful pins with flags, it will still be just a record of progress.

While working in the team, it’s significant that project manager has verbal contact with particular team members. People are not machines and sometimes, being under a lot of stress, they cannot find simple solutions. A five-minute-talk on the current matters might contribute a new angle to the project.

Stand-up is one of such tools. Those 15 minutes, when you talk about current matters, problems and ideas, will support your team and allow to deliver the functional project on time.


When everything is planned, and the work is on progress, you must remember to keep each member systemized about their tasks. Especially programmers, because versions of files and particular code elements have their order in the file structure and class naming, etc.

There are two methods, that support these tasks:

  1. SRP –  write a code in the way that each object has just one task. It allows for an easy access to methods and models performing specific tasks.
  2. DRY –  make sure that the code does not ‘grow’ too much without a reason. When it comes to large applications, the number of files is counted in thousands, and the line codes themselves – in millions. Each unnecessary code line is written in a day, which gives 20 lines in the iteration. For a three-member- team it is already 60 lines and it is only for one task!


Regardless of how many people have tested the software during the particular iterations, you cannot forget the final tests. Once all the iterations are completed and before the release of a stable software version, it needs to be checked once again. The best solution is to entrust the testing process, not only to the technical team but also to the ordinary users. In order to do so, we may write several scenarios and ask for their fulfillment. Then we will obtain solid feedback concerning the usability of the software, which was produced. If users find something difficult and not intuitive enough, it may be worth changing before 1.0 release, otherwise, the huge launching of the new venture might be a big and irreversible mistake, which might only make users not interested in this topic again.