A few days ago, I was released early from a contract because of capital cost cutbacks. Then a heat wave hit. I don't handle heat well; my salvation in the summer is usually working in an air conditioned office. My daughter works in a local college which is both air conditioned and open to the public, so we invented "take your Mom to work" day, modelled very loosely on "take your kid to work " day, an annual event here.
When she introduced me to her co-workers, one of them jokingly called me a "lazy bum" because I was not working. I replied that I am on full salary, at least until the money in my consulting company runs out. But it made me think about the similarities between consultants and projects.
This was my first contract after three years as an employee. When I last contracted, I learned how to survive as a contractor. After 4 1/2 months as a contractor, I have a cushion which will allow me to pay myself for about four months. I can stretch that to six months, if I really need to. Even in this economy, I shouldn't be without work for that long.
This works solely because I plan for it. Some of my colleagues gleefully spend all the extra money they make contracting, then panic if they can't find work immediately. I was let go early because the company I was working at acted the same way.
This project has all the classic problems. It is a textbook example of the trouble with date driven projects. It is a major and highly visible project to develop several new applications and integrate them with a large number of legacy applications and a third party order system. I was warned in the interview that the schedule was very aggressive. If I was smarter, I would probably have run away screaming. I like integration projects, so I interpreted very aggressive as lots of overtime and took the job.
I quickly discovered what very aggressive really meant. The project was staffed with in-house systems people, staff from the outsource company, members of the preferred consulting company (Jerry Weinberg would call them a grape jelly company), and a few independent contractors. There were a very few users, part time on the project and still trying to do their "real" jobs. The theory was that the first two groups were familiar enough with the business to define the requirements and do User Acceptance testing. That's a popular theory. I would like anyone who has seen it work to share their experience.
Management originally announced the project as six releases, beginning last December and ending in June. I was hired in February. Estimates, where done at all, were done based on insufficient data and evidently ignored by management. The testing team did two sets of estimates while I was there, both used to justify delays. Neither of them was taken into consideration in planning the next date.
The third party software package was to be an upcoming release. The vanilla version was significantly different than either the version in use or what was required, so a major customisation effort was required. The current version of the package was only in use in one small office. Development of both the new release and the customised version was going on simultaneously with development on the new in-house software. Development of each new system, the third party software package, and the changes to each legacy system were handled independently. Functionality slipped one release at a time, with something always delivered so that a success could be announced. This is a national company; the project was to use a virtual team. As the schedule slipped, more and more people were relocated, with development in one city and testing in another, as there was insufficient space available in any one location. Many people started travelling every week or two, spending most of their time in hotels. Travel time was not paid, so most people travelled during working hours, losing about a day a week. Expenses skyrocketed. Two thirds of the way through the project, an Integrated Design Team was formed to deal with any integration issues. Need I go on?
When I left, the final release was late, and most of the functionality for all six releases was to be delivered at once. The final release dates had slipped two months and some functionality had been deferred. Because all schedule changes had been justified as "more convenient for the users", not project problems, these dates are probably no more realistic than the others. Management appears to believe their own press and refuses to cancel, to stop and estimate properly, or even to investigate the issues. While I found the system fascinating and really like some of the people, my strongest feeling when I left was relief. Until you are prepared to admit there are problems, you cannot begin to deal with them.
I wonder if the project would have been successful in the same timeframe if we had been allowed to do properly from the beginning. There were some very talented people working on this project. If we had started with the integrated design, real users, real requirements and a schedule based on realistic estimates, I know it would have saved time and money, much of which was spend in rework, often caused by redefining releases. I hope for the sake of those who are still there that something will be learned from this project. When one contractor spends money like there is no tomorrow and forgets to consider the future, the results are often unfortunate, but the effects are personal. When large companies do it, the repercussions are widespread.
Email this article to a friend.