I think 80% of the project work is completed in 40% of the total time while it’s the remaining 20% that takes 60% of the time. Those of you who ever had to manage a project will notice that the it starts very slow and then it picks up speed and you see a lot of progress being made everyday but suddenly towards the end it slows down again and you feel that your team has lost the zest or they are slacking behind. But is this not expected ?
if you plot the progress of the project (% of feature completed with time), you will see it takes up a S-curve as below:
Let me explain why initiation and closing is slow.
During Initiation
Initiation refers to the starting phase of the project when you receive the notification that the project has started. It needs to be understood that unlike race-course horses, developers cannot dash out the gate at full throttle towards the finish line. They have just been allocated and they don’t even know what the project is all about. Here are some reasons which will slow down the progress during the starting phase:
Team Establishment
This is not about allocation of people. The team goes through a whole stage of Forming-Storming-Norming-Performing (Bruce Tuckman). This duration of this cycle depends on both the size of the team as well as diversity of domains/specialization within the project.
Ambiguity in Requirements
From no documentation to hundreds of pages of requirements, but I am yet to see a requirement document that is understood exactly in the same way by all people. There are multiple round of discussion between the team members and with the client during which the progress seems frozen.
Tools and Environment
In certain cases the project is dependent on tools and environment which is hard to duplicate in our development environment. I once remember a search engine portal project that we were doing in which our job was to make some enhancements. The current system extensively based on XPATH queries and we lost 10 days in just setting up the system on our server. In another project we are doing, the client had four different versions of the same application and the application called files (PHP includes) from multiple versions. We had to set up a team of 3 people for 7 days just to clean up the code and set it up on our servers.
During Closing
Closing is the abyss between when a developer says the job is complete and when you say that the job is complete. Here is what happens:
Product Integration
Often we have to wait for days (or weeks) for simple things like Payment Gateway info, SSL Certificate or information from 3rd party vendors on proprietory systems (web services) that the system must be intergrated with. Sometimes, server does not supports parts of codes that we have written and upgradation of server or rework of code is required.
Note: CMMI required all integration requirements and environment to be planned earlier but still, if your hosting company responds to request within 5 days then what are we supposed to do?
Defects
As more features are added into the system, more bugs are also introduced. As the bug database takes a life of its own, there is a tendency to increase the mix of bugs to new client-valued functions being coded. The result is that the overall speed of the team is maintained but an increasing percentage of the effort is devoted toward fixing bugs or adding “bells and whistles”
Enhancements
Buy enhancement I am referring to all the things a developer had to do which he did not knew he will have to do when he started the project. This mostly comes in the form of – “Of course it was supposed to be there!” and with some luck we will be able to point back to requirement document and say “nope!”. The problem is that time is spent in these negotiations and discussions which would rather be spent on stabilizing the current set of features that the product already has.
At the end, I remember what one client told me – “Project is like painting the wall – it’s the corners that take most of the time!”
