Monitoring the Health of a Development Project

I have been thinking about this role for quite some time now. I have had the chance to work on a couple of development projects and one thing that stood out in common was the lack of time invested in design reviews, code reviews, etc on an ongoing basis i.e. throughout the life cycle of the development project. Even if there were reviews, most of them cited the obvious, which mostly revolved around good naming conventions, etc. But what I had been looking for is a review that could help me validate my choice of a design principle or a strategy to solve a complex UI requirement. But unfortunately nothing much happened on this front.

The following are the reasons why I feel that there haven’t been enough reviews happening in most development projects:

1. Too many meetings – This is probably the main culprit. I observed there are way too many meetings happening all the time and you would have all the leads attending one meeting or the other all the time. It leaves them with very little time in a day to focus on the “Actual Task” at hand.
2. Lead to Developer ratio – This is another major contributor for the lack quality reviews from leads. A good lead (Module lead) to developer ratio 1:3. Why this ratio? I feel that a module lead can devote his time towards 3 developers at the max and still be able to deliver as expected. Once this number exceeds, things begin to get a little bit out of control. A lead then has to start spending a lot more that required time with developers to clarify and addressing issues. This leaves him with little time to focus on his regular tasks like code reviews or low level design. Hence it is very important to maintain this ratio.
3. Process is a means of achieving the end result not the end itself – Let’s face it. Process is good. But it should always be adopted with a pinch of salt. If we bring in too may processes, it will only introduce too many levels for achieving something in a project. I am talking here about some process which has just been adopted because you wanna come out clean in some XYZ standards audit. Heck! it’s not gonna work. You may end up having followed all the processes but the end deliverable is not just what the customer wanted. It is more of a “means” to achieve results and not the “end result” in itself.
4. Dead lines – I had written it before too. Just re-iterating it here; Deadlines often introduce a lot of dead lines of code in a project. It is very important to keep a tab on the time lines and make the most out of it. Hence the development team must get its due time. Reviews must happen on time and shouldn’t be a post harvest/project retrospection activity. Looming deadlines should never be a reason for postponing reviews.
5. Lack of demarcation of roles and responsibilities– A project must have a clear demarcation of roles and responsibilities. This is required for 2 things. Firstly, It sets the right expectation with the person discharging the responsibilities associated with the role. Secondly, it avoids unnecessary confusions and duplication of efforts in the team since everyone knows exactly what he/she is supposed to do and not to do. Sometimes it these little things like knowing exactly what to do that can work wonders for a team in a time crunch situation.

Due to the above, we find a lot of projects deviating from their normal course, without getting noticed. Can this be avoided? Can a project be saved from gradual derailment?

I think yes! What we need to do, is to introduce a role into the project, that would be of a dedicated reviewer.

Some of the salient responsibilities of this role could be:

1. Ensure that reviews are done on time and development team get good feedback on their implementations and designers on their designs.
2. The person assigned with this role, would be accountable for ensuring the reviews happening on time and not the execution of the end deliverable in itself.
3. The person is expected to be available at all times to provide feedback and flag deviations as soon he/she identifies it in the project. This would help teams to rectify inconsistencies as soon as they get introduced into the system, either in the design or implementation.
4. Facilitate the development team in identifying re-usable components as and when he/she discovers an opporunity.

After going through the above description of the role, you might get a feeling that the role is very much close to what a Technical Lead it supposed to do. Ain’t it? But I beg to differ with you here and here’s why.

A Technical Lead is not only accountable for giving a high level design but also is highly accountable to the actual deliverable. Hence his scope of work often spills over from just technical guidance to managerial aspects of the project. It would also get increasingly difficult to attend to the queries of the entire team.

Hence there is a need for a role whose sole responsibility is to monitor the health of the development project. Give quality feedbacks and conduct "continous reviews" and ensure the project's health is always green.