My Rules For Solution Engagements …

I’m baaaack … again …

I have decided that I just cannot not blog …

I have too many thoughts and I sure would hate to see all the knowledge I have accumulated disappear with me into retirement someday (or that other thing that shall not be discussed).  30+ years has taught me a lot and I hope that it is useful to somebody out there.

I would be glad to hear directly from you if you really read this btw .. But I do not consider this a discussion forum so if you disagree with what I say here please just go somewhere else and think what you want.  I admit I will not always be right but this is always my blog 🙂 ….

So take my thoughts or leave them please ..  I would however like to hear from you if you see what I say is valuable.  If not then ok contact me too – but be nice – please.  I do not really feel like a cat vs dog people argument anymore … this is what I think and that’s the way it is … unless I specifically have an error that you see.

Dick

Somebody asked this question recently on Linkedin:

“Hello, for those of you who develop Access db’s and apps for small and med businesses – How hard is to establish a common ground on which you and your customers establish a set of requirements?”

Interesting question that I simply felt I had some ideas about so I posted the following up there (slightly edited I’m afraid).  I thought maybe this deserved some kind of Blog posting.

Bottom line for me is that the main pain-point of development in Medium to Small (and also usually large) clients is not REQUIREMENTS “per se” but rather managing the engagement both at the beginning and throughout.  I have found that without appreciating the facts that I am detailing below nearly every project WILL FAIL to satisfy probably everybody involved.  Yeah sure you’ll likely get paid but they’ll likely never implement the solution or worse you will end up supporting a “wheezing dog” solution for a client that will get more and more pissed off as time goes on.  You MUST produce the right solution for the client period .. You cannot let the client force you to create a piece of carp that no one likes and doesn’t do the job for them…

Here we go – not totally random thoughts on this question …

Thirty years of doing solutions for Large, Medium and Small business has taught me that in many ways Medium and especially Small businesses are the toughest to satisfy. These businesses are most often owned and micro-managed by a person who is used to making all the decisions (as opposed to Corporate clients where there people are more used to compromise and collaboration).

To satisfy a Medium/Small business’s requests for a solution I find there is one key component I look for and that is a specific “Champion” in the business (sometimes the owner but not always) who “gets” what you are offering. By “get” I mean that they appreciate your skills as a business analyst and as a developer. He/she MUST respect you and especially respect that you are there to bring your skills in application development to their business need and they must have risked their careers on the success of this solution (really)..

The next consideration whether this is a NEW implementation or a spreadsheet replacement or a “Reno” of an existing Access database.

There are few opportunities anymore to create a database where there isn’t already some kind of automation in place. The first thing you have to do is determine who will fight that change and whether they are going to be an insurmountable problem. An effort has to be made to get ALL of them on-side. The more there are the faster you get to a failed opportunity. Regardless of the enthusiasm from the Boss or the “Champion” these folks will kill you if they are part of the decision-making process.Either they have to be won over or they have to be told that this is happening and they have to “get used to it”. Sad but true.

You have to insist on one rule without exception Saying “That’s the way we’ve always done it ” is NOT acceptable. Contd …

As developer you will, be doing your client and yourself no good if you let your database design be bastardize by their definition of some business process or some strangely laid out form or report that goes against good design practices and yet would deliver exactly the same info and result but in the right way. But at the same time you have to realize that you are just the developer and the business process has to be satisfied. So you often have to suggest alternative ways to accomplish something and fight for it. Again a reason why you need a “Champion” on your side.

After all these considerations then every solution goes it’s own way as every business requirement is different .. like snowflakes.

But without the relationships mentioned above and without respect for you and you skills as a solution developer (justified or not 😉 ) no project will succeed.

Always keep in mind the old saying that you have to NEVER say “I gave you what you asked for but it’s not what you need …” Understanding the roadblocks in place and managing those relationships is ultimately way more important than any technical or best practices in the building of the actual solution.Sorry to say this (and I know it will sound self-serving) but it is only through EXPERIENCE with people and organizations that you can fine-tune these skills. But when I was younger I learned these rules early and have just fine-tuned them over time.

But one of the problems ends up that once you get to a certain age the temptation to tell clients what you really think about the way they are approaching the project can be hard to suppress 🙂 … If you know what I mean ;-).

A very important part of any successful solution is NOT showing your work as you develop it to any more than a small number of people and most importantly 1. The people who will actually USE the solution and 2. NOT anyone Director-level or higher (if you can avoid it). If you ever show a solution partially finished to a Director or a VP I guarantee that they will suggest something be added .. EVERY TIME. ….

AND that something will likely have absolutely nothing to do with the original purpose of the solution and is very likely to mean going back the beginning in your design and development .

AND this one thing (or worse multiple things) will be the ONLY part of the solution they will care about and if you do not deliver it they will become negative on you and your solution and will very possibly kill the project.

I know you don’t always control this but if you can avoid this scenario TRY

If forced into it I suggest you be open and honest about the implications of these suggestions to the project right then and there and/or get your Champion to push back or manage this issue away.

I know that this is hard and I KNOW that the customer is always right …

– these extra people aren’t your customers …

– you have to keep the feature suggestions down to the least people who are most genuinely involved in the business process you are trying to automate ..

– AND you have to focus on delivering something that works and is not a dangerous piece of bad design and compromised spaghetti code to make it look good but that will tip over soon and will be impossible to revise or even maintain going forward..

One last thing … These “special requests” invariably are added without any revision to the budget or the timing. That is a BIG risk you have to manage immediately … The longer you delay that chat the more likely that YOU will end up eating the extra cost …

Talk soon ….

Dick