3 min to read
On Project Ramp ups
As I think back about all the failed projects that I had seen, I recognize one unifying feature about them. They all took too long to ramp up! I am not saying that they did not spend enough time on design or architecture. On the other hand, many of these failed projects spent an inordinate time weighing on alternatives, designing, documenting, estimating the effort and the like. But they failed to recognize one little truth. All the effort expended here is fruitless without code! It is just, as one of my colleagues puts it, “intellectual masturbation” at this point in time.
Code, like good wine, takes time to mature. The earlier you write the code, the more opportunity it gets to evolve. The same arguments apply for a development team. A development team has no sense of belonging to the project in the absence of code. They sit nonplussed by the surfeit of documentation that surrounds them. Give them an IDE, a proper module structure and some code to write and voila! watch the difference.They start getting involved in the project.
As human beings, I think, we need the ability to mentally slot things. We cannot work with intimidating wholes. We need to break them down into their constituent parts. That is only possible if we are given the slots to put the parts into. A module structure gives the developers just that ability. It tells them that the problem at hand needs to be broken down into smaller consumable units which can then be pigeon holed into individual modules. As the modules have been set up in the IDE, the developers are able to translate the requirements into stuff that they can relate to.
This makes all the difference to a project. As the developers and their code start “soaking in” , the project gets more mature. In a month or so, the developers become adept at the code and the environment. The code starts becoming more stable as it starts getting exposed to more testing very early. The inception stage in a project is a tension free time. ( as indicated in the diagram below) . Hence extra effort expended at this point is sustainable. As the release deadline approaches, the tension starts to mount. But if the team has been ramped up adequately, the stability of the code reinforces confidence to the team about the feasibility of meeting the project release deadline.
IMO, the diagram below represents a good recipe for a project. The initial “tension free zone” needs to be utilized to ramp up both the team and the source code. The source code must have been modularized and set up in individual developers’ IDE by the time the actual coding phase begins. By that time, the team should have got ramped up and must be performing at its optimal effort level as indicated by the purple portion of the diagram. There would be a spurt in effort required as the current release approaches culmination. However, that effort spurt is minimal and is not even close to the spurt that was originally expended during ramp up. We all know that tension and high effort levels lead to quick project fatigue resulting in considerable productivity loss. Hence it is imperative that we ensure that the team is comfortable as we approach the release date.
Also, observe that even the spurts do not take the effort level anywhere close to the saturation point.
It is important that we ensure sustainability for the team by keeping their effort as much possible at the optimal level. Sub optimal level effort is wastage of resources. Spurts over the optimal effort level are necessary but cannot be protracted over a long period of time.
All failed projects were characterized by super demands on effort level during the period preceding the project release. This lead to a considerable loss of productivity and increased the risk of attrition.
In my projects, I tend to encourage a “war room” kind of atmosphere during inception so that the team quickly gets off the mark!
Comments