Feasibility Studies a Waste of Time?

Hi Everyone,

In his recent article "The Elements of a Good Feasibility Study" Tim
Bryce says, "I have read where some people in the IT field, such as
the "Agile" methodology proponents, consider Feasibility Studies to be
a colossal waste of time" and I wondered whether this is true?

Anyone care to comment?

Duncan

This is the article in question:
http://www.projectsmart.co.uk/eleme...lity-study.html

Duncan wrote:

> In his recent article "The Elements of a Good Feasibility Study" Tim
> Bryce says, "I have read where some people in the IT field, such as
> the "Agile" methodology proponents, consider Feasibility Studies to be
> a colossal waste of time" and I wondered whether this is true?

I want a feasibility study to answer these questions:

- do we have the right people to start?

- do we know how to run the tools?

- do we know enough to specify the high-value features?

- how soon can we put something into production?

In other words, we need to run the project's first iteration. That's just
Agile in practice. Each iteration of an Agile project answers those
questions.

Without answering those things, a "feasibility study" is an attempt to
predict whether a project is feasible, _without_ dedicating people, tools,
and specifications to it for a w. If you assume the first iteration must
last several months, then you might think you need to guess at feasibility
without actually launching the project.

The first iteration of an Agile project should cost less than a feasibility
study, and should return higher quality data. If the data say the project is
not feasible, cancel.

--
Phlip
http://assertxpath.rubyforge.org/

> The first iteration of an Agile project should cost less than a feasibility
> study, and should return higher quality data. If the data say the project 
is
> not feasible, cancel.

Yeah, this is the way it is supposed to work (according to the agile
literature I've read, anyway).  There would probably need to be some
kind of release plan too, and measurement of velocity (might take two
or three iterations), or else it would be hard to make a go/no-go
decision (in the sense of whether the benefits would exceed the
costs).  Depending a bit, I suppose, on how closely one is able to
approach the "deliver business value on day one" ideal.

In practice, I'm not sure whether teams I've been on would have had
the courage (or the organizational flexibility) to cancel after one or
two iterations.

Jim Kingdon wrote:

> Depending a bit, I suppose, on how closely one is able to
> approach the "deliver business value on day one" ideal.

/Worker/: We probably won't be able to deliver something useful
by this Friday.

/Bossoid/: Why not?

/Worker/: You gave us too many requirements; you need to triage
them.

/Bossoid/: They are /all/ important!

/Worker/: While we are here, is there any nice-to-have items we
could work on?

/Bossoid/: The data entry operators keep complaining the query
results page isn't paginated, so they have to keep
scrolling.

/Worker/: Okay. Paginate... the query results.

/Bossoid/: That's not a project! It's just make-work!

/Worker/: Absolutely; that's the point!

--
Phlip