Getting the mountain to Mohammed

The business dilemma

Few IT professionals have any grasp of the difficulty facing a business person who needs to stay abreast of tough competitors and try to win competitive advantage via IT without understanding how IT works sufficiently to make the right decisions. It’s a crapshoot where he/she can’t afford to lose.
Having learned the art of decision making the hard way and knowing the difficulty of staying ahead strategically in his business, it’s not surprising that he doesn’t want to hand these decisions over to someone who is seen to be obsessed with technological coolness,  incapable of making a decision without a debugger and bereft of business savvy .
Typically, the sales director at “abc software” wins more credibility and trust with the customer than his own IT experts because he at least demonstrates some business savvy and empathy. The corporate hospitality doesn’t hurt either.

The IT dilemma

Few people in business have any appreciation of exactly how complex and demanding a job it is to ask them what they want, give it to them and get a “thank you, that was great.”

Most professionals would argue that the patient should not be defining the solution, but describing the problem and I would go along with this, but we don’t generally have the luxury of making that decision.
Business managers on the whole are adverse to personal risk and their number one priority is someone to blame if it goes wrong. This can usually be traced to their boss, but that’s no consolation to the IT supplier.

Business people try to equate complex business systems to a car or machine that can be delivered and plugged in and they expect t to buy a tool without knowing what it does and all will be well.
Systems are endless boundless things with unlimited possibilities and similar complexities to the humans who design and use them. Ultimately they are little reflections of humans.
The majority of IT delivery people, be they IT directors, department heads or representatives of suppliers have adapted the approach of defining a product they are going to deliver in technical terms that are hard to refute, insisting on a signature before proceeding and in the case of suppliers, getting their pay loaded up front.  Then they deliver it and walk away guaranteed a cheque and a profit.
If it doesn’t quite deliver then there’s a new document, a new purchase order and the exercise is repeated until success is finally achieved.
Public sector suppliers and increasingly in private quarters too are notorious for the re-negotiation strategy.
This is simply taking the aforementioned  failure a little further to the point of using  it as a strategy to win the business with a cheap bid and then re-negotiate midstream once the client is heavily committed and in no position to negotiate from strength.
In reality, it could be argued that Agile is nothing more than a recognition of this state of affairs and an attempt to bring some element  of structure and communication to the procedure as opposed to letting it run freely into a sort of adversarial mating dance. The problem is that agile applies only to development of software and is useless to the process of buying commercial systems off the shelf (COTS).

Challenges for the business

What is the problem I want solved and is there a reliable solution to it? What are the risks and can I accept them?
Will the solution give me competitive advantage, keep me up, or keep me up with the chasing pack, what choices do I have?
Who’s going to carry the can if it all goes wrong?
Is there really a do nothing option?
Who can I trust with these decisions?
How can I get the business knowledge and the IT knowledge to somehow meet in the middle and give me some realistic answers?

Challenges for the IT supplier

How can I keep the bills paid?
How can I prevent businesses dumping their risk onto my shoulders, I am just the technology vendor, I don’t run their business?
How can I compete with the rest of my industry?
How can I say Caveat emptor without having customers run a mile?
How can I win competitive tenders for projects that almost never complete anywhere close to agreed budgets?
How can I give best advice and still stay in business?

Challenges for the Project Manager or Business Analyst dropped in the middle of all this.

How can I keep the bills paid?
Does the client actually know what they want and what am I tasked with delivering, E.G. Technology, or success?  If it is success, what will that look like? Who will measure it? Am in control of that, or shouldering someone else’s risk?
Will they trust me with their project, or will they cosy up to the supplier over corporate entertainment events and discard my advice?
Will senior sponsors take the time to understand the problem, explore the proposed solutions, make decisions and stand by them?
Will they still remember what they asked for when the final product arrives and if they’ve changed their minds, will it be clear whether they asked for the wrong thing and got it? asked for the right thing and didn’t get it? Asked for the right thing, got it, but it didn’t solve the problem?
Will challenging the client be seen as professionalism or showing them up?

To stay in touch with this series, be sure to subscribe to our feed or register

IT guy and the balloonist

Five stages of an IT project

About the author

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.