TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Ten Ways to Guarantee Project Failure



A StickyMinds.com Original
Article Picture
Ten Ways to Guarantee Project Failure

By Naomi Karten

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: Naomi Karten specializes in helping companies succeed in their projects. In this week's column, however, she gives tongue-in-cheek advice on how to make a project fail. Read on to see if these steps to failure are part of your organization's modus operandi.


Infosys
Imagine that you’ve been put in charge of a mighty important project. Imagine further that you’re allergic to success and will do anything to avoid it. What can you do to ensure that the project doesn’t just fail, but (just to be safe) fails miserably? Here are ten suggestions: 
 
1. Abbreviate the planning process.  
Planning is boring. It takes too long, and diverts attention from doing real work. Besides, there’s nothing to show for it, so name the project, sketch some squiggles on a scratch pad, and get going. There’s no need to strategize every little detail. Everything will fall into place in its own time. 
 
2. Don’t ask “what if?”  
What if we have staff turnover during the project? What if some anticipated business changes actually come to pass? What if the other groups on our critical path perceive priorities differently from the way we do? Hypothetical possibilities are great for hypothetical projects, but this project is real. Just focus on the here and now, and you’ll be fine. 
 
3. Minimize customer involvement.  
Customers just slow things down. Anyway, they don’t know what they want, so why bother asking them? Do your best to avoid customer input, and don’t waste time with customers clarifying project direction, scope, and expectations. You can’t afford such trivial pursuits when you’ve got a deadline to meet. 
 
4. Select team members by the “hey, you” method.  
It doesn’t really matter who is on the project team. If the people you initially assign prove too slow, you can always add more. Don't worry about the learning curve; they can teach each other. If progress is still too slow, reorganize the team and watch energy levels soar.  
 
5. Work people long and hard.  
People who work a normal workweek aren’t invested in the project. Anyway, people who work weekends get out of mowing the lawn, chauffeuring the kids, and entertaining the in-laws. There’s something wrong with a deadline if people can meet it without any overtime. 
 
6. Don’t inform management of problems.  
Managers have better things to do than be concerned with what and how you’re doing. If you’re going to bother them with a problem, wait till it’s a real doozy. Then spring it on them. Don’t worry, they can handle it. After all, that’s what management is paid for. 
 
7. Allow changes at any point.  
The more changes, the better. Accepting all requests for changes keeps things lively and avoids the monotony of a static project. Maintain a you-want-it-you-got-it philosophy. It does wonders for customer morale and keeps project personnel on their toes. And don’t bother documenting these changes. They’ll all be part of one big end result, so why bother? 
 
8. Discourage questions from team members.  
They don’t have to understand what they’re doing; that’s your concern. And they certainly don’t need to understand what anyone else is doing. Above all, don’t explain the instructions and directions you give them. Their job is to do, not to think. You’re not a seasoned project manager until you can glibly tell people what to do without telling them why. 
 
9. Don’t give customers progress reports.  
If they ask, just tell them the project is proceeding smoothly. Explain patiently that status reports are counterproductive; you could be using the time to work on the project. Tell them anything; just get them off your back. This is the trust-me approach to project management. Customers will appreciate the confidence you exhibit. 
 
10. Don’t compare project progress with project estimates.  
That way, you won’t have to deal with the discovery that the project is slipping. Anyway, the sooner you fall behind, the more time you have to catch up. But you already knew that. 
 
Failure guaranteed or . . .  
As a rule of thumb, remember that if you pay attention to the needs of the project, the team, and your customers, you run the risk of succeeding. Heed the above, and failure is yours. Guaranteed!


About the Author
Naomi Karten (naomi@nkarten.com) has delivered seminars and presentations to more than 100,000 people internationally to help them improve their service strategies and client relations. In 2002 her presentation, “Managing Customer Expectations,” earned the Best Presentation award at SQE’s SM/ASM Conference. She is the author of several books, including Communication Gaps and How to Close Them and Managing Expectations: Working with People Who Want More, Better, Faster, Sooner, NOW! Her handbook, How to Establish Service Level Agreements, is in use worldwide. The above article originally appeared in her newsletter, “Perceptions & Realities.” Numerous issues of this newsletter are posted on her Web site, http://www.nkarten.com.

Back to Top
 

StickyMinds.com Weekly Column From 4/7/03 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by jaideep khanduja 5/20/2008

Naomi – That is an excellent and satirical way of running a project in a purely Non-methodical and Hypocritical manner. And this is what most of the mediocre and unprofessional companies do. Least Documentation, staggered islands of team members, lack of trust and respect, unorganized way of working, no accountability and questionability, frustration, no combined involvement, directionless progress (or digress), never ending game are some of the features hidden in your points above which I could instantly recollect.//regds//jaideep

 
 
Comment:    
by Gary Whelan 6/2/2004

While point #1 is relevant to our projects at work . We also have a 'Abbreviate the Testing Process" in the form of Customer Qulaity reviews. Eg Last year our area dropped UAT from its Test Plan . Then an area was established to "talk to the business" and "talk to testing". They now want to see the screens during the testing process. This is made by setting up a 'walkthrough" during testing and inviting these folks (up to 20 people) to show them how it works (remember testing is still in progress) Some of the greatest pieces of change 1. Buttons that are changing colour 2. 1 Field that requires a different input. 3. Processing stuff...Read On

 
 
Comment:    
by David Hooper 6/2/2004

Rule 13 - Don't expect perfection; demand it while always claiming "I could do a better job!" (If unsure how to do this with a straight face, see John Kerry.)

 
 
Comment:    
by Kim Quigley 6/2/2004

#11 - Why bother testing? The users can find all the errors after a project is released. #12 - Don't waste time evaluating projects after they fail. Just call them a success and move onto the next one as quickly as possible. (If you're not sure how to make a project or mission successful simply by saying it is so, follow President Bush's lead.)

 
 
Comment:    
by Jeremy Wadley 3/17/2004

I think I can safely say that I've seen the whole list from just two project - and guess what, they failed! There are a couple of items I could add: 1. Totally demoralise your team (preferably shout at them about how useless they are because they are behind schedule). 2. Expect them to know a foriegn, out of date language without any training. 3. Announce that the whole office is being made redundant, but that we must still meet the project deadlines. 4. In planning, cut all project estimates by atleast 40%. While this is all tongue and cheek, but unfortunately common place, many of the items are exactly the ploy of the RAD and Agile...Read On

 
 
Comment:    
by Bug Detector 1/29/2004

Great list. I believe that my employer has mastered all 10. We have even managed to master about half of Daniel and Noelle Ferry's larger list published in their book "77 Sure-Fire Ways to Kill a Software Project". I believe that upper managment does not know just how good we are at failure because we never admit failure. Those in middle management never admit failure because they are too afraid to tell the truth. (After years of searching, I still haven't found the source of this fear.) I often read reports from upper management stating the success of projects in which only a small fraction of the original goals were accomplished.Read On

 
 
Comment:    
by Giovanni Carlo Liuzza 8/6/2003

It is a particular intuition to write about something that It have not to be done. But N. Karten writes about 10 ways to guarantee Project Failure. So many people know what it has to be made to guarentee successes, to lead successfully a project. Today so many people teach in Internet how to have success in their life too. We know 100.000 rules to guarantee Projects success, and Ten Way to Guarantee Project Failure. Someone thinks, here too, that they could be more than ten. I think that perhaps they could be less too. Just one it is enough, and then it is not enough some thousand to have success. We have almost everybody a good Skill.

 
 
Comment:    
by JAGANADHA KARRA 7/24/2003

What Naomi says seems to be realistic, based on my 14 yrs of exposure in this industry. I had come across some managers, who just want to start coding for a moderate project with just one-page requirements...Some Managers avoid the developers, who keep asking the "why or what if " questions...because they think that this developer might slow the project speed.I worked under some team members who were selected based on their seniority & not on their technical skills. I used to wonder what will be their role & responsibility. Well, if everything in real-life goes what we read in books....then our careers won't be this much challenging...

 
 
Comment:    
by Ranjith GR 5/18/2003

One more simple method that helps to bring down your work load also. :-) Delegation to the least qualified people. This has proven very effective. An example is delegating the task of preparing the Project Plan to a resource who has just been into IT for 3 or 4 months. Another advantage is that they will not come back with many doubts as they feel it will make them look stupid in front of their manager.

 
 
Comment:    
by Carol Kohn 4/29/2003

Excellent! - I'll add one more. Don't let your team member talk to each other about the project. They are too busy and don't have time. Yes - that actually happened to me. I was asked to document a number of processes during the install of Peoplesoft. The project manager told me flat out that I can't bother the programmers, even though it was their processes I was attempting to record. In the end I pasted together a very large document packed with nonsence. The project manager was thrilled. I don't believe he ever actually read it.

 
 
Comment:    
by Deepak Daniel 4/20/2003

That was cool stuff... Though we went in a systamatic way and we didnt give any room for the the above points....due to contineioous requirement change by the customer and evey one in the organization acting as if they are driving the project and finally for our dismay due to too many requirements means to say too many requirements our product failed and 1.5 years of hard work has gone for a toss...

 
 
Comment:    
by Robert Todd 4/10/2003

Just in case these ten steps aren't sufficient to drive a project off a cliff, let me suggest a two more steps: 1) Fundamental technical decisions (e.g. selection of an embedded OS) should be left to people without any technical background 2) Developers should work in cramped and noisy cubicles while clerks and admin help work in private offices... there's nothing like constant speakerphone noises, keyboard banging, and the non-stop drone of a co-worker who talks to him/herself all day to send frustration sky-high and productivity into the dirt. Hope this helps.

Author's Response:
4/11/2003    
From my past life as a techie, I can appreciate the frustration of having important technical decisions made by people who know nothing (read: NOTHING) about the technical issues. As I’ve observed since then, there’s often a political agenda (such as management wanting to reward a favored vendor with the business), and they don’t want to let the decision-making be contaminated by the facts. As to crummy work environments, you said it all. All the rest of the measures taken to improve project productivity become irrelevant when people are being driven to distraction by their surroundings. I think even the kids who can do their homework to the sounds of cacophonous, ear-jarring music would be driven bonkers by the noisy situation you described. Or maybe they’d thrive. I wonder….

 
 
Comment:    
by Gene Fellner 4/9/2003

Re: No. 5. (Work team members long and hard.) There actually is a very tiny proportion of the human population that has the ability to work long hours endlessly, with no dropoff in speed or accuracy or any other ill effects. And every manager believes that all of those people will be assigned to his project.

Author's Response:
4/9/2003    
Or that they’re already assigned to his project, and can therefore be worked to the proverbial bone. Do any of you out there fit Gene’s description of that tiny proportion of endlessly energetic, consistently speedy, unstoppably accurate workers? We can compile a list for projects that are in need……

 
 
Comment:    
by neill mccarthy 4/9/2003

One of the best I have seen is slightly at odds with point one, we never finished planning. We micro-managed to the point of paralysis, then spent our lives reviewing the plans, replanning the plans and reforecasting plans. All to the sound of milestones and deadlines whooshing past. The second was even better then not letting the team ask questions, it was not letting the team do their job. The project was lead by a very experienced manager who had saved many death marches(Edward Yourdan has an excellent book on these), who basically ensured everything had to go through them. No one was ever good enough and the work would always land...Read On

Author's Response:
4/9/2003    
Your experience is not just at odds with my point #1; it totally trumps that point, because if you spend forever planning and replanning and re-replanning, your project will successfully fail without having to contend with any of my other nine points. And what a time saver! If you never actually proceed with the project, you don’t have waste time discouraging questions from team members or dealing with change requests or comparing project progress with estimates. You can focus your full attention on (re)(re)(re)planning. I love your description of the milestones and deadlines whooshing past. This sounds like the perfect auditory signal of a project in trouble: listen for the sound of whooshing!

 
 
Comment:    
by Toby Mills 4/9/2003

Wow, this is an accurate description of a typical project within EDS.

Author's Response:
4/9/2003    
Wow is right! I’ve seen examples of all 10 points in various projects across a multitude of companies, but it’s reassuring to know there’s at least one company that excels at all ten. Though I’m not sure that "reassuring" is exactly the right word. If you’d ever like to be a case study, I’m sure there are lots of people who’d like to interview you. Sorta like those newspaper ads that seek volunteers for medical research studies: If you’re between the ages of 21 and 65, and your company’s typical projects successfully abbreviate the planning process, minimize customer involvement, discourage questions from team members (etc. etc .etc), call now, 800-….. :-)

 
 
Comment:    
by Brad Appleton 4/8/2003

I agree that "Allowing changes at any point" can help "seal your fate". It's just that for all the other ones, if you basically negate them - they become valid statements of what you MUST do in order to succeed. But if we negate "Allow changes at any point" - this no longer true because "Don't allow changes at any point" can VERY easily be MISREAD to mean "dont allow any changes" - which Ive all too often seen be yet another way to guarantee failure (you may deleiver on time but it doesnt meet their needs because needs/expectations do genuinely change). I too often see an overly controlling tendency to try and prevent change as opposed to...Read On

Author's Response:
4/9/2003    
Your comment made me smile because your observation about the result of negating my points is the sort of thing I notice in reading other people’s articles, but I missed it altogether in my own. So thank you! I agree with you. Both extremes -- accepting all changes and refusing all changes – are, well, extreme. Like you, I’ve seen excessive attempts to control projects by (among other things) refusing to consider any changes at all. It seems to me that it’s not reasonable to expect customers to always be able to specify everything clearly and completely right up front. Customers (including ourselves when we’re the customer) learn things, gain insight, and just plain know more about what they want as the project evolves and they become more aware of the possibilities. Of course, changes should not be requested frivolously or on a whim. But as you pointed out, the key shouldn’t be whether changes will be made, but when and how, with appropriate consideration to the risks and impact. The "when" may at times prove to be "never," but in most cases, that shouldn’t arbitrarily be a given at the outset.

 
 
Comment:    
by Arthur Royce 4/8/2003

You forgot another one. Go to each member of the team and make up stories about what other people are saying about them. Be sure to throw in made-up gossip about race, gender, national origin and religion. This is actually for real. We never figured out the motivation for this, but did figure out that the project manager was trying to incite in-fighting and most of us got deparmental transfers or quit. We also held our own internal meetings to combat this behavior. Pennsylvania is a "work at will" State so basically anything goes. Management has no liability for their behavior. The bottom line? The project went 100% over budget...Read On

Author's Response:
4/9/2003    
What a sad situation! You have to wonder what kind of distorted thinking was behind this guy’s abusive behavior. Even if the project had somehow managed to come in on time and within budget, there’s no excuse for treating people that way. In writing this article, my aim was to focus on familiar flaws in project management practices rather than basic human interaction, but clearly there's a need for an item on how people treat each other. Thanks for sharing your experience. I’m sure that it was a lot worse living through it than you can capture in a single paragraph.

 
 
Comment:    
by Marc Duerr 4/8/2003

This was a fun thing to read. The only thing I'm afraid of comes from the does and don'ts in teaching: Never write something wrong on the board, because our minds we will remember only that it was written there in this context, but not, that this is wrong.

Author's Response:
4/9/2003    
Mmmm, now that you mention it, I’ve heard similar advice myself, though I had conveniently forgotten it till I read your comment. Of course, I’d like to believe that this article will be an exception and that readers will remember the intended points rather than the points as literally stated. But if we see a sudden increase in team members being selected by the "hey you" method, it’ll probably be my fault! :-)

 
 
Comment:    
by yogita sahoo 4/8/2003

May I add one too :-) Communication within team. Forget regular communication inside team even for a week and see the dramatic side effect it shows on the project. It’s important that nothing be a secret within the team, be it change request, schedule changes, client bugs or existing risks. And when we talk about team, it should be developers, testers, technical writers, customer support and everybody else related to the project….. thank you for this excellent article

Author's Response:
4/9/2003    
Thank you for your thank you!! You are right about the importance not just of communication but of regular communication. And I especially like your point that the team encompasses everyone connected with the project. If I had to rank order my ten points, plus all those being contributed by readers, I’d put this one in the top 3. Maybe even at the very top!

 
 
Comment:    
by Ben Goh 4/8/2003

Tired workers make mistakes.

Author's Response:
4/9/2003    
How true this is. I think it would make a great poster to hang in every manager’s office. Fatigue and foggy thinking don’t do much for project success.

 
 
Comment:    
by Daniel SUCIU 4/7/2003

I have some improvements, too: - at no.2 : Don’t ask “what if?” and don’t allow others to ask. - at no.4: Select team members by the “hey, you” method. Also considering no. 5 you don’t have to think how many resources you’ll need, neither schedule conflicts with other projects/tasks. Don’t think they need training for any aspect of the projects, even if this imply new technologies, methodologies,… - no 9 and 10 should be deleted. These imply that you should keep progress reports, and more than that, to have estimate to compare the progress against. Who cares about estimates and progress reports. These are for beginners. A good project...Read On

Author's Response:
4/8/2003    
Daniel, well said! I especially like your point about not offering training. That will help team members be unprepared to do their job so that they do their fair share in helping the project to fail!

 
 
Comment:    
by Frank Patrick 4/7/2003

I'm sure you'll be innundated with additional ways to guarantee project failure, so let me be the first.... 11. If you do bother to plan your project, plan it and promise it as if it were the only thing going on in the organization. Don't let the possible need of resources by other efforts or other business objectives sway you from your narrow focus on your focus, and be prepared to hoard resources, using experienced, skilled people for grunt work so that other projects can't get their grimy paws on them. (More about project failure and multi-project impacts here.

Author's Response:
4/8/2003    
Hi there, Frank. Thanks for your eagerness to contribute to the list. Your comments reminded me of another item for the list, one based on several projects I’ve seen: "Treat every project as top priority." When this "rule" is followed in conjunction with your grimy-paws resource-hoarding strategy, a multitude of projects can all fail at the same time.

 
 
Comment:    
by Robert M Melendez 4/7/2003

Thanks loads, Naomi. I've recorded these bulletpoints in my PDA where I can safely ignore them. I'd let you know how my project was doing, but I'm too busy getting it to fail. (And I hope my manager doesn't notice I'm reading a professional site. He might think I was after his job.) ROTFL!

Author's Response:
4/8/2003    
Hi Robert. Well, I’m sorry I'll never get to know how your project is going, but I’m glad you appreciate that making a project fail is an all-consuming task, especially if you’re conscientious about it. Anyone can make a project fail through sheer luck. Only the savvy know how to do it by design!

 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


ThoughtWorks




STAREAST 


Better Software Conference