confusing users... (1 Viewer)

[mission2java_78]

Im having a dilemma here with a new proposed application for our business development personnel. I am the only developer and am having a lot of problems with communication from the people at the business dev. side. sure they need a nice purdy tool that helps them estimate and quote projects for various customers...and they want me to just whip it up guessing on what the inputs and outputs are? Well thats how it seems now. Also I've been told that there will be near 50-75 end users with a lot of transactions and people logging in and out. So im thinking access isnt the way to go? What does everyone think SQL Server with VB ? Will this step up be a huge learning curve? Also how does SQL Server work? Does it just sit on any type of file server with MS SQL Server running?

That was my first question my next is we currently use some excel spread sheets that get sent to us from Bremmen, Germany which lists pricing information for each component for a proposal. ive been told they need to still use these sheets since our parent company in Germany will continue using excel spreadsheets and they have no plan of sending this data to a database. So will I be able to move this data when they update us with new excel sheets each month? Will I be able to transfer the data over from Excel to SQL Server?

Now for my third question...we've gone weeks without getting much of anywhere. I mean they seem to think I know their complete process (which I do not)...how do I get this info out of them? What should I be asking them...I feel more like a project manager than a developer....so please excuse my ignorance on the hows and whats. Im soo used to already having a functional specification...and using the functional specification to develop the end tool. Now im the one putting the functional specification together and developing the tool . But how am I to develop the tool without getting good info from these guys. What do you guys ask your end users?

Thanks,
Jon

 

[pono1]

Keep your conscience clear by putting forth your best effort to do things, as you see it, correctly.

Start with an e-mail or phone call(s) to everyone involved and re-state the obvious: successfull apps depend on careful planning and that you, before writing any code, need to be educated on the process that your program will faciliate.

Use business cliches to invoke support: Ask for a "resource person." Preface statements with phrases like, "Our best chance for success..." and "I'd rather invest the time up front..." and "If we're going to do this, let's do it right..."

This may result in the project being scrapped because it will mean someone other than yourself will have to do some work. Often, no one wants to put in any effort -- they just want a big return. Quite common. Big ideas, no volition.

If things do move forward, try to get someone to create a flow chart. Interview and re-interview people to verify you understand how the process works. Sketch out the app and try to figure out how long it will take and then multiply by two or three to estimate the time.

Invoice monthly.

Write the app and expect major changes because many people neglected to take the project seriously along the way.

Don't be surprised if the app is only used six months because there is some sort or personnel or partnership re-organization.

Hang in there.

Tim

 

[sambo]

I had a similar problem and I found mapping out a flow chart to be the best method.

Right now I've got a giant piece of construction spanning across my cubicle walls that graphically maps out exactly what the process flow looks like. The trick will be getting someone in the know to sit down and lead you through the steps. A good policy is to try and map it out yourself as best you can, and then go show someone who really knows what's going on. Chances are they will re-mark the paper all over the place.

If you can show them what you think you know, then they can show you what you truly don't know. Make it easy on them and remember, chances are good that end users have no idea about programmatics (is that even a word??).

Good Luck..

 

[neileg]

Sounds like you have at least two problems that will need two sets of skills.

The ones you appear to have now are the developer skills. However, I caution against trying to learn a new database on a complex project. Why not develop the application in Access if that's where your skills lie, and regard it as a prototype? The number of concurrent users estimated is usually wildly out, over or under. Our organisation has potentially 3,500 users for our financials, but we only have 90 concurrent licences, and it's enough!

The skills you seem to lack are those of project management. Pono1 is suggesting a way of bluffing this out. Good luck! An alternative is to choose a standard project management methodology and take a crash course. We use Prince 2, and a three day course makes you an accredited Prince 2 practitioner.

Now a couple of observations.

You will need to formalise the process. If the company is using Excel, you can be sure everyone is using a different approach. Any system you dvelop will be different from the ad hoc methods used presently, and you are bound to get resitance from some or all of the potential users to any imposed system.

If the parent company is providing the info, what do they do with it? Are you in danger of re-inventing the wheel?

Good luck!

 

[mission2java_78]

I'd love to re-use access but their is just way too much information, history, and so on that access I dont think can handle. For instance just one report to the customer can get upto 400 pages long..this is a complete quotation of an assembly line along with a tech. description. As for project mgmt. you're right I lack it and did not want it at any point in my career...at least not this early. I'm more along the lines of developing rather than organizing .

The parent company stores components on an excel spreedsheet they call the "Database file" so thats why I was wondering how I should approach this...they HAVE to use this file since this file is updated monthly.

Anyone else on some input.

Jon

 

[mission2java_78]

Would anyone think that Access could handle something like this. I mean we are talking about a lot of data...one quotation can be over 400 pages long. Reports for one proposal can range from 100 to 1000 pages. There probably wont be that much concurrency but there maybe a lot of people opening and viewing the database records. A lot of history and querying of data.

This is why I didnt think access could handle...but what is the learning curve to SQL Server / or should SQL server be an option we should take along with a vb front end.

Thanks,

Jon

 

[RobertQ]

For my opinion Access is not the right system to handle so many records and USER.
I do not have any knowledge about SQL Server only that it is the Big Brother. So what about: Database in SQL Server and build front ends by Access. This should be possible.

Good luck

 

[pono1]

Pono1 is suggesting a way of bluffing this out

Wo. No. Never.

Jon: Keeping in mind that you only provided a glimpse of your situation, I was mostly trying to suggest that you come clean and explain to your boss and colleagues that developing a mammoth app all by yourself, without any clear means of mutual support, may not result in a decent product. Saying something like, "I'm feeling a little uneasy about the scope and current drift of this project..." may be the place to start.

Regarding SQL: Assuming you don't have an experienced network administrator -- or, better, a DBA -- at your workplace to consult with, a book that will probably answer many if not all of your Access vs. SQL questions: "Microsoft Access Developer's Guide to SQL Server." Sams Publishing. Also, search on SQL at Microsoft.Com...

Regards,
Tim
PS. You never know -- it might not turn out to be as big and gruesome as it seems...

 

[mission2java_78]

pono1 completly understand what you mean.
Hey thanks for the encouraging words...I think Ill just deal with reality and battle it out...besides this could be good experience. Yes maybe painful and a fairly large learning curve but we all need to start somewhere.
Thanks for the info regarding SQL Server...I think its time to learn and share my knowledge with all of you.

Jon

 

[neileg]

Sorry, pono1, no offence intended. I see that I misinterpreted what you said.