Another observation from years of working on software projects, particularly e-commerce.
The biggest risk to a project is the dragging of deadlines. As a consequence – the budget. It doesn’t matter whose initiative it is – the client’s or the developer’s. If the deadlines are slipping – the risk increases every day that the project will never be completed at all, the money won’t be received, the client will remain unsatisfied, etc. After a certain point, both sides lose interest.
Business is such that if, say, you haven’t launched a new product (website, store, or something else) in four months, the volume of changes over that time accumulates to the point where you might as well throw everything out and start over. Of course, nobody goes for this, and the system gets patched up.
Moreover – the longer the project, the more likely it is that the client will change their mind, that key people on the client’s side will change, that the market situation will change, and in our country, anything can happen. Therefore, everything must be done quickly.
The second problem is that when a project is stalled (no matter the reason – the client is slow in providing data or the developer is falling behind), the costs of labor continue to eat into the project budget. If the development company, in an effort to economize, reduces the resources allocated to the project (by switching someone to another project), it leads to a loss of interest and motivation in the team to finish everything on time and to do it well.
But how to fit a large project into a small timeframe? Here many make a big mistake – they create an excessively large team. Pushing resources should only be done to pull a project out of a mire, but not in its normal planning. A large team increases the number of communications within the project, which in turn increases the volume of documentation and the contradictions and ambiguities that permeate this documentation.
Therefore, we try to make everything very compact and try not to inflate the team without a very great need. Unfortunately, to achieve this goal, it is sometimes necessary to mix some roles that should be separate in the team for large projects. But if you separate them, then the problem of increasing the number of communications arises, and as a result, the increase in timelines and budget. And the growth of timelines – see point 1.
Therefore, for e-commerce projects, I believe in compact teams, dedicated 100%, consisting only of versatile professionals capable of making revolutionary changes in a short time, launching, and then it can be transferred to calm support.
By the way, we are looking for a developer (Java/Spring), QA, business analyst, and systems engineer. Recommend them, we have a good team.
Hi, I'm Rauf Aliev. 