When the boss asks "so what's your budget to build this database?"

[ulteriormotif]

... he gets a bit tetchy when I reply "how long is a piece of string?"

Background: small/medium company of consultants (not IT). I'm the resident geek - run the network, training staff in general office apps, website and database development (Access). NB: I'm also the FIRST resident geek - it's a developing role that has basically come about because they realised I had skills they could use.

We're starting to develop more and more databases, and they're getting larger and more advanced all the time, and some are now being sold to clients rather than just used in-house.

My problem is setting the budget to build the damn things. Every darn time I end up running over. I know to a degree it's the nature of the beast - or the beasts I work with shifting objectives - but it's an ongoing problem. Just once I'd like to be able to complete a project without an overrun.

Aside from the nature of the beast though, I know it's also my own inexperience with this. I'm entirely self-taught, and while my skills are pretty good after five years or so working with Access, it's still very much ongoing learning, and as tends to happen with self-teaching, "swiss cheese knowledge"... which makes it hard to put a time on how long something is going to take.

Is there some magic formula out there for timelines/pricing databases?

Is there a course I could be looking at doing? I'm definitely interested in learning more, either in terms of a hard-core course in Access (preferably where I wouldn't have to spend forever going over the stuff I do already know though). Are the Microsoft courses worthwhile? Or something more... IT quantity surveyor/project manager type thing that would deal specifically with running these types of projects. I dunno, that's probably overkill. Realistically, filling in the holes in that swiss cheese knowledge might go a long way towards fixing things.

NB: I'm in New Zealand and work full-time. Courses need to be distance self-paced sort of thing.

Or am I pipedreaming? Does setting timelines give you nightmares too?

 

[rosieb]

I sypmathise, I'm also a severe case of Swiss cheese knowledge. I think one of the keys is to insist on a proper specification up-front, make your estimates (then add your comfort factor). After that, any changes require a change to the estimate, and make it painful, requirements drip-fed do lead to a massive increase in development time.

Rosie
"Never express yourself more clearly than you think" (Niels Bohr)

 

[RiverGuy]

What does the budget consist of. I mean, is it just your time, or is there some kind of equipment/monetary investment associated with each project?

 

[ulteriormotif]

Riverguy, it's essentially just my time.

Rosieb - I'm glad I'm not alone. I often think half the problem is that these guys are 'concept' guys. They don't know and don't want to even think about how something will work.. just that I can make it happen. It's often like pulling teeth to even get a real idea of what they want.

Them: I need a report about the sky.

Me: Sure. You want to know why it's blue, or how high it is, or what it's made of?

Them: Well... why it's blue I guess, but it wouldn't hurt to know what it's made of.

Them some time later: oh hey... this report doesn't tell me how high it is!

 

[CajunCenturion]

In this case, nothing replaces experience. rosieb is absolutely correct in that you should do everything you can to obtain as complete functional specification as you can. The next exercise is to take the application apart, break it down into pieces as small as you can. The pieces are small enough so that you can comfortably say, I can do that in x hours, where x is not that big of a number. Then you need to add in testing time. I would do this bottom up. Start at the individual tasks, small enough so that you have a reasonable estimate of how long it will take. Work your way up, allowing for testing at higher levels. At the higher levels you get into integration testing and so forth. Figure in how long it will take you to install the system, how long it will take you to train the users, and them add in how much time you'll spend writing status reports, attending meetings, delivering progress reports. Is documentation involved? Add in that time too, and be sure to include time to proof-read the document(s).

It is hard not to allow yourself to get overwhelmed with the overall application, and that is why you need to break it down as far as you need to. Then I add somewhere between 20% to 35% to account for unforseen hurdles or other little gotchas along the way.

The more you do it, the better you'll get. It is also a good idea to keep track of your actual times for each of the tasks so that you can compare your budget estimate to the actual and compare. When you're way off, ask yourself what did you misjudge, and add that to your experience layer to help you the next time.

You may never get it right, but you should get better and better as your experience increases.

Good Luck
--------------
To get the most from your Tek-Tips experience, please read FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[BJCooperIT]

A very long time ago I attended a systems analysis class at IBM. The object of the class was to estimate how long it would take to develop a parking ticket system to catch scofflaws. After one week of all the tricks of the trade including average lines of code, illness, coffee breaks, experience factors, etc. my team arrived at a final figure on Friday morning. The instructor announced that afternoon, just before he let us go, "Now...take your estimate and multiply it by three!"

If you are an optimist and constantly under-estimate, try it. It is 28 years later and the formula is still more accurate than I am. Take your top-of-the-head budget figure times 3 and see how close that figure comes to your final budget.

[sup]Beware of false knowledge; it is more dangerous than ignorance.[/sup][sup] ~George Bernard Shaw[/sup]
Systems Project Analyst/Custom Forms & PL/SQL - Oracle/Windows

 

[ulteriormotif]

CajunCenturion, you're a gem, as always. I rather suspected 'break it down more' would be the answer somewhere along the lines. It does lead to another question though - how long do you allow to do that breakdown?

Again, I get hit with on-the-spot requests for prices.. and the company is big on minimising non-billable time, ie, prep time that might stop those overruns (duh!).

BJCooperIT- *LOL* funnily enough, I've been caught out so badly with underestimating time in the past that I now routinely double my estimate. Triple though... if I had tripled this last job, I think I would have come in just under budget. *writes a big ol' X3 on the pinboard*

Seriously though, what do you folks think about the Microsoft certifications? It's been a year or two since I looked at them and can't remember the acronyms clearly... MCDBA or MCSD? I remember thinking the systems developer sounded like what I'd like to do. Are they worthwhile?

 

[CajunCenturion]

How long is a piece of string?

Sorry, couldn't resist. It will vary from project to project based on complexity and size.

Good Luck
--------------
To get the most from your Tek-Tips experience, please read FAQ181-2886
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[ulteriormotif]

*lol* yeah, ok. deserved that. Guess I just need to get tough with the boss and tell him I'm going to take the time it needs.

 

[rosieb]

ulteriormotif
I wish I took my own advice. I recently worked a holiday to create a database, nothing complex, took about 5 hours. But it was "urgent", ...took them a week to look at it, then 4 major changes over 3 weeks. I reckon that if I'd had the full requirement it might have taken 5.5 hours, as it is I've probably spent 3 full days re-hashing the thing.

However,

Been having an ongoing debate with the same group for 8 months now, it runs like this....

Them:"We need some reports, urgently"
Me:"What do you want"
Them:"Give us a report and we'll tell you what isn't right"
Me: "NO, tell me what you want, in writing"
Them:"Can't you sit with of the officers and work out what we need?"
Me:"No, give me a written requirement"
Them:"But we're too busy. OK we'll give you a spec."

A month passes
Them: "IT promised to give us some reports, they're being un-cooperative"
Me:"What do you want"
.....
repeat monthly.

Actually it's becoming fun, I had a 3 hour meeting with 7 of them "I hope you don't feel intimidated" then launch into above, 7 times.

Followed by complaint to my boss, "un-cooperative".

So stand firm! And get a spec before starting any work.


And, follow CajunCenturion's advice.



Rosie
"Never express yourself more clearly than you think" (Niels Bohr)

 

[ulteriormotif]

You know, the great thing about this forum is just sometimes finding out you're not alone, and you're not crazy.

RosieB, I can so relate to everything you said there... particularly the 3 days rehashing.

On this last job I tried to avoid that as much as possible.

Client: "So when X does Y, Z will happen.

Me: "What if X does W? Can that happen? Because that makes a significant difference to how we need to handle this.

Client: "Nope. Can't happen. X never does W, and never will."

(repeat above 3x on separate occasions).

Client some time later: "Oh, X has done W, and now it doesn't work."

Me: *Rip, strip, restructure, rebuild and swear a lot*

 

[rosieb]

Yup, hence the 3 days! And I have one or two (or 50) other things I could be doing during that time.... (IT is so unhelpful, Yes, I could have done your upgrade but this is supposed to be important......)

The old, "Oh yes, I didn't want to bother you with this but it also needs to do X" ===> almost complete redesign of database structure.

Which is why you have to make changes painful, one way or another, are they really necessary? If so it will cost X (time or money).

the great thing about this forum is just sometimes finding out you're not alone, and you're not crazy.
and it's a great place to let off steam! grrrrrr!

Also, the advice from the more experienced is immensely valuable.




Rosie
"Never express yourself more clearly than you think" (Niels Bohr)

 

[ulteriormotif]

Which is why you have to make changes painful, one way or another, are they really necessary? If so it will cost X (time or money)."

I have to admit, I glossed that a bit when you first mentioned it, but I really do need to take it to heart. Another quote for the pinboard.

 

[jrbarnett]

Just as an aside, the answer to the question "How long is a piece of string?" is "twice the length from the middle."


John

 

[johnstrang]

Rosieb,

What you wrote

Been having an ongoing debate with the same group for 8 months now, it runs like this....

Them:"We need some reports, urgently"
Me:"What do you want"
Them:"Give us a report and we'll tell you what isn't right"
Me: "NO, tell me what you want, in writing"
Them:"Can't you sit with of the officers and work out what we need?"
Me:"No, give me a written requirement"
Them:"But we're too busy. OK we'll give you a spec."

A month passes
Them: "IT promised to give us some reports, they're being un-cooperative"
Me:"What do you want"
.....
repeat monthly.

Actually it's becoming fun, I had a 3 hour meeting with 7 of them "I hope you don't feel intimidated" then launch into above, 7 times.

Followed by complaint to my boss, "un-cooperative".

So stand firm! And get a spec before starting any work.

 

[johnstrang]

Continuation from my previous post which I posted before completing the reply

It is exactly the situation I found myself in a couple of months ago - nice to know I'm not alone!

I can't agree more "Get a spec before you start" and if changes are requested, do your best to include them but don't be afraid to say NO.

John

 

[ulteriormotif]

How long is a piece of string?" is "twice the length from the middle."

Heh. Another for the board. Right under

"Designing Databases = Knitting Treacle"

and

"I LOVE DEADLINES
I really like the cool 'whooooshing' sound they make as they go flying by"

An update - had my annual performance review this afternoon, and it was all good. The boss loves what I'm doing and now sees software as an actual product area for the business. YAY!!

He was also less concerned about overruns than I expected and has pretty much given me the go-ahead to upgrade existing products as I see fit, and start looking for new products to develop. DOUBLE YAY!!

It definitely helped that I was able to take some of our discussion here into the meeting (heh.. and burn off a little steam here before the meeting). So thank you all again.

 

[ecobb]

I LOVE DEADLINES
I really like the cool 'whooooshing' sound they make as they go flying by

That's great!!

Yesterday, at 3:30, my boss comes in and says "I need you to build this site for me and have it tie in to two of our database servers...by 5:00"!!! He wanted seperate sections for AR, HR, Safety, Maintenance, Financials, etc... It seems that the owner of the company had requested it, and wanted to look at it first thing this morning in a manager's meeting. My boss finally admitted that he had "been meaning to get with me about this for a few days...". So, I came up with a basic background, border, header, etc... for the site, got it looking nice, then I put a bunch of links there for each of the sections which all point to an "Under Construction" page. They loved it. It turns out all they wanted to do was see what it was going to look like. They didn't care about the functionality or what was going on behind the scenes...just wanted see what color it was going to be. Whew!!

Sheesh...talk about getting specs?? Planning?? What's that? Anyone can design a fully functional Intranet system in an hour and a half!



Hope This Helps!

Ecobb

"My work is a game, a very serious game." - M.C. Escher

 

[Tarwn]

Heh, been there ecobb

I have seen this same problem (specs and lack thereof) time and time again. Depending on what the requestor does for the company I modify my approach a little, but basically:
I explain that they wouldn't want to execute "important task here" without prior planning and that a spec is part of prior planning for me executing "requested task here". Building that plan means we have the same idea in mind from the beginning and requires less time rewriting later down the road where our understandings diverge or a forgotten piece of wanted functionality comes to light. I don't like specs, you don't like specs, but I hate wasting time and money more. On the other hand, if we would rather spend less time planning and more time doing, I have no problem going and making stuff up as I go along, as long as you keep signing my paychcks and don' giv me anything else to do for the few months after you want this done by.


Like I said, the wording changes a little differantly depending on who I am talking to, but generally I get my spec and we build a couple mock intefaces together.

Course it helps that the last major project I worked on had been in development 12+ months before tey gave it to me. I threw it out and had it done and working in 2 months... (the original had to many mid-stcream changes, it wouldn't even install anymore). So this significant difference helped back up my point on why specs are good.

-T

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:

http://www.tiernok.com/

 

[philote]

Anyone can design a fully functional Intranet system in an hour and a half!

ulteriormotif, you're definitely not alone. I too am the first, and only, 'geek' at my company. When I got hired it was mainly for training employees on software and network admin stuff, and was explicitly told this was NOT a programming position. That didn't last long once I started developing the intranet and was asked to do a programming/database project.

Well, I just got that project 'finished' on Monday, though I originally told them I could have it done by April. I did however have it working by April. It just wasn't exactly what they wanted since I never got a clear answer on how it should work. Communication's horrible in my company and even though I asked and asked and got answers on how this and that should be done, they constantly changed their minds or I found I was asking the wrong person.

So, I too am open to suggestions on how to improve this process the next time I have a project like this. I'll definitely be requiring some sort of specs and have a lengthy, painful process for requesting changes, but can someone give me more specifics on how to do this? How and in what format should I get the specs? How detailed should they be?


This thread's really made me laugh because it hits soo close to home. Great posts all!