# # Setting Project Exit Criteria
APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Setting Project Exit Criteria

By Kevin M. Berry

I've removed advertising from most of this site and will eventually clean up the few pages where it remains.

While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.

If you found something useful today, please consider a small donation.



Some material is very old and may be incorrect today

© July 2005 Kevin M. Berry

Ever notice how easy it is to get INTO a project, and how hard it is to get OUT of one? There's an old saying about project timelines - "The first 90% of the project takes 90% of the time, and the last 10% of the project takes the other 90% of the time."

So, how do we drive a project to closure? The answer to that lies in setting the exit criteria first, as a part of gathering the requirements and understanding the priorities. Usually, we don't start identifying these criteria until we are in the closure cycle, and, of course, the customer ALWAYS has extras they want done.

Have you ever had a day like this one? The boss calls you into her/his office, and starts with an apology "...I'm sorry to give you this assignment, but ..." and holds out the requirements document, using gloves and tongs. You, of course, being a quick thinker (with lots of scars) respond with Plan A. "Well, you know, I'm pretty whacked with work right now, but I noticed Dave in my cubicle was reading a novel this afternoon, and he looks like he's got some slack time." Dirty, but hey, we've all done it, right?

So,failing that attempt, you move on to Plan B, which goes like this: "OK, boss, I guess I can do it. But, could you tell me, what is the absolute minimum I have to do to get this steaming heap of post- digested-bovine-feed off my plate?" This, Grasshopper, is the key to completing projects. Drive out the minimum acceptable product, on the shortest reasonable timeline, using the least possible resources.

Think about this for a minute. It would be nice if we all got the opportunity to bid on exciting, groundbreaking projects that we could camp on for a long time, feeling fulfilled at every step. However, in the real world, there are many tasks that Just Have To Get Done. Our natural inclination is to bury these stinkers deep in our "In" baskets, work them as little as possible, and drag out the hardest parts as long as possible. This very human tendancy clogs our souls, ticks off our boss, and drags overall efficience down like a lead balloon.

Ah, but I can hear Dan Akroyd saying "Rosanne, you ignorant *redacted*. Don't you know that if you get a reputation for doing putrid projects quickly, you'll just become the Superfund site for the office?" (Apologies to those of you who aren't vintage SNL fans.) Well, lets analyze that for a minute. When the Glorious Earth Mother Of All Projects comes along needing a PM, which position would you rather be in, approaching the boss. Slug #44, who has dogged everything the boss has given them, or Hero #1, who's taken it in the shorts for the department time after time?

None of the above mitigates the need to get the customer's REAL requirements, do a crisp project plan, and take the time to produce quality work. Actually, driving a conversation on exit criteria quickly defines the deliverables, and sets up a true understanding with the boss/customer on what they really want. Delivering the right product, on time and on spec, has got to be a good thing (even if you do have to get your hands smelly). So buy some Lava soap, take a firm grasp on that stinker, and earn your way to hero-hood!


If you found something useful today, please consider a small donation.



Got something to add? Send me email.





(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

->
-> Setting Project Exit Criteria

4 comments


Inexpensive and informative Apple related e-books:

Sierra: A Take Control Crash Course

Take Control of iCloud, Fifth Edition

Photos for Mac: A Take Control Crash Course

Take Control of Upgrading to El Capitan

El Capitan: A Take Control Crash Course





More Articles by © Kevin M. Berry







Fri Jul 22 02:33:46 2005: 846   anonymous


Great Article!

The "never-ending project" is a big problem for all of us developers. I've found that if you define the beginning and end up front, you're more likely to be able to finish happily.

BTW, wasn't it "Jane you ignorant..."??? :)



Fri Jul 22 16:01:59 2005: 851   Kevin


GAAAAHHHHH .... My middle age is showing! I can't even remember my favorite SNL skits anymore! Thanks for the feedback, and also pointing out my, uh, what was I talking about? Oh yeah, faulty memory. :-) Yes, for the record, it IS "Jane" not "Rosanne".



Wed Sep 6 14:07:50 2006: 2443   RichP


When stuff piles up in your Inbox, you can take relief by watching the Sand Dune Effect. Over time, or due to sudden unexpected storm, the dune can drift and change shape, sometimes disappearing completely. In the context of your post, you might see this spill into the next cube, or be forgotten by Boss.



Mon Jun 8 20:49:56 2009: 6474   CMangos

gravatar
Closing out the requirements is the hardest thing to do! In comes the clean up committee that no one whats to see! I love the way Kevin wrote this article! He hit the nail on the head!!

------------------------


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us


Printer Friendly Version





The danger of computers becoming like humans is not as great as the danger of humans becoming like computers. (Konrad Zuse)




Linux posts

Troubleshooting posts


This post tagged:

Business

Programming



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode