In the previous post on this topic (Risk planning by looking at confidence level of estimates), I talked about the difficulties posed due to discrepancies between the original estimates done at the time of planning, vs. the actual efforts spent on the work when the features are in development. Tracking these discrepancies and working out some kind of logic about these discrepancies is very important for the project manager. Typically, the estimation is done by the senior folks on the team while the person who works on a specific feature can be anyone on the team (if the work is specialized, then it would be allocated to somebody who has more experience in that area, but that person could still be different from the person who did the actual estimation).
So what do you do ? Well, you would typically track the estimation against the effort, and try to figure out whether there is some kind of logic. Sometimes, there is a possibility of generating some logic to figure this out. We had a case whereby the person who preparing the estimates had a person situation during the time that he was working on the estimations which was very distracting (but not enough that the Project Manager could figure out that here was a problem). So, soon after the actual work started, some data analysis about the discrepancies resulted in figuring out that the actual effort was about 25% more than the estimates where this particular person was involved, and this helped us in re-estimating the remaining features and also making a decision that a particular feature needed to be stripped down, the scope of the feature reduced for getting everything in the time frame.
However, what was interesting was that this logic was actually seen by a member of the team who pointed this out, and though it seemed a bit strange at first, more analysis helped. Some speaking to the people who had already worked on the features that this person estimated tended to confirm that they believed that the features were under-estimated. What this incident showed was that this provided us (the leads and the project manager) that we should get the team more involved with the risk planning and analysis that we do, such that sometimes it would be possible for them to identify a pattern that we might miss. There were other smaller cases that we could see.
One problem that was told to us before we started was that it was supposed that this would distract the team members from their regular work, and, many of them might not be interested in being involved in such kind of analysis. We did find people who were not interested, but we did start out with the entire team, making them involved with the process we did for identification of risk factors, gathering the data and then doing the analysis. About the time it took to do this, we figured that overall this would take an hour per week, but getting team members involved with stuff such as this would help give them a better perspective on some important processes that team leaders go through and when they could see the problem, they had a closer perspective on some of these risks and could figure out solutions for a percentage of these cases faster than we could. This helped save time overall, and after a couple of rounds, the people who elected to remain involved were appreciative of the learning they got from such exercises.
So what do you do ? Well, you would typically track the estimation against the effort, and try to figure out whether there is some kind of logic. Sometimes, there is a possibility of generating some logic to figure this out. We had a case whereby the person who preparing the estimates had a person situation during the time that he was working on the estimations which was very distracting (but not enough that the Project Manager could figure out that here was a problem). So, soon after the actual work started, some data analysis about the discrepancies resulted in figuring out that the actual effort was about 25% more than the estimates where this particular person was involved, and this helped us in re-estimating the remaining features and also making a decision that a particular feature needed to be stripped down, the scope of the feature reduced for getting everything in the time frame.
However, what was interesting was that this logic was actually seen by a member of the team who pointed this out, and though it seemed a bit strange at first, more analysis helped. Some speaking to the people who had already worked on the features that this person estimated tended to confirm that they believed that the features were under-estimated. What this incident showed was that this provided us (the leads and the project manager) that we should get the team more involved with the risk planning and analysis that we do, such that sometimes it would be possible for them to identify a pattern that we might miss. There were other smaller cases that we could see.
One problem that was told to us before we started was that it was supposed that this would distract the team members from their regular work, and, many of them might not be interested in being involved in such kind of analysis. We did find people who were not interested, but we did start out with the entire team, making them involved with the process we did for identification of risk factors, gathering the data and then doing the analysis. About the time it took to do this, we figured that overall this would take an hour per week, but getting team members involved with stuff such as this would help give them a better perspective on some important processes that team leaders go through and when they could see the problem, they had a closer perspective on some of these risks and could figure out solutions for a percentage of these cases faster than we could. This helped save time overall, and after a couple of rounds, the people who elected to remain involved were appreciative of the learning they got from such exercises.
No comments:
Post a Comment