“This is an interesting article on the reasons why projects often focus on being timely rather than meeting quality or managing cost. But it seems to place the overwhelming “blame” on the IT team. While I am sure this is true in some cases, I believe the bigger truth is often more complicated. First, unless it is a one off, this tendency to launch on time and sacrifice quality and cost is an institutional problem. After all, it is not only the IT team’s compensation that is tied to the project, it is also their boss and their boss, and so on. Thus, the problem is one of culture. Second and perhaps a more fundamental reason why schedule is placed on the pedestal of project management constraints, time is absolute. If you’re late by 1 second, you are late. Costs can manipulated, quality is often in a range tolerances, and scope is changeable. There is no other factor like time, it time is absolute”.
Te Wu’s comments on the David Taber article titled “The dirty secrets of project management revealed” for CIO Magazine (below).
David Taber for CIO writes the following: For business systems, the project go-live date really does matter — and project managers seem willing to sacrifice budget limits more often than they’re willing to blow past a scheduled deadline. There are sound business reasons for doing this as bonuses, commissions and stock valuations depend upon the revenues and earnings for the quarter. So you don’t want to make any changes that would mess up this quarter’s results, but you do want to implement changes as early as possible next quarter.
Now for the problem: You’ve got a few days to go, and the time pressure to do the cutover will only increase. And with that, the collective IQ of the project team will only decrease. Because of the 4th of July weekend, everyone will be lobbying for a slash-cutover to the new system so everyone can make their Q2 bonuses.
Institutionalized rationalization?
In the final push to release, you’ll hear all kinds of helpful suggestions to expedite things:
- Skimp on unit tests, focus on integration testing.
- Do integration testing and user-acceptance testing in parallel.
- Skip the configuration control overhead.
- Do debugging and make fixes directly in production.
- Skip some of the harder test cases, particularly for integrations.
- Do functional testing only for the top three use-cases.
- Shift the user-acceptance testing to an offshore team.
- Worry about data quality after go-live.
- Bring in a tiger team of additional staff.
- Get the consultants to work double shifts.
- Forget about doing business process validation and code reviews.
- Don’t turn on all the integrations until later; do nightly batch data updates to keep things somewhat synchronized.
- Spin up a shadow copy of the new system and have a few low-impact users on it, so you can claim go-live even though the heavy-lifting users are still on the old system. Meanwhile, developers will work only on the real version of the new system where there are no users. (You can call this the “Potemkin Village” strategy – you’ll also need some low-cost offshore resources to do the triple-entry of data that will be required.)
- Don’t do short weekly, task-based, effective training. Instead, do it as one day-long session.
- Skip the luxury of hand-holding, developing power-user mavens, or go-live-week support. These things will just happen on their own, and our developers will need to get on to the next project immediately (because that one’s late, too).
In other words, you’ll hear all kinds of half-baked, rookie ideas coming from people who are otherwise professionals. This is the kind of stuff you’d immediately reject a job applicant for suggesting, but when the ideas come from a review committee full of bosses…well, you sometimes have to bite your tongue (and sometimes almost clear off). Snip, the article continues @ CIO, click here to continue reading….