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?

 

[sha76]

So glad to know I'm not alone! Half an hour ago I had the following conversation:

Manager: "So how long will that take you?"
Me: "Well, if you just e-mail me with exactly what you want then I'll let you know"
Manager: <extremely p'ed off> "Well I don't know exactly what I want, I'm just exploring what can be done so I need to know how long it'll take you"

I may have to leave a dictionary open on her desk with the word "logic" circled!

"Your rock is eroding wrong." -Dogbert

 

[entaroadun]

If specs are unclear, in my experience, the best way to handle this is to brainstorm all of the potential requirements and cost them all out. Present it back to them as a menu that they can pick and choose from. This will force them to sit down and think through the specifics of their requirements, as well as ask the cost per functionality questions up front ("Why does adding this teeny bit of functionality multiply the cost by 3?").

You can't leave it to them to give you specs. Your job is getting specs from them. You have to pull; they're not going to push.

This won't be comprehensive, since they'll probably come up with functionality that you didn't consider. But it will force them to think about it. You'd be surprised what comes out of these costing sessions.

As for how to cost out each piece, it depends on experience. No cert can give you that. The MCSD and MCAD certs are excellent for building out your skill sets, but this won't help you with project management. Microsoft has added a section into the certs on project management, but this is purely an academic view. It certainly won't help you assign hours to building a table or form.

There are design archetypes that you begin to recognize as you gain experience. For example, I know that a module that lets people view and edit fields will cost X, that a module that retains version history for those fields will cost 3X, that a module that retains version history and a change log (who did the edits and when) will cost 5X, and that a module that lets an admin rollback specific entries in the change log will cost 10X. Just sit down and think through HOW you would implement something, and rely on your gut to tell you how long it would take to develop and test.

Oh, and pad your estimates. I've gotten to the point that I only need to add 20%. This gets better with experience.

 

[entaroadun]

Oh, and BTW, just to throw this out there...

You have to look at it from the user/manager POV. They have no basis from which to cost out something. So they assume a linear relationship between functionality and cost. All of us here know that sometimes a great deal of incremental functionality can be really cheap, and that a tiny bit of incremental functionality requires a complete redesign. Users don't know and can't appreciate that. If you make the cost to functionality relationship clear up front, it will force them to confront it.

Keep in mind that when you get users to sign off on specs, you aren't just getting them to sign off on functionality. You are also getting them to sign off on cost.

Oh, and you can be flexible about scope creep, as long as every time they expand scope, you let everyone and their sister know how much more it will cost. Laying out a menu of options up front helps with this.

Managers have cost and time constraints as well as functionality requirements. I've been both a tech manager and a LOB manager, and tech typically demands a single set of requirements up front so they can design and cost. But it doesn't work that way from the LOB side. Tech has to present options to the LOB so that the LOB can choose the right functionality given the LOB's time and cost constraints.

 

[entaroadun]

Oh, one more thing...

Bureaucracy pisses people off. Making people sign off on requirements and cost doesn't always help. Engaging them in a conversation about functionality and cost, and the relationship between them, is much more helpful that getting a project artifact out.

Remember that those signoff documents are usually just tech's way of covering themselves legally in case the customer doesn't like what is delivered. It doesn't help establish a clear understanding of functionality and cost for both parties.

To all those who are angry with managers and customers:

They usually don't mean to be difficult. They just have no idea what they're doing. It is your job to guide them. Believe me, they are very grateful for the help afterwards.

 

[BJCooperIT]

I cannot find the post to give credit to the member who said this, but it really struck me as true:

"You can have quick, cheap, or quality. Pick two."

If they want quick and cheap, it will not be quality.

If they want cheap and quality, it will not be quick.

If they want quality and quick, it will not be cheap.

[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

 

[KornGeek]

I love this thread. So much of it pertains to me and my work.

My best advice (beyond what has been given) is to get all requested changes to the spec in writing. This can be as simple as an email. In fact, fall back on email for all conversations about the project. Explain that this helps keep track of what was dicussed and helps protect both parties.

This way, when they say "X will never do W" and then later complain that "X did W and the system failed" you can print the email where they confirmed that this could never happen. It also helps in the discussions where they ask why it went so long past the deadline. You can show them how new changes were requested every day and each change has a time cost.

 

[SQLSister]

One thing to remember in costing is never to estimate assuming an 8-hour day. When I did manpower studies, we always calculated the total manpower needs using a 6.25 (Approximate figure, it's been 20 years) day because every person has unproductive time during the day for breaks, telephone calls, etc.

What seems to work best is to have adetailed task list with times for each task. Then when it takes too long, you can ask them exactly what tasks need to be eliminated. If you just say 3 months without a task list and they tell you to do it in two, then you have nothing to use to get them to limit their wishes in order to get a faster delivery date.


Questions about posting. See faq183-874

 

[rosieb]

entaroadun
I agree, up to a point, brainstorming can work really well. But I think this thread is really about those users who cannot be bothered to think at all. They know they want a database / reports, but that's "technical", they're too busy to work out what they want, they want us to hand it over on a plate, so they can criticise.

My users run the full gamut from:
"I've analysed the data and I want, XYZ (which is in abc table), can you do this for me?"

to

" I want xyz, and this is how I input the data" (But I don't understand the system.)

to

"I want xyz"

to

"Iwant"

Guess which ones get serious attention.

If users can't be bothered to work out what they want, it's not my job to do that for them, in the main they are senior managers after management information.

Half the time some of them aren't even collecting the information they want reported.

If they'll go halfway to helping me define their requirements, then I'll help them. Otherwise, no!

Is it any surprise that if someone gives me something they've really worked on, I give them priority?

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

 

[entaroadun]

rosieb,

I agree with you too, up to a point. It depends on how you view our role. Are we just implementers? No. We get paid to figure out what will solve business problems.

I've been on both sides of the fence, and I understand the frustration. However, it is unrealistic of us in IT to expect business requirements to be provided wrapped with a bow. The fact is that we are staff. We are auxiliary. Why should a salesperson in a sales organization have to know anything about tech or ops? Their job is to sell and bring money in. Our job is to support. The burden is on us to understand how to help, not the other way around.

Large organizations have the luxury of splitting out the roles of business analyst and systems engineer. It's the analyst who figures out the requirements. Small organizations don't have the luxury. However, the need for the business analyst doesn't go away.

Quite frankly, if I ran a small org, I would much rather hire a business analyst than a true techie. I'll get much more mileage out of the analyst who tries to understand the business than the techie who insists that the business understand him/her.

Now, I'm not talking about managers who get in the way on purpose. Managers who won't give you the time of day to at least meet with you to define/brainstorm requirements deserve what they get. Ditto for managers who consciously sabotage projects for political reasons.

At the same time, it is unrealistic for us to expect a user to "understand the system". That's our job, which we get paid a professional wage for.

Most managers don't know what they want or how to express it. They're not being uncooperative on purpose. They just don't know. And yes, it is our job to pull it out of them. My favorite analogy is Helen Keller. It can be infuriating to try to get useful requirements out of managers. But when they finally understand "water", then everything just pours out.


On a side note, my experience with smaller organizations that have organically grown is that people in senior management aren't really qualified to be there. Their positions have grown with the org and they occupy senior roles because they have been there the longest. Most of their ill-defined management information problems stem from the fact that managers feel like they should DO SOMETHING. They just don't know what it is. Fortune magazine tells them that they should think "strategically", but they don't really know what that means. So they puke up some dumb data request that asks nothing.

We have to deal with that. And yes, it is our job.

 

[rosieb]

entaroadun

I don’t think we’re disagreeing. I work in a public sector 250 user environment, and support c 50applications with 2 staff (plus I vacancy). – ie understaffed. We handle anything from resetting passwords, installing and troubleshooting software, installing and configuring hardware, to creating databases.

And I’ve also been on both sides of the fence. In a previous incarnation, I spent 4 years working as the interface between IT and Users, which is where I decided to move into a real IT role.

As a user it would never have occurred to me to demand “reports” without fully analysing what I needed – probably why I got on very well with IT.

I completely understand that users often don’t understand the systems they use, and shouldn’t need to.

My objection is to “managers” (ha!) for whom understanding the system that they manage is beneath them, who need management information, but cannot even clarify what it is that they need to measure.

The fact that, as senior managers, they do not even know what information their own sections gather, is a further source of amazement to me.

Then, they cannot define the basics of what information they need in order to manage their sections, and expect me to provide appropriate reports. (And they get paid vastly more than I do.) Yes, I'll act as a business analyst (though it ain't my job, we can't "afford" such luxuries) but even for that I need input.

I appreciate your analogy, but I disagree, as a manager, you are paid to understand your business, you should know what information you need to manage your section.

Yes, I’ll help them – joyfully – if they are willing to contribute. My objection is to those users who contribute nothing and essentially expect me to do a large chunk of their job for them.

Move me, I'm burning!


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

 

[entaroadun]

We're not disagreeing. I'm just having one of my more gracious days. On a worse day, I would be saying exactly what you are saying.

I guess my point is that we shouldn't complain that senior managers are incompetent. They need us. Does it suck that they get paid that much to do so little? Yes. Is it infuriating that they want others to do their entire job? Absolutely. Is this a bad thing? Not necessarily.

Like Stanley Bing says, you have to learn to feed the elephant. If the elephant needs you, you are safe.

If they complain that you are being uncooperative, kill them with kindness. Contact them constantly to get requirements. Be overly helpful. They will sit down to define specs with you just to make you go away.

Accept the fact that senior managers will want you to do "reports" without telling you what they want to measure. It's a career opportunity. Well-intentioned, clueless managers learn quickly where their bread is buttered, and they get hooked.

Of course, bad ones who take you completely for granted will never advance your career and should be stopped.

 

[LesleyW]

entaroadun -

Helen Keller was a business analyst? LOL that's a new one on me. I've only vague memories of the "water" analogy you're refering to, I'll have to check it out.

Another thing - what is LOB you refer to earlier?

Lesley

 

[ulteriormotif]

LesleyW - when Helen's tutor (Anne?) first met her she had no communication at all. The water comes in because it was when Anne held Helen's hand under a water pump signed 'water' into her hand repeatedly that Helen finally understood and got her first word.

On the issue of 'how long is a piece of string' and analysing time requirements, I'm about to give it a serious shot. We have three internal databases that I'm going to repackage and upgrade to sell to clients, so I'll take the opportunity to write some detailed work breakdowns and see how accurate I can get with my estimating. It'll be a good exercise because I built the databases originally so know them well, but the upgrades are significant enough that they'll give me some good baselines for future jobs.

 

[entaroadun]

Lesley - LOB is my acronym for Line of Business

 

[bednarjm]

I don't remember where I got this:

[blue]If Architects had to work like Programmers


Dear Mr. Architect!

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one.

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don't have nearly enough insulation in them).

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)

Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.

To insure that you are building the correct house for our entire family, make certain that you contact each of our children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.

Please don't bother me with small details right now. Your job is to develop the overall plans for the house: get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpet. However, keep in mind that my wife likes blue.

Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features this house has.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

You must be thrilled to be working on an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can't happen very often. Contact me as soon as possible with your complete ideas and plans.

P.S.:
My wife has just told me that she disagrees with many of the instructions I've given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can't handle this responsibility, I will have to find another architect.

P.P.S.:
Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case.[/blue]

[purple]jim b[/purple]

 

[ulteriormotif]

*laughing* bednarjm - that's just perfect!

 

[willir]

To re-iterate what others have said...
- Itemize as best as possible
- Get the user to sign off on the specifications
- Get the user to sign off on the initial design
- Over-estimate instead of under-estimate -- if you finish sooner, then that's a bonus.

As part of the budgeting process, come to an agreement with your boss on how to handle modifications and enhancements which we know will come.

Also, in a dream world. indicate that you can only be responsible the technical decisions you have input on (instead of non-technical people making technical decisions.)

Sidebar: In another life, the Sales Rep would come and sit on my desk the morning after a demo, and said "I said our software could do this and this" ... "Can you have it done by Wednesday?" on a good day, or "I need it done by..." on a bad day.

Oh yea, I suspect you are a very experienced designer, but I can't help but over-state the fact that a well designed database is much easier to tweak than a poorly designed schema. Ditto for modularizing your code.

 

[ulteriormotif]

willir - I suspect your sales rep has become my boss. I get that pretty regularly.

I'm working on something of a template now that I hope will give me a firmer base to quote from. heh... and I suspect along the way it will open the bosses eyes a bit when he sees how many bits and pieces are involved.

*nodding* absolutely agreed on the good base design. Structure and normalisation is always something that has sort of come as second nature for me - it's always just been quite clear. But I'm working with a couple of novices over email/phone of late... and good gravy they've got themselves into some messes! They're both having a hell of a time getting their heads round what I think are really quite simple data structures. One of them I think just doesn't have it in him, and I'm not sure why.

Question though: modularizing? Whassat?
(swiss cheese brain again)

 

[Tarwn]

Willir: At least your sales rep would tell you what bs he spread, ours waits until after the product is done and tested then asks why previously unmentioned options a-q were not included...for some reason I am the one that is called difficult when I ask why it wasn't mentioned when I passed around the original functionaliuty list, the revised functionality list, and the requirements spec....

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

http://www.tiernok.com/

 

[rosieb]

Tarwn
Obviously you're being difficult, you should have known....

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