Assessing Project Size (1 Viewer)

[Isaac]

Rule of thumb: the project is 2.5 times bigger than it seems after you assess it

 

[gemma-the-husky]

@CraigBaker

I think the real problem is that you are most likely out of your depth. If you weren't you would know how to do this. The best thing would be to spend a few thousand (or hopefully less) getting conceptual help on what is feasible and practical, and then deciding whether your company wants to commit the time and expense to develop towards that solution. You don't necessarily have to do everything. You might find it very worthwhile cherry picking the easier parts initially and extending the project over a longer period.

@The_Doc_Man mentioned that it doesn't matter how big your company is, and that's a real issue. In general terms, a system needs to work just as well with one item as with 1000. It has to allow for all the special cases that arise. If 99% of the time you do one thing, but 1% of the time you do something differently, you have to allow for this 1% occasional event, or you will be stymied the first time the special situation arises.

You can't have a system that allows for, say, 3 alternatives, if once in a while you have more than 3 alternatives. What you need to do is develop a system that allows for multiple alternatives, however many that may be. This is really database thinking rather than spreadsheet thinking.

Good luck, anyway.

 

[Isaac]

You can't have a system that allows for, say, 3 alternatives, if once in a while you have more than 3 alternatives

+1 A+ yes Amen.

This principle that gemma is alluding to will ripple through all of your designs. If you are very new to the game, you will likely be frequently building things that allow for everything you think you will need, until a few weeks of use go by and you will realize you designed it wrong.

If you are still in Mechanics Class, you shouldn't be in charge of building a highway-ready car for someone - that makes no sense.

Go slow, start on practice stuff, don't start out on production deployments that your company depends on. I have no idea why in tech this is so common, but it is done nowhere else. Pre-med college students don't perform surgeries on people independently, pre-law college students don't take a murder case.

 

[CraigBaker]

I think the real problem is that you are most likely out of your depth. If you weren't you would know how to do this.

Sheeesh. I haven't got time to waste replying in detail, but if others still want to comment on the thread, I want to be sure they aren't misled. In case they also don't read the thread properly.

My question is not asking how to do the project. I hope it's obvious that there is no short answer to that question. As I said in another post, I don't have all the answers, but I have the knowledge and experience to work my way through this. As previously said, that includes database knowledge and experience.

This thread was about getting other people's views on the relative size of the project. I had my ideas, but I'm not perfect, and there is much more MS Access experience on this website than I have. The gist of the comments have supported my initial estimates, and the one reminding me that all projects are 2.5 times bigger than originally estimated was very appropriate.

Good luck, anyway.

Nothing to do with luck. I'm racing along enhancing the thousands of lines I inherited, addressing the issues raised by others in this thread, and addressing plenty more.

I'm beginning to get some engagement from the business, which was one of the missing pieces. I take that to mean that the users are seeing progress, and are beginning to see why this system was introduced by the manager who has since left the company.

That might not be the case, but I'll continue working with the company until there are no more benefits to be gained.

 

[gemma-the-husky]

Sheeesh. I haven't got time to waste replying in detail, but if others still want to comment on the thread, I want to be sure they aren't misled. In case they also don't read the thread properly.

My question is not asking how to do the project. I hope it's obvious that there is no short answer to that question. As I said in another post, I don't have all the answers, but I have the knowledge and experience to work my way through this. As previously said, that includes database knowledge and experience.

This thread was about getting other people's views on the relative size of the project. I had my ideas, but I'm not perfect, and there is much more MS Access experience on this website than I have. The gist of the comments have supported my initial estimates, and the one reminding me that all projects are 2.5 times bigger than originally estimated was very appropriate.

Nothing to do with luck. I'm racing along enhancing the thousands of lines I inherited, addressing the issues raised by others in this thread, and addressing plenty more.

I'm beginning to get some engagement from the business, which was one of the missing pieces. I take that to mean that the users are seeing progress, and are beginning to see why this system was introduced by the manager who has since left the company.

That might not be the case, but I'll continue working with the company until there are no more benefits to be gained.

Sorry if I came over as dismissive. That wasn't the intention.

I think it really depends how well it was written originally. If the data analysis was good, and the table designs well normalised, it should be working OK. If you don't think the table designs are good it may be easier to scrap the lot and start over, as engineering bad stuff is not easy at all.

I would look at the tables and relationships, and see if you are happy with the table designs and the RI settings. If there are loads of orphan records, and superfluous records, and other problems that prevent you adding appropriate keys to manage the data, you will have to clean the data before you start.

If you can do this, then maybe look at a way you can cherry pick the best bits, and improve and integrate the rest of it over time. It depends on what your organisation regards as the most important features of the system, and whether they are prepared to commit the time and resources. It doesn't sound like a quick job.

Does that make more sense? Do you feel you can improve what you have, or whether you need to start from scratch almost?

I've worked on poor systems, and it's a time consuming and sometimes thankless task trying to fix them, or more likely to rebuild them in a way that you would have done it in the first place.

 

[The_Doc_Man]

I think Dave's response might have been a bit harsh. But he's also quite correct in a limited sense - you are out of your depth. NOT because you don't know how to program, but because you are (relatively) new to the environment in which you will apply your skills learned elsewhere.

That is one of the unusual aspects of building a business operations package. You need to be an expert in TWO things - and you have only one expertise. You are still developing the other. You know how to do SQL and how to use Access. No problems there. But every business - no exceptions here - has their own unique way of doing business, and you have been thrown into the gladitorial arena with a Swiss army knife.

You didn't get a project bible (we discussed that earlier) and getting info out of your predecessor has been described as "hit or miss (mostly miss)" - which you also discussed. That makes for TWO factors holding you back in "getting up to speed" on the way the business operates. And that lack of a project bible ALSO hinders you because you don't have a write-up of WHY particular choices were made. So to FIX something, you first have to reverse-engineer it.

In this sense, you are the exact inversion of what we normally see here. MOST of our questions come from folks who understand their business but are new to Access. We have to remind those OTHER questioners that they must be the subject-matter experts. Here, that isn't the case. It does require us to think a little harder to understand the inverted situation.

The only REAL solution to your problem is time spent learning what your employer does and how they do it. Pay attention and take COPIOUS notes because when you start getting lost in the weeds, you'll need something to help you regain your bearings now and then.

 

[gemma-the-husky]

@The_Doc_Man
Very well put, I think. That's what I was trying to get at. I didn't appreciate that @CraigBaker was as competent a developer as he must be.