Fog Creek Software
Discussion Board

SDLC - Feasibility

One of the many stages in the systems development life cycle is determining the feasibility of a project.  Is the project feasible technology, budget, time and people wise?  This was pounded into us in the System Development Class at school.  If the project is not feasible don't even attempt to make it.  Having been in the "real world" for quite some time now, I can honestly say that I have never seen a project deemed "unfeasible" and forgoten about.  The fact is that all projects, no matter what the feasibility is, are gone ahead with and an attempt to create them is made even if the end result does not fully satisfy the customers needs.  The quality of these projects is usually very poor and I feel for the customer that pays to have all this code written for nothing.  It would be better off to tell the customer that their particular needs cannot fully be met, but it never happens.

Does anyone reading this forum do feasibility tests anymore?  Is it just taken for granted that everything is feasible?  This really sounds like a "money" thing to me. i.e.  We'll just "make" every project feasible even if it's not 100% correct.  Does anyone follow the SDLC anymore?

If you gots the poison, I gots the remedy
Tuesday, May 27, 2003

before you determine whether something is feasible project-wise, you need to determine if it's feasible ROI-wise.

I don't see this ever being done either.

victim, jr.
Tuesday, May 27, 2003

There's an old saw that no feasibility study ever came back with the answer "no".

What does feasibility mean anyway? Business? Technical? The group qualified to make a judgement in one area is usually not qualifited in the other. Additionally, there are sometimes very good reasons for taking on a project that is economically questionable (for example, a competitor is in that area). And you can still learn something useful from projects deemed technical unfeasible.

I do not believe feasibility is a binary concept. Instead I believe in the old tripod of scope, resources, and time. And even then, rules are made to be broken.

Tuesday, May 27, 2003

I've been on several projects which had ROI calculated before full proceeding.  Additionally, loss against the return per week of schedule slippage must be part of that calculation.

Companies which manufacture products in a factory environment have to run these estimates.  There is too much overhead associated with bringing a new product to market to risk the loss of line time, tooling, training, etc.

But, as we all know, software development time is free - so there is no need for ROI.  :)

As for technical feasibility, rarely is anything not feasible.  There are often better ways of doing something, but rarely will a project fail because you cannot get there from here.  Usually, get a larger hammer approach will save any project - even ones in deep trouble - if the managerial will is in place.

Nat Ersoz
Tuesday, May 27, 2003

Ummm I can't remember any product I've ever been involved with that didn't have a business case made for it.  I can remember a great many ideas for products which seemed reasonable which didn't get anywhere because a decent business case wasn't made.

Feasible doesn't mean possible.

Simon Lucy
Tuesday, May 27, 2003

I wanna work where you guys work.  SOP around the places I've been: 

IS Director:  "man, if we built this new system, we'd {save|make} a lot of money!"

President:  "let's do it!" or, depending on political climate:
"no way in hell!".

victim, jr.
Tuesday, May 27, 2003

I agree.  Too many times it is  "If we tell them it is going to cost "X" dollars, we won't do it."  or "a vendor will."

That said, their is an argument, especially with an internal IT organization that they must compete with any price a vendor supplies.  Vendor X says they can rewrite the system  for only $5 million and you estimated $10 million.  Then Vendor "X" comes in, spends the $4 million and tells us they need $9 more to complete it.  So they approve $9 million more.

As internal you do not have the luxury to say "boy the CIO screwed the pooch on that one..."  In the end, Dilbert wins and you look bad.  Your estimate was high, and rejected even though it was more accurate.

Tuesday, May 27, 2003


Kindly send us your HR department's email address so we can send in our applications there!

I've rarely (read never) seen a feasibility study done either. I've seen cases where technical issues may have been researched before hand and ROI was calculated on the back of a napkin, but never an in-depth study to determine if a project is worthwhile.

Most of the time someone in management makes a decision that this project is worthwhile if done within this timeframe. If someone says it can't be done in that timeframe, then they bring in consultants who are all too eager to accept the job.

Mark Hoffman
Tuesday, May 27, 2003

Why are there so many unfeasible projects and why do so few projects bring in a ROI.

Because you always get the following scenario.

The boss comes along and says he wants something. You give him an estimate of cost and time and show him what the rest of the world is doing.

He says there are constraints. You accept the constraints and work out a plan that can deliver what is asked for provided everything else is in place. You also suggest that they might like to consider a completely different approach as there is really little margin for error.

They then proceed to try and get you to offer more in less time. You hold your ground stalwartly and "win".

Your concession has now become the norm. A little later they start to see its limitations. So they go along and say you have to change the original figures. You tell them it can't be done. You are told "that is the trouble with you programmers; you live a theoretical world, you have to keep in touch with reality, you have to be flexible." You point out that you were as flexible as possible at the very beginning when you did the original estimates and if you try and stretch things any more the rubber band will snap. "Come on," they say, "how much more can it be stretched; do you know the exact figure? A little more here won't matter." And so the new figures are agreed on.

And now the new figures have become the norm. And the same process starts all over again, except this time with a little more urgency because the revised figures are of course creating problems and slowing things down instead of sloving problems and speeding them up.

It is usually soon after this that denial starts to set in, and the idea of completing the project gets replaced with CYA and hoping you can sign off before the problems become apparent.

And then you get total meltdown, when the project is either abandoned totally, or what parts of it are salvageable are salvaged, and then additional effort and funding goes into producing a much more modest result than the original one at three or four times the cost.

Stephen Jones
Tuesday, May 27, 2003

I have to agree with the naysayers (i.e., truthsayers) on this thread. I have worked for companies large and small and it seems to be the norm where the person in charge is the one who deems a project "feasible" or not.

I think feasibility studies (both technical and financial) are incredibly useful. I also agree that technical studies aren't really "technical"--they are just a means to calculate the amount of investment needed (e.g., should we buy the latest development system that only requires 5 engineers for $1M or the old system that requires 8 engineers and costs $200K?). In any case, upper management inevitably seems to ignore what it takes to get the job done (as well as the marketplace) and makes the ultimate decision on whether it feels good and if it will help their career.

As an aside, I believe that the lack of true feasibility studies goes hand in hand with poor project estimating and project management. In other words, not only are you going to set off and build something that cannot be done reasonably well in 12 months, you're only going to get 6.

Tom Fairlie
Tuesday, May 27, 2003

*  Recent Topics

*  Fog Creek Home