 |
 |
 |
 |
|
 |
 |
Transcription by PWOP Productions, http://www.pwop.com
Page 18 of 18
Pat Hynds on why projects fail
April 16, 2009
enough detail on what they're willing to accept and not
accept that lets a techie or an architect go off and
write a functional and technical specification. Usually
when you torture somebody they can get you to that
point but if they're not technical they don't have the
ability to go to the next level.
Richard Campbell:
Right, to actually get down to
that much detail.
Pat Hynds:
And the next two documents
are really where they probably meet the road and I
usually like to combine them. It's a functional spec
which is like it's a mock up of the UI, used cases, and
could allow a fixed bid project with a lot of
assumptions, and then there's a technical spec which
is the blueprint for the application, there's no
unanswered technical questions, and would actually
allow fix big project. Typically, the functional spec
with the technical spec completed allows you to say
yeah, this would take us X weeks and it would cost
you this much money based on that number of weeks.
That's really the gambit, and occasionally I meet
somebody who actually works regularly on fully spec
projects based on those definitions and I also noticed
that the success ratio on those is much higher.
Richard Campbell:
Yeah, there's dedication in the
specification. Spending time to getting it done right
ends projects sooner when they need to be ended,
but more so immediately it causes the conversation
that sets people's expectations reasonably.
Pat Hynds:
Exactly.
Carl Franklin:
Pat, do you speak about this
topic, Software Project Failure, and do have any white
papers or resources people can pass out?
Pat Hynds:
I just did start a session on this
exact topic and the title of the session that I gave at a
Code Camp in New Hampshire and Code Camp in
Boston last month is How to Prevent Project Failure,
and then I have another session on How to Write
Specifications for Survival and Profit but there was a
little bit too much overlap so I really can't present both
sessions in the same event because there's just too
much overlap in them, but I blog them, I’ve started to
blog again, I blog three times last week and I'm going
to blog this week, I posted the slides up on my blog at
and Hynds is spelled H-Y-N-
D-S.
Carl Franklin:
In hindsight, that should be
pretty good. No, no, I won't start the puns.
Pat Hynds:
That's very “punny.”
Carl Franklin:
It was. Is there anything else
that we missed that you want to cover? We're just
about out of time.
Pat Hynds:
No. I'm just happy to talk to
you guys again. I've been out of the community for
probably over a year now. I'm back. I'm speaking at
user groups and Code Camps and I'm starting to blog
again and trying to actually add to the conversation
and I appreciate the time you guys have taken to
have me on the show and hopefully we can talk about
less dry topics. I think it's an interesting topic but it's a
little bit of a heavy topic.
Carl Franklin:
Well, it's always good talking to
you, Pat, and you always bring a variety of
perspectives on a problem so it's always great...
Pat Hynds:
Thanks.
Carl Franklin:
Thank you again and we'll see
you next time...
Richard Campbell:
On .NET Rocks!
[Music]
Carl Franklin:
.NET Rocks! is recorded and
produced by PWOP Productions, providing
professional audio, audio mastering, video, post
production, and podcasting services, online at
www.pwop.com. .NET Rocks! is a production of
Franklins.NET, training developers to work smarter
and offering custom onsite classes in Microsoft
development technology with expert developers,
online at www.franklins.net. For more .NET Rocks!
episodes and to subscribe to the podcast feeds, go to
our website at www.dotnetrocks.com.
 |