What may happen if we ignore one of the most fundamental rules that govern IT projects? Why can some ready-made solutions pose a threat to the success of your project? In what situations can PM’s room for manoeuvre be limited to the minimum?
You will find the answers to the above questions in a second, in yet another post that describes my first project at Objectivity. In my previous post, you had an opportunity to get familiar with our preparations for starting a new project. You also found out about the most common problems and mistakes we come across and those we made during the estimation, planning, and project kick-off. Today, I’m going to focus on the next stage, which is an initiation phase.
After the quick kick-off, we moved even faster to the initiation phase. Within the next two weeks our goal was to prepare the best we could in terms of the technical aspects of the project. The aim was to ensure smooth and efficient work in the next stage. According to the initial plan, at this stage there were only three people to be involved: an architect and two developers. Unfortunately, due to the fact that we reduced the time for finishing work (what was mentioned in the previous post), we were forced to revise the assumptions. Therefore, three developers joined our ranks in order to consider delivering the solution according to schedule. Consequently, it we had almost a full team to work on the matter.
What does the Brooks’ law have to say in this matter? ‘’Adding human resources to a late software project makes it later’’. I can entirely agree with this law and I have to confirm it works in practice. The sudden and unexpected enlargement of the team became a source of various problems, which affected the project status for quite a long time. Three of the most important problems were as follows:
- A drastic increase in time devoted to internal communication and task synchronization
- A decrease in efficiency resulting from a frequent context changing and switching communication and synchronization, code review, etc.)
- reacting to the current situation instead of planning based on reliable data.
The third problem seemed to be particularly problematic. It quickly turned out that in order to make the work easier for the team, we had to give up on a peaceful and methodological preparation. Consequently, we focused on the current tasks and obstacles that could hinder our work. Yet once again, being in a rush and being under the pressure of time was to become the root of our problems.
Out of the (Pandora’s) box
While preparing for the project kick-off, we assumed that in order to implement the two key components, i.e. UI and grid, we would apply the already existing solutions. By doing so, we hoped to avoid creating new solutions from scratch. A good practice before using ‘’out of the box’’ solutions is to do PoC or Spike which allows us to assess the usefulness of the solution in terms of viability, functionality and price. In case of unsatisfactory results, we have enough time to take a decision to change the component or to extend the planned budget for its implementation. Unfortunately, we didn’t have enough time for certain aspects before the estimation, and now that was the case as well. After the first problems with UI, a rapid decision was taken to write it from scratch without analyzing the possible options and their consequences. When I think of it now, I’m wondering if any decision was actually made at that time. It seems that instead of saying: ‘’Yes, let’s do it!’’ something like ‘’let’s kick off and see where it takes us’’ was said. And it took us nowhere. Rapidly mounting problems made the costs increase much faster than the very progress of work.
We found ourselves in a very similar situation as far as grid is concerned. In this case our initial assumptions were too optimistic as well. Having started the implementation, it turned out that the scenarios, that worked flawlessly on its own, started causing trouble when several of them were supported at once. ere, we didn’t make the same mistake once again and we decided not to rewrite the component from scratch. However, a different mistake was made. We decided on our own ‘’customization’’ of the chosen solution so that it could fulfill our needs. As you can guess, in this case many things did not go as expected, either. Each time we thought that the worst was over, new obstacles appeared on our way. Unfortunately, this state continued throughout the project.
Why didn’t we decide to give up despite all these problems?
It was mostly the matter of time. We had a feeling that if we stopped the work, it would result in yet another delay – something that would definitely make the situation worse. We were running out of time day by day, which made the decision much harder, and eventually impossible. Moreover, we did not want all the effort that we had put to go to waste. We were not willing to accept the fact that we had lost, and so was the investor, even if it was to help us achieve the goal.
I find it quite obvious that if something is to be delivered faster, the cost is to increase. That was the case as far as our project is concerned. The fact that the team members joined faster than planned as well as the problems that we came across, resulted in the reserve budget being used up rapidly. During the conversation with the client, it turned out that the increase in the spendings was beyond their means. At that moment, the project that we treated as Time & Material became a Fixed Price project. You are probably wondering why I’m writing about all this since a great number of projects are carried out in this way, and there is probably no reason to be afraid. Well, I totally agree. Unfortunately, at that time the budget, as well as the scope and schedule, became another invariable parameter of the project. My room for manoeuvre was limited to the minimum, which definitely affected my team in terms of the sense of comfort. We were aware that each and every mistake or a wrong decision could increase the risk in a way that we wouldn’t be able to react accordingly, e.g. to limit the scope or to extend the deadline.
As you can see, the initiation stage took place in a hurry and consisted of a few decisions that did more harm than good. Being focused on the present moment and not paying attention to the bigger picture resulted in various negative surprises, which could have been predicted much earlier.
After the project was finished, I tried to analyze this stage focusing on the actions and decisions taken as well as their consequences, which helped me define 4 main points, which I would have approached differently if I had been given one more attempt:
- At the beginning of the initiation stage, while being aware of the necessity of extending the team, I would spend 1-2 days on updating the plan to account for the additional team members joining the project. Consequently, we could optimize the way of working and minimalize the negative consequences that I mentioned at the beginning of the post.
- While selecting the ready-made components, I would spend more time verifying their usefulness and gather a sufficient amount of information necessary for making a quality decision. Such a step would allow us to save hours of work and frustration caused by the piling-up problems.
- During the preparations for the delivery stage, I would put more emphasis on finding the exact relationships between the tasks so as to enable optimal planning of the implementation order. Another advantage of such a step, would be to increase the probability of spotting some inaccuracies or lack of knowledge, that hindered our work in the further part of the project.
- When planning the scope of work for the initiation stage, I would mark technical tasks as those of high priority, since completing such tasks was a necessary condition for a quick and efficient implementation of the business part. It would therefore allow the implementation of ‘’first time right’’ functionality part.
And this is where the initiation stage ends. In the next post, you will have an opportunity to find out about our struggle with the delivery stage, i.e. the way agile waterfall looks like and how a daily helped us overcome critical situations.