How long will the project take ?

[sarettah]

When you fly by the seat of your pants, you either soar like an eagle or you crash and burn. There is usually no in between.

In this day and age, business is done very rapid fire. Clients want their product now at a price they perceive as reasonable and do not understand why you cannot just give them a price and a time frame right this second.

To arrive at the true amount of time that a project really will take requires a fairly thorough analysis of the project. If the designer/analyst has done similar projects in the past, he might be able to give a broad ballpark estimate off the cuff, but usually, any type of accuracy requires an anlysis, a factfinding so to speak.

Unfortunately, we, as analysts/programmers/designers do not have the luxury of telling a client. Ok, give me about 1 week of your time to ask you questions and determine a definition so that I can give you an accurate quote.

Instead we take a quick, high level view of the project and pull a number out of our ass (that number always seems to be "oh, about two weeks")

We hope we get it right or are overestimating. We are usually being very optimistic and underestimating out the ass. It is a very rare ego that thinks it can't pull the project off. It is a very rare programmer that can pull it off.

If you want it real fast, real bad, that's probably how you're gonna get it.



Last edited by sarettah at May 23 2004, 09:15 PM

[venturi]

Amen!

Finally someone gets it. :wnw:

The "Triple Constraint" is something that everyone in this biz should commit to memory:

Build it Fast.
Build it Cheap.
Build it Right.

Pick Two.

[cj]

Colin, thanks for stirring up the pearls :okthumb:

Now they are bloody everywhere!

[Hammer]

Now if we could just get the clients to understand this, things would be peachy.

[Dravyk]

Originally posted by venturi@May 24 2004, 06:26 PM
Build it Fast.
Build it Cheap.
Build it Right.

Pick Two.
That's the truth, Venturi!

Dunno, seems my luck or lot in life to see things from both sides of the fences. If I'm not having folks coming to me (to give to my team) for new programs, then I'm going to my guys and still more folks have them made for myself. All I can say is it's tough on both sides!

Wish someone would come up with a proven formula of some kind to make things more accurate in forecasting, to benefit both the programmer and the client. It seems to be a bit of seat of the pants kind of profession that's hard to do it any other way.

[CuriousToyBoy]

Originally posted by The Hammer@May 25 2004, 10:45 AM
Now if we could just get the clients to understand this.
Bwah ah aha ha ha ha ha

:biglaugh: :agrin: :D

That was tooooooo funny.....

WHAT? SORRY?

Oh, you weren't joking.

:unsure: :( :blink:

[venturi]

Agreed, Dravyk!

It's a slippery slope on both sides. I truly feel that developers want to satisfy their clients' needs as soon as possible, but as a developer I also know that shit happens all the time that gets in the way. Say I sold you a script 2 months ago and while I'm working at a deadline something happens with the script I sold you. What should I do? Supporting my clients is very important, and getting the work out the door is too. It's hard to handle sometimes.

I think, and I'm just free-thinking here, that more people that are looking for custom solutions need to focus on really writing down exactly the business problem they need a solution for and realizing that even if it's a simple thing it may not be a 2hr job. Things happen in development - heck I had a snare put in my widget tonight and it's going to be tomorrow before I can get it fixed.

The other thing is because our clients tend to want everything yesterday, rather than understanding that things, even the simple ones, do take time. Clients need to plan ahead rather than behind.

Don't come to me wanting a full featured paysite backend and expect that in 3 days I can make that happen. I'm just as busy as you, and projects like this take time and consideration to pull off correctly. If you want it done "right now" be prepared to pay a hefty price for something off-the-shelf that you'll still need someone like me to customize to fit your needs and that's going to again take time.

We as developers tend to set unrealistic goals for completion and/or pile on too many projects and get into trouble. It's tough to really balance things. We under bid almost religiously, we run into issues that affect other projects and before we realize it we're backlogged and scrambling to get caught back up.

At the risk of giving away a secret, I think that we all need (developers and clients alike) to get back to the "Scotty Principle". Scotty, from the original StarTrek series, used this principle:

Always tell the captain it's going to take 4 times as long as you know you can get the job done.
The captain will only give you half of that time.
You get the job done in the original time you figured it would *really* take and you're a miracle worker.

By using this simple negotiation tool you can save all parties lots of headaches.

[Lisa]

Saw this sign while I was out tile shopping last week...

These three words: GOOD FAST CHEAP

Pick one...

If you want it CHEAP...it won't be fast and it won't be good.

If you want it FAST...it won't be good and it won't be cheap.

If you want it GOOD...it won't be fast and it won't be cheap.

[Trev]

Originally posted by Lisa@May 25 2004, 11:21 AM
Saw this sign while I was out tile shopping last week...

These three words: GOOD FAST CHEAP

Pick one...

If you want it CHEAP...it won't be fast and it won't be good.

If you want it FAST...it won't be good and it won't be cheap.

If you want it GOOD...it won't be fast and it won't be cheap.
PEARL!!!! :okthumb:

[Almighty Colin]

Being on the other side of this, there is much planning involved around the timing of receiving programming projects. The programming time is one of the factors in determining which programming team a project will get outsourced to. I have gone with a more expensive team before on the promise of a shorter time only to have the project take more than 3x as long as the estimate and completely ruin the original evaluation.

Communication (customer service) is vital. It makes a world of difference and really helps to define the "professionalism quotient" ™ of a company. If a project is going to come in later than estimated or promised it is good to pick up the phone and call your client as far in advance as possible. Receiving word in advance is much better than finding out on the day a project is due that it will be 30 days late.

[Almighty Colin]

Originally posted by Trev+May 25 2004, 04:24 AM--></span><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (Trev @ May 25 2004, 04:24 AM)</td></tr><tr><td id='QUOTE'><!--QuoteBegin--Lisa@May 25 2004, 11:21 AM
Saw this sign while I was out tile shopping last week...

These three words: GOOD FAST CHEAP

Pick one...

If you want it CHEAP...it won't be fast and it won't be good.

If you want it FAST...it won't be good and it won't be cheap.

If you want it GOOD...it won't be fast and it won't be cheap.
PEARL!!!! :okthumb:[/b][/quote]
Yeah :-)

[gonzo]

Originally posted by venturi@May 25 2004, 03:37 AM
Agreed, Dravyk!

It's a slippery slope on both sides. I truly feel that developers want to satisfy their clients' needs as soon as possible, but as a developer I also know that shit happens all the time that gets in the way. Say I sold you a script 2 months ago and while I'm working at a deadline something happens with the script I sold you. What should I do? Supporting my clients is very important, and getting the work out the door is too. It's hard to handle sometimes.

I think, and I'm just free-thinking here, that more people that are looking for custom solutions need to focus on really writing down exactly the business problem they need a solution for and realizing that even if it's a simple thing it may not be a 2hr job. Things happen in development - heck I had a snare put in my widget tonight and it's going to be tomorrow before I can get it fixed.

The other thing is because our clients tend to want everything yesterday, rather than understanding that things, even the simple ones, do take time. Clients need to plan ahead rather than behind.

Don't come to me wanting a full featured paysite backend and expect that in 3 days I can make that happen. I'm just as busy as you, and projects like this take time and consideration to pull off correctly. If you want it done "right now" be prepared to pay a hefty price for something off-the-shelf that you'll still need someone like me to customize to fit your needs and that's going to again take time.

We as developers tend to set unrealistic goals for completion and/or pile on too many projects and get into trouble. It's tough to really balance things. We under bid almost religiously, we run into issues that affect other projects and before we realize it we're backlogged and scrambling to get caught back up.

At the risk of giving away a secret, I think that we all need (developers and clients alike) to get back to the "Scotty Principle". Scotty, from the original StarTrek series, used this principle:

Always tell the captain it's going to take 4 times as long as you know you can get the job done.
The captain will only give you half of that time.
You get the job done in the original time you figured it would *really* take and you're a miracle worker.

By using this simple negotiation tool you can save all parties lots of headaches.
add to that...take what you think it will cost and double it in the estimate.

[AM Jeff]

Isn't that the truth.

Nothing like a client wanting a full blown paysite, members area and all the trimmings and expecting the entire site done within a few days, only to hound you.

Not to mention, when you have questions for them..it takes them several days to even respond back to you. Even thou...they expect the projects completed.
:unsure:

[sarettah]

Originally posted by AM Jeff@May 25 2004, 07:04 AM
Isn't that the truth.

Nothing like a client wanting a full blown paysite, members area and all the trimmings and expecting the entire site done within a few days, only to hound you.

Not to mention, when you have questions for them..it takes them several days to even respond back to you. Even thou...they expect the projects completed.

THat's an important part of what I usually have to teach clients. In a custom environment, the client is an integral part of the development team. Often a good amount of the definition is sitting up in their brain and we have to get it out.


And they don't let us do lobotomies....... :blink:

[Rox]

Great points, Sarettah & Venturi. Here's how we try to get a handle on it (I say TRY, because the best-laid plans go awry - unfortunately more often than NOT):

We have a few analysis sessions up front with clients to gather their requirements for a project, which results in a Requirements Definition Document. The RDD lists in full detail everything the client expects from the project, along with a wireframe of the site or tool we're to build. The RDD usually goes through a series of revisions before the client finally signs off on it. Until there's an approval on the RDD, there can be no schedule or estimate; never mind any work begun on the project. This can be a long and arduous process, and the cost for the work it involves MUST be included in the estimate and budget.

The problem we seem to run into time and again is that the client has a launch date in mind (generally, in my world, tied to the release of a film or TV show) and they expect their project completed and up by that date no matter what. It's especially painful for my department (Interface Developers, DBAs and App Engineers), because we do the last bits of work on the front end and back end, so it's usually our part of the schedule that ends up getting compressed. It sucks when the original schedule allowed for four weeks in Technology (which includes time for thorough testing), and then for some reason art or copy gets held up and is delivered late and leaves only two in which to complete the project. That results in requiring other developers to jump in to help out, and having to work late nights and weekends to make deadline. Oh the joys of going to work every day to face 25 grumpy geeks with more to do than there are hours in a day!

I swear there must be some sort of vision condition that afflicts clients, Project Managers and Marketing folks, whereby they somehow look at a project schedule and under the department responsible for building their site and making it work they see "Magic & Miracles" instead of "Technology." :headwall:

I blame that damned Harry Potter (http://harrypotter.warnerbros.com) :nyanya:

[sarettah]

Originally posted by Dravyk@May 25 2004, 01:17 AM
Wish someone would come up with a proven formula of some kind to make things more accurate in forecasting, to benefit both the programmer and the client. It seems to be a bit of seat of the pants kind of profession that's hard to do it any other way.
There is one. Any of us that went to programming/analysis school would tell you that it works great in an academic environment where you have all sorts of time to play with and your "client" is able to give you their undivided attention for hours on end. Unfortunately, the methodology gets fastttracked in the real world.

Rox described it fairly well there. The process of getting a good definitions document can be a long hard process. To get to a good determination of the actual amount of time and resources required you have to go through a certain amount of your actual design process. To give an accurate estimate, you have to disect the project to what amounts to the "module" level.

Now, the rub here, from the programming perspective, is that if the client, after you go through this process, decides not to buy, then you have to eat that time somehow. If the client does buy, you try to include that time in the actual quote in order to recoup it.

The rub, from the client point of view, is that it takes an inordinate amount of their time for me to be able to provide them with a realistic estimate.

So, in an effort to not have to eat time and an effort to satisfy the actual client needs, the process becomes shortcircuited.

The process that we, in programming school :) learned is basically:

Design: (this is anywhere from an 8 hour to multi month timeframe)
Code: (If the time spent in design is used properly, the coding period can be fairly rapid. Withouty a detailed design, this period can draw out and draw out and draw out)
Test and Debug: (Depending on the quality of the time spent in design and coding, this can be a short time frame or an extended period)

This results in any project being able to be quoted as "at least a year". 3 months design time, 3 months coding time, 3 months testing and debug :)

The actual process that ends up resulting in many cases is:

Design, code and test as we go and hope that we get it right the first time.

:yowsa:

[Rox]

Now, the rub here, from the programming perspective, is that if the client, after you go through this process, decides not to buy, then you have to eat that time somehow.

We took it in the shorts quite a few times before someone finally got smart and put a price on analysis and the process of defining requirements. No mean feat, considering that outside of our Technology department it seems to me there's hardly anyone in our company that understands a fucking thing about the Internet or Software Development. It's bad enough when the clients don't really understand the extensive work it takes to complete a project... but to have Sales people and "suits" whose technological savvy is summed up in their ability to create a PowerPoint presentation is enough to drive one crazy. The same people who are too retarded not to open an "I Love You" infected email are the same ones who can't understand why production on their projects has been halted in order to deal with the results of their infecting the internal network - including the development servers. I fantasize about grabbing my SuperSoaker and going postal... starting with the 4th floor's residents - the suits and salesdorks.

"Well, we just don't understand WHY you can't localize the entire Harry Potter site for 17 languages (including a couple 2-byte Asian) in one week, instead of the three originally scheduled! What? There are only three people who could possibly work on it, as long as they set aside their OTHER projects? Hey, that's only a little over five languages per person, that shouldn't be too difficult, right?" :rolleyes:

I'll be fully vested in 7 1/2 months and at that time I'll be taking a long, hard look at whether my talents might be more fully realized (and appreciated) elsewhere. Of late the ONLY good thing I can say about being a developer in a corporate environment is the steady paycheck and the medical benefits; beyond that it's a trial of one's patience to constantly be called upon to do whatever it takes to make some salesfuck look good when s/he's promised the client the moon with a fence around it, assuming that "Technology will figure out how to pull down the moon," and only providing us with raw lumber for the fence, a week before the launch date.

The stupidest thing I think we ever can do is let people know that SOME projects can be "fast-tracked." Next thing you know, somehow it gets around that they ALL can... and the developers are expected to perform miracles. Unfortunately, more often than not we actually DO pull a rabbit out of a hat (or a huge project out of our asses, in an unreasonably short amount of time), and for our trouble we end up with Project Managers and salesfucks who consider those miracles proof that their expectations weren't so unreasonable after all... bastards! They leave promptly at 6pm without a care in the world while half the Tech department works til 10 and on weekends to save their asses. In appreciation we might get a basket of cookies after launch (woo hoo! That certainly makes up for all that time we didn't get to spend with our families, doesn't it?).

Lucky me, I get to concurrently manage all the testing for a HUGE website, content management app and games arcade app project we've built that's due to launch on 6/3, while customizing and "becoming the expert" on a 3rd party (Jive) message board system we're finally moving over to (did I mention I know fuck-all about programming for J2EE?)... while also doing all the site maintenance requests that come in, too. It'll BE a miracle if there's not an article in the LA times a few weeks hence, under the headline, "Software Assurance Analyst Goes On SuperSoaker Rampage!" :lol:

Whatever the hell a Software Assurance Analyst is... I keep telling my boss that my title would be more accurate if it were "Everybody's Go To Gal," since I do everything from editing and encoding media to building sites to burning CDs and DVDs for the abovementioned clueless VPs and virus-spreaders who are too stupid to be trusted sitting in front of a workstation.

"7 1/2 months... 7 1/2 months... Steady paycheck... Steady paycheck..." The mantra that helps get me through each day!

Sarettah, in another thread you said you wished you'd cultivated the sales side in your field of expertise. I think we ALL wish that more programmers and developers would do so, because having people with actual expertise in what they're selling would be a godsend in managing the expectations of clients, and keeping projects within budget and on time. After all, that's what all parties consider a successful project, isn't it?

[Dravyk]

Tell you though (and this time this is from being the client as opposed to managing a project for a client), no matter what, one can get bit in the ass.

Content God 3.0 should be out in one to two weeks. This is the third programmer I had on this. That is why there had been no new major versions in about 14 months. Last year I had a guy work on it for six months and produce ... NOTHING!

He had the best damned time-table, as Sare and Rox have mentioned, I have ever seen. My expectations were incredible. This guy knocked my socks off at Day One. He broke the project down in three sections. Each section went by "element", then broke each element down to manhours (like 1.8 man hours, very specfic). Added things up, said he could spent 14 man hours a week, gave a dated time table for each section. He has 68 seperate elements ... Guaranteed he would be finished within six weeks. Milepost points with delivery dates in between. The whole nine years. In real time he was taking off for two weeks, so by the calender, two months for delivery, chronicled down to the minute.

He began in May, then .... this happened, that happened, he had a new boss at his day job who was more of a hard-ass, his two weeks off for his wedding and a honeymoon, the preparation for the wedding took longer, he comes back and his bride doesn't like him spending his off the brick-and-mortar job on programming and ignoring her ... yadda yadda yadda. He was so precise he had zero fudge factor (and zero understanding of getting married too, apparently.) He worked on it (remember two months, right?) from May to October I ended up with ... SQUAT!

So much for the great time-table and amazing projection analysis does when it isn't ever kept.

Again, I do see both sides, but that was my worse "burn" so I had to rant about it a little. :)



Last edited by Dravyk at May 25 2004, 02:55 PM