VBNotebook Home | Articles | When Projects Go Wrong

All of us would like our projects to come together like something out of a textbook, perfect and with few, if any, problems. However, in the real world of rapid application development, we find many things break early and often. In my experience and in the experience of others who contributed their experiences to this page, the problems often arise from conflicts with non-technical management, technical managers whose technical skills are outdated and the political infighting that can surround a software project.

Here are a few examples gleaned from real world experiences in doomed projects and death marches from my own experiences and those of friends and associates. Most are told from the perspective of a lead developer or the development team. While most are from Visual Basic projects, some are from other types of projects, including C/C++ and Delphi ones.

Treat them as both shake-your-head-in-disbelief humor and as cautionary tales of what can easily happen during the course of a project.

Design and Project Startup Phase

* You schedule JAD sessions with your internal client department. One or more key players won't be able to attend the sessions because of sudden scheduling conflicts. Your manager says that you have to have the meetings anyway. The person or persons who weren't able to attend later attempt sabotage the project out of spite.

* A manager in the client department with a reputation for being uncooperative and difficult to work with has been promoted ‘out of the way’ into a ‘do nothing’ position. She did, however, have a lot of input into to the project design at the start. Therefore, she constantly works to undermine the project hoping to score political points against rival managers in her department.

* When you attempt to draw up uses cases, object models, GUI prototypes, development schedules, and so forth your boss complains that you aren't showing any progress on the project. He wants to know why your team isn't coding. 

* You submit a tentative development schedule to your boss. He, in turn, shows it to his boss or an executive committee. They decide that you don't need so much "fluff" in your development schedule like use cases and prototypes. They remove them from the schedule and tell your boss that they expect you to start coding now.

* In order to begin development work, you must have the project sponsor to sign off on the design. Of course, they give cleaning their coffee cup, sleeping in their office, and complaining to their management about your lack of progress a higher priority. Eventually you have to start developing without a formal signoff due to pressure from your boss. This leaves the project sponsor free to complain about the results later or even reject the project entirely.

* If your manager does allow you to do things like drawing up uses cases, object models, and GUI prototypes, and reasonable schedules, his bosses will view him as being incompetent and/or indecisive. He'll be fired or reassigned as a result. A ‘results oriented’ manager (aka a total jerk, a Bill Lumbergh type) will be brought in to replace him to get you back on track. 

* You submit your scheduled milestones to management. They cut them in half to meet an arbitrary "drop dead" date to deliver the project that totally ignores your schedule and your staffing needs. Amazingly, this will usually coincide with the annual sales meeting, a merger, an industry event, or even the day before the boss wants to leave on vacation. To meet the new schedule, you will have to hack the entire app together quickly rather than having reasonable project milestones.

* When staffing a project, your manager and/or human resources hires employees and/or brings in contract help based on their cost, not their experience and skills. As a result, you have developers on your team who you will have to train as you go or who are simply dead weight.

* You are handed a GUI design that's completely unworkable. You are told that you must implement it anyway. 

* The required GUI design prevents the use of standard Windows controls. This will increase the development time required, but you aren’t allowed to reflect this additional work in your schedule. 

* Higher-ups make the decision that the GUI design must incorporate the latest graphics from marketing so that the application will match brochures and other advertising copy. However, marketing refuses to give the team any graphics at all or only provides graphics in a proprietary Mac format that can't be converted.

* Marketing gets into a cooperative mood after a little prodding and provides the necessary graphics. However, when they see a prototype of your app, they complain bitterly that you've ruined the graphics presentation. They even bring a Pantone color wheel to a design session to show you what you did wrong. Unfortunately, they don't understand that your specs call for a maximum of 256 colors or 'web safe' colors. They withdraw their support and proceed to trash your project to company executives.

* Powers that be within the company have decided to use a complex design methodology on all software projects. Of course, the methodology is completely at odds with rapid development strategies and requires a lot of additional work. However, you can't reflect this overhead in your schedule. 

* You have already developed a successful application for your division of the company. Upper management likes it and decides that it could be implemented in another division with just a few modifications. When the other division sends you their change requirements they’re much more than ‘just a few modifications’. In fact, it almost calls for virtually a completely new application. Of course, the ‘just a few modifications’ project schedule is the one that stands. 

* Your project is stuck in design mode. Sponsors refuse to sign off on the completed design specs so that you can start coding and seem to stall at every turn. Your management seems relatively unconcerned about this although they expect your team to do a lot of ‘busy work’ and status reports but insist that you should not do any actual coding. Suddenly, your whole team is reassigned or fired. You discover that the project was intended to support some executive's political position and your team was the sacrificial lamb when this political maneuver failed.

Coding the Application
 
* There is a company wide reorganization or the company is sold to another company during the course of your project. Management and/or sponsorship of your project gets shifted to a new group who has completely different ideas about the product should be done. Of course, no adjustment to your schedule or staffing is allowed.

* Your project's sponsor goes to another company or position. The new sponsor decides that you should start over again with her ideas, although you're 3/4 of the way through the original project. Once again, no adjustment to your schedule or staffing is allowed.

* To meet the accelerated schedule your team codes like crazy and delivers the first cut of the product to QA testers. The QA testers can't figure out how to install and run the app but they don't tell you this for several weeks. They complain to management that you haven't delivered a "testable" product to them yet (behind your back, of course).

* Since the project is being proclaimed a failure at this point by it's sponsors and QA, your manager decides that you and your team aren't motivated enough. He decides to have daily 9:00 a.m. and 5:00 p.m. status meetings to help track your progress or lack thereof. These two hours of meetings aren't reflected in the schedule either.

* The division that’s sponsoring your project gets impatient with your progress and sends over one or more ‘black belt’ programmers to help you out. Sadly, even if they are really programming ‘black belts’ it certainly isn’t in the technologies you’re using on the project. But, this won’t stop them from stepping in and recommending and even implementing wholesale changes that impact your project schedule and kill your productivity and team morale.

* Office space is tight and management's solution is to crowd programmers in like sardines, oblivious to the effects of this arrangement on productivity. Supply closets without air conditioning vents are a particularly popular place to squeeze 4 or more heat producing bodies and computers into. Or, they acquire temporary additional space but to save money on furnishings they seat programmers at rickety portable tables and cheap stackable chairs instead of actual cubicles or desks with decent office chairs.

* Your manager gets chewed out by his manager because of your 'lack of progress' on an unrealistic schedule to meet an arbitrary deadline. In turn, your manager calls a team meeting where he cusses out the team and questions their ability as programmers.

* The company CEO or other VIP stops by to see your project and is somewhat disappointed by the lack of progress. He asks if it would be a good idea to add a second and third shift of programmers to help complete the project. 

* Due to economic conditions everyone is fearful of loosing their job. They know there are a dozen unemployed programmers who would take their job ASAP. As a result, a rosy and unrealistic picture is painted when discussing the course to the project with upper management while the development team knows how troubled the project really is.

* Your manager, fearful of loosing his job, tells upper management that everything is on schedule. That is on the highly aggressive schedule that has no basis in reality that upper management expects. The development team is then browbeaten into accepting the new, unrealistic, schedule even when they know it can't be done. Of course, the team's manager makes an effort to hide the real situation from upper management.

* The upper managers decide to bring in an outside consultant to analyze what's wrong with the project. The consultant requests a lot of busy work, such as documenting procedures and code that's still under development, that takes the team away from their development work. Of course, the schedule is not changed to reflect this distraction. The project team has lengthy meetings with the consultant so that he can put down the development team's skills in detail, even though he hasn't written a line of code in 20 years and certainly never done any coding at all in the language you're working in.

* Management brings in an outside consultant to evaluate your project. His conclusion? Replace the programming team with people from his company.

* When your manager has a meeting to review the project schedule, this means the entire project schedule, not just the current or relevant items. Even action items that are not slated to begin for several months must be carefully reviewed. Of course, these long meetings aren't on this detailed schedule.

* Upper management decides that cause of your group's perceived lack of productivity is because it isn't being managed enough. Therefore, four more managers are assigned to 'assist' with your project.

* Your manager goes on a lengthy vacation while the rest of the team is denied even a day's leave.

Deploying the Application

* 3 or more departments are given "go-no go" authority on deploying your project to internal clients. Of course, the managers of these departments are at odds with each other and demand changes that the other department heads won't accept. You get into a cycle of making a change for one department only to have it rejected by another.

* You get a call from the tech support department. It seems a customer is having a problem with your new product. You tell them that the product isn't shipping yet and you call the customer yourself to check out the story. They do have the product and you ask them how they got it. After a little investigation, you discover that their salesperson had taken an internal beta of the program from the QA lab and had it installed at his customer's site. All of this was done with the permission of upper management so as to meet last quarter's sales quotas. 

* You are forced to deliver the product to users before it's ready in order for sales people to meet their quotas or for it to be presented at an industry event. You then spend the next several months doing the work you originally scheduled for but you weren't allowed to complete.

* Your team actually completes the project when you originally said it would be done. Of course, everyone has forgotten this by now.

The Aftermath 

* The sales manager, who has made a huge commission/bonus on the sales of the new product, well into 5 figures, decides to reward the development team. His idea of a reward: a "PayDay" candy bar for each member of the team.

* After slaving away on a money making project for the company, your team asks for a simple item to commemorate all of their hard work. Your team and your manager decide on a polo shirt with the product logo stitched on it. After waiting and waiting the big day comes. A company-wide meeting is called and the your manager's boss, after praising the team, says, "The project shirts are here." Everyone applauds. The boss follows up by saying, "Anyone who wants one will need to cut us a check for $49.50." 

* The program has serious problems due to the highly aggressive development schedule and/or serious design flaws requested by project sponsors. The answer: fire the programmers involved.

If you have your own project horror stories please pass them along to me and I'll add them to this article (and give you credit, if you want). In the mean time, don't forget your TPS reports.

Copyright 2000-2005, J. Frank Carr