I, like most people, don't like to piss off other people I work with, especially my boss and his boss. I estimate this is true of about 95% of the normal humans in any workplace. The other 5% fall into a category of people I sometimes admire - those people who do not care if they piss off co-workers, and the subcategory of those who actively try to do so.
But I digress - The tendency to not want to piss off one's boss and higher-ups has a well-documented effect on project estimating and scheduling. My project team and I are living with the consequences of such effect as I write this. A year ago, we took a project we had spent the previous year trying to get done with a recalcitrant vendor back in-house and relaunched it ourselves, with much enthusiasm. The technical lead, key team leads, and I all collaborated on the best estimates as we could possibly do at the time, knowing full well that there were many unknowns that we would encounter throughout the project.
I insisted that we would use our ongoing learning and refinement of estimates to present a worst case, best case, likely case scenario of completion dates. Initially, management was not comfortable with this approach and asked for more refined dates. I maintained that this was not possible nor responsible, and we would continue to stick to this model. This approach earned the respect and appreciation of the project team.
However, this approach did not change the fact that upper management still wanted to ensure the project was completed as soon as possible. Feeling this pressure and wanting to avoid presenting dates that would cause agitation is what led the team and me to make a crucial estimating, planning and scheduling mistake. We had divided the project up into feature sets. Each feature set contained functionality development and other work related to a particular area of functionality. One example would be "US B2C Website" to denote all functionality and related work necessary to develop and deliver that e-commerce experience.
The plan called for 4 - 8 weeks of work and testing on each feature set followed by a release and demo to the business owners. The plan also called for the business owners to review and test each feature set after the release, provide their feedback and alert us to bugs. The plan did not call for a dedicated testing and bug-fixing period by the project team after each feature set release, and this is where we compounded our mistake, out of the desire to avoid upsetting management with completion date extensions.
After each feature set release, the team met to review the processes we used, revisit the project risks, and plan the next feature set and update the overall project schedule. After the first couple of releases, the project team realized the need to have a dedicated period of project team testing and bug fixing prior to kicking off the next feature set. However, we also realized that this would add a couple of months to the project schedule - a schedule that was already beginning to lean towards the high-end, worst case estimate for a completion date. We feared going back to our sponsor with the news that the project would take far longer than what he and others we expecting.
So, we pushed on without adding the extra time after each release. Our first pass at user acceptance testing (UAT) went badly, and we ended the scheduled week of UAT after two and a half days. A few more weeks of bug fixing and testing positioned us to launch another round, but problems stabilizing our environments led us to call off that round, too.
We're now two and a half months past our worst-case release date and the team is still testing, finding and fixing bugs. We're so close to done, and the bugs found are progressively easier to fix, but it is time-consuming and tedious work for the team. Everyday, my boss, the sponsor, asks when we will be ready for UAT and to release the site.
The project team and I recognize that the hours of comprehensive testing we're doing now are a direct result of not doing the testing incrementally after each feature set release. But at the time, it seemed more necessary to avoid the negative reactions that we perceived would come from extending the schedule by two months than to face reality and add the time.
This is testament to the influence that fear of pissing off one's boss, management or sponsor can have even over highly experienced project managers and project team members. My scenario occurs in a fairly open and trusting environment, so this speaks volumes on how far business project environments in general have to go to ensure that project estimates and schedules are developed without the influence of fear.
No comments:
Post a Comment