Site News for 8/13/07 through 8/18/07Exploring the System.IO.Path Namespace - Part II

10 Ways To Insure Project Failure

August 19th, 2007

Captain Bligh - A great navigator but a bad project managerIf you want your next software development project to fail, and not just a small way but in big, spectacular, way, here are some sure fire steps for you to follow:

1. Set Unrealistic Goals

Your management says the project has to be done in 2 months. You know it can’t be done in any less than 6 and it’s probably more like 9 months. But, hey, they want it in 2 and you’re in no position to challenge them so why not just go ahead and agree to it. Your team won’t mind. After all, if they agree to work 80 hours a week they should be able to pull it off. Besides, you’ve just gotten the purchase of a brand new code generation tool approved. This will save loads of time in the project.

2. Staff Up Quickly

You need people on your team ASAP. Hire the first warm bodies your pal at Programmers-R-Us sends over for an interview. Your project has a tight schedule so you need somebody, anybody, on-board and ready to code. Don’t bother with having your team participate in the interview process or be too picky. If you do, you might lose the good candidates to other companies.

3. The More Documentation The Better

Require your team to document everything. You need a scribe to take down the minutes of each and every meeting and publish them afterwards. Every form must be filled out according to a mandated template taken from an antiquated mainframe methodology you learned in school or a NASA software development handbook you bought on eBay. Insist developers write out weekly, or even daily, status reports. You can never have too much data about a project. Ignore the whiners on your team who complain about being overloaded with useless work. They just don’t understand the benefits of good documentation.

4. You Can Always Make Up a Schedule Slip Later in the Project

If your project is falling behind it is always safe to assume that you can make up the difference later. People were just goofing off or getting into the project at first. Everybody knows that as the project progresses everyone gets more comfortable and productive. Just like in a distance race, everyone stores up enough energy for a big sprint at the end. Count on having a strong finish for your project.

5. Relax Your Standards To Shorten the Schedule

OK, so it looks like the document everything plan is not going to work out so well. The obvious answer is to do the opposite, scrap all documentation including any end user instructions or help files. That extra work can be done after the project is completed. Also, cut out fluff like integration and user testing, well managed source control and test systems and your other standard coding processes and procedures that just get in the way. Quality isn’t important, only completing the project on time is important.

6. Micromanage

If left to their own devices team members will goof off. It is your job to stay on them 24/7. If traffic is bad one morning, make a point of calling late team members on their cell phone every 2 minutes to gauge the progress of their commute. Who knows, they actually may be lounging at Starbucks rather than sitting in their car behind a jackknifed semi. Call them in the evening at home as well, particularly if they have the audacity to leave early, to discuss fine points of the project for 30 minutes or so. Use time management software to track each developer’s time in and out of the office and exactly what they’re working on throughout the day. Also, you should swing by every team member’s cubical 2 or more times a day to ask them about their progress. Feel free to offer your sage suggestions about whatever they’re working on. This lets them know how much you care.

7. Call a Daily Project Status Meetings

You should have at least one daily meeting to take the pulse of the project. This is best scheduled either first thing in the morning or very late in the afternoon. This helps insure everyone is arriving on time and not leaving early. Better yet, schedule a meeting for both times for a win-win situation. Every point of the schedule and the day’s work should be discussed in detail during these meetings. You have the room and the team’s attention for a full hour so why not use it to the fullest?

8. Threaten Team Members to Motivate Them

If your team is falling behind the problem is that you aren’t motivating them enough. You’re allowing them to goof off and fall behind! Put your project back on track by putting their feet to the fire. Let them know that if they don’t dedicate themselves wholly to the project they’ll be finding a new job. Question their competence as programmers and mention how anyone who doesn’t perform up to standards will be fired so as to spur them on to greater acheivement. You will be amazed at how motivated your team is after you take this approach.

9. Bring In More Programmers

That Brooks guy’s ideas might have applied way back in 70’s at IBM but they don’t apply in modern, Web 2.0, times. Screw the ‘Mythical Man Month’. Bringing in more programmers means more people coding and thus more getting done faster, simple as that. You could even have them work shifts using the same computers to save office space and equipment costs. You can easily find or invent a buzz word to describe what you’re doing to sell it to the team and your management. What a brilliant coup that would be!

10. Set Your Plan in Stone

Never, ever, back down on your vision of the project schedule or plan. You said 2 months with the new tool and you meant it. You know you have awesome estimation and project management skills. Don’t entertain any complaints about your choices in meetings. Anyone questioning your decision is being insubordinate and disrespectful and probably just looking for a way to slack off. How dare they question your competence and authority?

Special Bonus Idea

If you need good political cover for implementing these steps toward failure you need to tie them to a popular development and project management buzzword like Scrum, Agile, or Extreme Programming. All of these methods offer excellent cover to you both during and after the project. This shows your managers that you’re on top of the latest software development project management trends while your team are a bunch of disloyal whiners who can’t stand to have their cheese moved. Furthermore, when the project fails you will be recognized as a company expert of the method since you know what doesn’t work. Does it matter that you just ‘cargo culted’ these methods? No, not at all. You’re well on your way to being the next ‘pointy haired boss’ or Bill Lumbergh.

Share This Article: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • del.icio.us
  • Reddit
  • StumbleUpon
  • Technorati
  • DotNetKicks
  • DZone

Entry Filed under: Development Teams, Project Management


Rate This Article:

Not That GoodCould Be BetterOKGoodGreat (7 votes, average: 4.43 out of 5)
Loading ... Loading ...

6 Comments Add your own

  • 1. mcwong  |  September 8th, 2007 at 11:27 am

    The article was a good read until the very end. It’s funny that you indict the agile methodologies, when they’re built to tackle a good number of the issues you highlight. I’m most familiar with Scrum…, so I’ll answer those particulars.

    Set unrealistic goals? Nope, get the goals from the team on a frequent basis. Management’s job is to manage the feasibility of those goals with the stakeholders.

    The more documentation the better? Nope… working code over specs.

    Making up schedule slips later? Nope… be constantly aware of where the project is, and manage reality.

    Relax standards? Nope… have a firm definition of what done means, and hold people to that definition (coded, tested, documented, demonstrable)

    Micromanage? Nope… delegate as much as possible to the team.

    Daily status? Sure, this happens. For 15 minutes.

    Bring in more programmers? Nope… teams are frozen for sprints. Granted you can alter structure in between, but (at least in our case) this happens infrequently

    Set your plan in stone? Nope… review the plan frequently with stakeholders and manage to reality.

  • 2. jfrankcarr  |  September 8th, 2007 at 12:53 pm

    Thanks for your comment.

    I was mainly noting how bad managers will seek to use the latest buzzwords to provide political cover for their mistakes. They might latch on to Agile and Scrum today while 10-20 years ago they might have been misusing classic SDLC methods.

    If I have one skepticism about Scrum it would be the daily status meeting part of it. I’ve seen status meetings so abused over the years that I’m wary of them being a key part of a methodology. How has that part of it worked out for you?

  • 3. mcwong  |  September 9th, 2007 at 12:35 am

    The clarification on blindly applying methodologies for political cover helps. That is definitely dangerous.

    The daily status meetings have to be carefully defended. We’ve barred specific people from our daily meetings on occasion. We’re fairly vigilant about breaking teams into smaller units when they get too big. The team is actually pretty vocal when they start getting too long and/or abused.

    I agree that’s a (the?) controversial part, but the general consensus we have is that they’re extremely useful when used properly. I think the biggest beneficiaries are doc and test folks… the developers sometimes overlook the (huge) benefit they get out of it, but appreciate it when they aren’t slammed with providing doc content or re-explaining the approach to a tester at the end of the project.

  • 4. 【翻译】确保项目&hellip  |  September 12th, 2007 at 2:52 am

    [...] 原文:http://vbnotebookfor.net/2007/08/19/10-ways-to-insure-project-failure/ If you want your next software development project to fail, and not just a small way but in big, spectacular, way, here are some sure fire steps for you to follow: [...]

  • 5. First you Scrum down, the&hellip  |  October 28th, 2007 at 1:27 am

    [...] his article, 10 Ways to Ensure Project Failure, J. Frank Carr addressed pains that my team once coped with routinely—pains Scrum eventually [...]

  • 6. Tom  |  January 11th, 2008 at 5:59 pm

    Daily scrums are not status meetings, they are short planning meetings as a gut check for the team. Anyone using Scrum properly will acknowledge and support that contention.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed


Visit Me At My New Site, Programming In C#

Most Popular Articles

Highest Rated Articles

Categories

Most Recent Articles

Feeds

 Subscribe in a reader

To subscribe by e-mail
Enter your address here

Delivered by FeedBurner

VB Opportunities

Archives