These days I work with a bunch of very smart people that know a lot about how to implement social media solutions (you can even chat with some of them here). But back when dirt was new, I used teach software development methods and project management. My old friend and colleague at the time Ken Orr had observed that a lot of failed projects had similar profiles, and came up with a template for failure he called “Project Titanic.” We used it at the time to illustrate how *not* to do projects. I dig it out every now and then to see how far we’ve come as an industry since the mid 1970’s. Judge for yourself.
Step 1: Assign a due date and a budget. The two things you know the least about; actually it turns out this is an important step. It announces to all involved with the project the exact time and place when failure is to occur.
Step 2: Assign the project an acronym. Either three or four letters; should include one of the following words: “Management”, “Information”, “System”
Step 3: Select a Project manager. A classic catch-22: anyone who applies for the job is instantly disqualified, since anyone who has ever been the project manager on this type of project is smart enough not to apply.
Step 4: Develop a Requirements Document. You know: the 10 pound requirements specification developed after talking to the user about their requirements for a few hours. Quantity is important. Use lots of graphs.
Step 5: Get User Approval. Actually this isn’t too hard. If the requirements document has used up 60% of the budget, the user community is unwilling to stop the project without having anything to show for it.
Step 6: Hire Systems Analysts. Someone needs to do the following work.
Step 7: Develop the Input Forms. It’s important to do this early, otherwise the three-part perforated color forms won’t be back from the printers in time for the projected start date.
Step 8: Hire Programmers. Someone else needs to do some real work.
Step 9: Develop Edit Programs. Results in a minor feedback loop since it inevitably results in changes to the input forms. Hope that the printer hasn’t gotten too far along with the job.
Step 10: Develop Conversion Programs. After all, we wouldn’t want that old bad data to just reside in the old system.
Step 11: Develop Data Files. You have to have some place to store the old bad data.
Step 12: Develop Update Programs. You have to be able to add new bad data at some point.
Step 13: Hire More Programmers. It’s usually around this time in the project that people realize that things aren’t going well. The project is obviously behind, but no one wants to admit it, so we hire more programmers. Now if programming is like digging a ditch, four hundred people can get a ditch dug faster than four people; unfortunately programming is more like digging a well: four hundred people can’t dig deeper faster than four people, you’ll just have people stepping all over each other and the well will be a lot bigger around when you are done.
Step 14: Begin Work on Outputs. Finally someone begins to ask embarrassing questions like: what is someone going to want to do with this system. Unfortunately the answer usually invalidates all the input forms, edit programs, update programs, data files, and requirements specifications. Now is a good time for all members of the project team to update their resume.
Step 15: Slip the Schedule. Call the user back. “Remember the system that was supposed to be delivered in January? Well, it’s going to be more like June….of next year.”
Step 16: De-Commit. Call the user back. “Well, Okay, we’ll meet the revised June date, but the system won’t quite have all the features we originally talked about. The new payroll systems won’t be able to actually print checks for six months. If it’s all that important perhaps we can throw something together to print them off in hexadecimal for the interim.”
Step 17: Panic. The fan and the excrement at last collide.
Step 18: Search for the Guilty. This goes without saying. Someone must be responsible for this mess.
Step 19: Punish the Innocent. The classic audit function: come in after a battle and shoot the survivors.
Step 20: Promote the Uninvolved. Actually not a bad idea; if the person was smart enough to stay away from the project, they might do a better job next time.
And since this is an “unstructured” project, the last step is of course...
Step 21: Go to Step 1.
No comments:
Post a Comment