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.

 

[CraigBaker]

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

Apology accepted. Written words often sound more forceful than they may have been intended.

I do agree with all the concerns you raised, and I have been trying to balance all the conflicting priorities on my project. I also think it's important to ensure inexperienced people using this site don't get the wrong idea. I've learnt a lot already from this site, but sometimes I think sites full of experts can come across as implying that you should have all the answers before you start. Knowing how to do a project could still involve only answering some (basic?) questions six months in. It's a matter of learning as much as possible, as quickly as possible, while avoiding major roadblocks. This is a nuanced and difficult path.

I also agree with all the issues raised by The_Doc_Man. But I think it's important to clarify that having an experienced developer who also understands the business is so rare it can almost be described as a miracle. But he's exactly right that I've needed to understand the culture of the business as well as their processes, while also understanding the code. Once again, there is no perfect way to do that, but there are some very bad ways to do it. Fingers crossed, I'm steering through the issues well so far.

Interestingly enough, I'm still finding it difficult to understand the motivation of the business for building their own system. What I've inherited is based on very sound business principles (and table data structure), and I'm confident it could become a real asset for the business. But getting back to my original question on the thread, I think they could buy a good system for $200,000 or so, over time. I don't think that is guaranteed, due to integration costs with an off the shelf system. The lack of technological maturity in the company will also make it difficult for them to navigate all the vendors out there.

My major concern is that if their in-house system eventually costs $500,00, we've made a mistake and should stop now. The issues with an off-the shelf system could be dealt with for less than that. I don't think it will cost anything near that to deliver the in-house solution, but $200,000 is quite feasible.

Ultimately they will decide when they want to let me go, and at this stage they aren't even asking me how long I think there is left, so I'll keep progressing a little bit in all directions, and balancing all the issues. With a lot of help from the technical answers I get from reading here.

 

[gemma-the-husky]

Well seriously, I think it can be a question that if you want to get from A to Z, you don't do the whole journey in one step. You go in stages and establish breakpoints. You might get many benefits by partially implementing a solution, so it's not exactly doing what you originally envisaged, but it still gives you a lot of benefits.

As you say you need to decide whether to build it yourself or buy an existing solution. I always think that depends on what compromises you can make. If you do it yourself it might cost more, and it might not be as polished, but it should do exactly what you want.

One of the biggest issues is that the stakeholders in the business can have a view about what the solution should provide, without really having a clue about whether what they want is feasible, and even more importantly, is the most effective and efficient solution anyway. The problem for the developers is that they are unlikely to understand the clients business well enough.

There's a lot of things that can go unsaid in the system analysis. Things that the users assume but which aren't obvious to an outsider.

Balancing everything with the project time and cost is not easy. How much time and expense do you need them to commit to be able to demonstrate some benefits, that they can retain even if the full project isn't completed?

 

[Minty]

There's a lot of things that can go unsaid in the system analysis. Things that the users assume but which aren't obvious to an outsider.

This is very true. Even basic things get overlooked.

We recently took over a existing system, and at no point had anyone mentioned that some people like to have two copies of the FE open at the same time.
This rendered the app I built to open the system, and check for updates rather ineffective, and took quite a bit of adjustment.
I still haven't worked out how to change the Access Icon if they open the second copy.

 

[NauticalGent]

This rendered the app I built to open the system, and check for updates...

Do tell...

 

[Minty]

Do tell...

I built a launcher database, that checked a variety of things, version numbers of the local DB against the released version number, created folders if they didn't exist etc, then open the main (updated if required) Access App.

However, when you use VBA to open a database, it will only open a single named instance of that database.
Here's the cue to think about alternatives, but I haven't completely resolved it other than by checking for a lock file and opening a differently named second copy, which seems clunky, but works. It also means they can only open two copies which I like.

 

[Isaac]

I like using vbs / vbscript files to do the launching, although I have used Access as well with good results.
The vbs file can do pretty much anything vba can do and is a quick edit.

 

[Pat Hartman]

I think they could buy a good system for $200,000 or so

You can't "buy" software anymore. You can only lease it, so it is a perpetual fee. I've worked on a lot of installations of "universal", multi-million dollar products and the products are ALWAYS purchased by management and the people on the ground are forced to change the way they do business to accommodate the new software, usually not for the better. I was always there to build the parts that the "everything" software didn't actually do.

Certain types of business processes are fairly standard across the board with perhaps slight differences in different industries. So general ledger, payroll, AP, AR - but, line of business software, should support how the company wants to do business. It needs to be flexible and able to pivot quickly to take advantage of new market opportunities. "Universal" products can never do that.