*
The moose likes Agile and Other Processes and the fly likes how to make sure project doesn't fail Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "how to make sure project doesn Watch "how to make sure project doesn New topic
Author

how to make sure project doesn't fail

Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30136
    
150

Jenny & Andrew list 5 ways "to make sure your project doesn't fail" :
1) Tell the truth all the time [transparency]
2) Trust your team [don't micromanage]
3) Review everything, test everything
4) Check your ego at the door
5) The fastest way through the project is the right way through the project

List quoted from page 20 of October 20 NY SPIN presentation. Comments in brackets are mine from the author's description at the sig.

Unfortunately this was near the end of the presentation and I can barely read my notes. Does #5 mean that the fastest way is to not cut corners and sacrifice things in hope of making a date?


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Jeanne Boyarsky:
5) The fastest way through the project is the right way through the project
[...] Does #5 mean that the fastest way is to not cut corners and sacrifice things in hope of making a date?

My interpretation would be that they're referring to not gold-plating the software by building fancy architectures where they're not truly needed. Am I close?


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Paul Michael
Ranch Hand

Joined: Jul 02, 2001
Posts: 697
Hi Jeanne,

I initially thought point 5 meant, "finish the project as fast as you can and you will succeed."

Thanks for the clarification.


SCJP 1.2 (89%), SCWCD 1.3 (94%), IBM 486 (90%), SCJA Beta (96%), SCEA (91% / 77%), SCEA 5 P1 (77%), SCBCD 5 (85%)
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30136
    
150

Paul,
I didn't clarify anything. Now we have three different opinions! Any more interpretations?
Jonathan Viray
Greenhorn

Joined: Apr 10, 2005
Posts: 5
5) The fastest way through the project is the right way through the project


IMHO, right way means good implementation to the project from the very start.
B Davis
Greenhorn

Joined: Dec 04, 2007
Posts: 12
In A Guide to the Project Management Body of Knowledge (PMBOK Guide), the definition of Critical Path is, "The longest path through the project, showing the shortest time in which the project can be completed with no slack or float".

This may be what #5 refers to. The Critical Path is said to be the right way through the project, as it is the fastest way you can do it taking into account all the activities and their relationships to each other.

B. Davis
[ December 04, 2007: Message edited by: B Davis ]
jennifer greene
author
Greenhorn

Joined: Dec 03, 2007
Posts: 5
Originally posted by B Davis:
In A Guide to the Project Management Body of Knowledge (PMBOK Guide), the definition of Critical Path is, "The longest path through the project, showing the shortest time in which the project can be completed with no slack or float".

This may be what #5 refers to. The Critical Path is said to be the right way through the project, as it is the fastest way you can do it taking into account all the activities and their relationships to each other.

B. Davis


Actually, we weren't talking about the critical path when we wrote that line. We were reacting to a common phenomenon in software development projects where people start cutting out every task that doesn't directly produce code in order to cut time off of a late schedule. Usually, doing that actually makes the project later. It means cutting out important stuff like quality activities, reviews, testing and other work that actually costs less time to do up front than it does in the end.

Say it takes you and your team 2 or 3 hours to go through a particularly risky chunk of code and during it, you find two or three bugs that would've taken 6 or 7 hours track down if they'd been found by the QA team (or worse, your customers). The time it took you to do the review actually saved you time on the project. That's what we mean when we say the fastest way is the right way. It's the same thing Phillip Crosby was saying when he said Quality is Free. Andrew actually wrote a good post about it on our blog a while back: Quality Really Is Free.

Another way to say it might be, "You're not saving any time by slashing reviews and testing from your schedule."

Hope this helps,
Jenny Greene
Author, Head First PMP and Head First C#
Building Better Software
[ December 04, 2007: Message edited by: jennifer greene ]
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30136
    
150

Jenny,
Thanks for the "official opinion. It was interesting reading all the different interpretations. And now I can amend my notes with what was intended.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I thought it just meant if you do it wrong, it will take longer. Or if it took too long, there is a way to make it more "right".


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: how to make sure project doesn't fail
 
Similar Threads
How to design/architect for a specified performance
lock & unlock
Where to start for SCEA Part II
Prototype and script.aculo.us ToC
Lead Oracle J2EE Engineer, Northborough, MA, 7/20/2007