Books have been my constant source of enlightenment. A few weeks back I laid my hands on the seminal book of project management “The Mythical Man-Month”. Actually there is another book that I would like to lay my hands on – Peopleware – Productive projects and teams. I could not help but reflect on the fact that opinions expressed some decades ago are still valid in today’s software engineering world.
Goes to show
History repeats itself.
One of the first opinion expressed was around estimation.
Our techniques of estimation are poorly developed.
Now I have been around in this software industry for more than a decade. I have yet to see a project which has been delivered in the time lines promised during the project initiation. The causes of delay/failure are numerous
- The estimation team lacks domain expertise.
- The business does not state all their requirements and whatever is stated is a 10,000 ft point of view.
- The programming expertise of the team is inadequate.
There just are too many moving targets. The requirements constantly change leaving the code in a state of flux, change request management is horrifying and the team has people with varying levels of experience and backgrounds all contributing to a deliverable of poor quality. I believe the key challenge to getting requirements right is clear communication between the end user and the developer. Requirements are of two types: stated and unstated requirements. Unstated requirements are those which the end user perceives to be too obvious to be put down in the requirements document. From a software development point of view it is imperative that the person documenting the business requirements from an IT standpoint have extensive domain experience so that he/she is able to grasp the unstated requirements and incorporate them in the document.
Schedule slippage is recognized and the natural response is to add manpower.
Recently we had a project which was running into schedule slippage. The project by its very nature was complex; the project team was struggling to cope and client was fast losing confidence in our ability to deliver a quality deliverable. Cometh the moment cometh the top brass. The wise old heads with decades of industry experience decided to do the traditional thing. Throw people at the problem. The end result the project team size ballooned from a 25+ team to a gigantic 80+ team.
So you wonder what was the end result? The top brass expected the project bugs to get fixed in quick time. After all if one person can fix 1 defect per day; 80 people should fix 80 defects a day. Simple! Unfortunately things did not pan out that way. The new joiners needed to understand the complex application and they were in no position to fix complex bugs. So the people since inception started helping them out resulting in their lost focus causing fewer bugs to get fixed. The exercise instead of being beneficial proved to be counterproductive. After around a month or so the additional workforce was soon getting removed from the project and the earlier core team remained.
To sum up,
The more things change, the more they remain the same.
Let’s see what other enlightenment the book gives me.