Stupid consultant

**thunderlizard** · 30 June 2010, 10:18

You can always hope. But more likely, the consultant's CEO will just happen to lose to the client's CEO at golf this afternoon and you'll be putting in some weekend overtime.

**Sysman** · 30 June 2010, 10:29

This is in the nature of the big-co consultant. Changing your application will be in your budget, changing the other party's application would probably mean that it goes on their budget. Cross-departmental charging and all that.

The interdepartmental thing can be a swine (and it's small wonder that government projects go wrong)

I'd recommend elevating the problem.

**fullyautomatix** · 30 June 2010, 11:08

If his application was there before yours why should he make way for you ?

**SupremeSpod** · 30 June 2010, 11:10

Originally posted by fullyautomatix View Post

If his application was there before yours why should he make way for you ?

WHS.

Think about the additional effort going through regression testing.

Are there any other modules that require that particular "feature" to be present?

**Drewster** · 30 June 2010, 11:29

Originally posted by NotAllThere View Post

Currently doing some work on a high-profile application for a client. We've got the application running nicely, but it causes problems with another, reasonably high-profile application that's been around for a while.

So, we're trying to work out how to get both applications working together. I proposed a simple fix on the other application. This was rejected by a big-co consultant, who says, effectively, it's up to us to get our application working, without changing theirs. Thing is, it's their application that has the fault, but it's only revealed when ours is implemented.

Same client, same system. Hopefully a project manager will giving him the twatting this "consultant" needs.

Are we to assume:
1) You are an expert on this other system (so your suggestion carries some credibility)
2) You are offering (free) full support of the other application after your simple fix has been applied

Mmmmmm thought not!

**Sysman** · 30 June 2010, 11:39

Originally posted by fullyautomatix View Post

If his application was there before yours why should he make way for you ?

If the other application isn't performing to specification. But we don't know whether that is the case or not. This should have been picked up during the specification of the new application.

You are right about the regression testing Spod.

**doodab** · 30 June 2010, 11:40

Originally posted by NotAllThere View Post

Thing is, it's their application that has the fault, but it's only revealed when ours is implemented.

Can you be a bit more specific? Is there some standard or protocol it's failed to implement correctly or is it simply a case of it falling over when you tickle it the right way?

**NotAllThere** · 30 June 2010, 11:58

Originally posted by Drewster View Post

Are we to assume:
1) You are an expert on this other system (so your suggestion carries some credibility)

Yes. The apps are in the same SAP system, they're just sharing resources.

2) You are offering (free) full support of the other application after your simple fix has been applied

No, none needed. It's a binary thing - either it works, or it doesn't. And it's already been demonstrated to work, on a full copy of the live system we happen to have laying around.

I just do the analysis and make proposals. No weekend working for me!

**DimPrawn** · 30 June 2010, 17:41

Originally posted by NotAllThere View Post

Currently doing some work on a high-profile application for a client. We've got the application running nicely, but it causes problems with another, reasonably high-profile application that's been around for a while.

So, we're trying to work out how to get both applications working together. I proposed a simple fix on the other application. This was rejected by a big-co consultant, who says, effectively, it's up to us to get our application working, without changing theirs. Thing is, it's their application that has the fault, but it's only revealed when ours is implemented.

Same client, same system. Hopefully a project manager will giving him the twatting this "consultant" needs.

Which means more of your time, and therefore more money for you. Where's the problem?

Stupid consultant