Archive for the ‘Corporate IT’ Category
Positive negatives
The stereotypical corporate IT employee has a reputation for uncooperative behaviour. The most common manifestation of this is his tendency to turn down requests from the business with a resounding “NO!”1. Unfortunately, this trait doesn’t endear him to the folks upstairs2, and a few such refusals soon translate into a company-wide negative perception of the entire IT crew.
Now, as some say, perception is reality3. So, the employee, despite his ever-mounting frustration with (what he perceives to be) ever-increasing workloads, needs to handle his customers with a little tact. He needs to learn how to say “no…” in a softer, exclamation-free, corporately-acceptable manner.
How so? Well, by using positive negatives – i.e. by putting a positive spin on the refusal. There are two ways to do this. By presenting:
-
Alternatives: This essentially amounts to saying, “No, but how about <insert alternative here> instead,” or
-
Compromises: This is a qualified “yes”. For example, “Yes, but not before next week.”
In either case, our unnamed protagonist would want to ensure that he can actually deliver on the alternative or compromise.
Obviously, the technique of positive negatives works in any area (consultants use it all the time), and the naysaying, nameless IT hack is merely a straw man to illustrate my point. So – and particularly if you’re a present or erstwhile colleague of mine – be assured that he’s a figment of my imagination.
Footnotes:
1 Some members of this mob are known to issue relatively verbose refusals such as, “No, that’s impossible because <insert random reason here >”.
2 We are talking stereotypes so the person’s a male, he’s overworked, and the IT department is in the basement – safely quarantined from the rest of the business.
3 See this post and the accompanying discussion for an interesting, if somewhat philosophical, counter-view on perception and reality.
_ Driven Development
In recent years there’s been a proliferation of _ Driven Development methodologies, where the underscore can be substituted by just about any letter of the alphabet. Some examples include: Behaviour Driven Development (BDD), Feature Driven Development (FDD) and Test Driven Development (TDD). What is perhaps not as well known, is that the world of in-house application development has its own A to Z of _DD methodologies. In this post I offer short notes on those that have gained popularity (notoreity?) in Corporate IT shops.
For convenience (mainly mine!) I go through half the alphabet here, with the strictly non-binding promise to cover the remainder in a future post.
Off we go then:
-
Arbitrarily Driven Development: ADD, which has many adherents in the corporate world, is characterised by a complete lack of planning or process. Also see item 3 below. This is sometimes referred to as Cowboy Coding.
-
Bulldust Driven Development: BDD is employed when end users don’t have a clue as to what they want. An (often unstated) implication is that developers don’t have a clue either.
-
Confusion Driven Development: See ADD above.
-
Desperation Driven Development: DDD, which is characterised by frantic, undirected activity, is often resorted to when a project runs short of time, money or any other resources.
-
Everyone Driven Development: This is used when every user (and potential user) wants to have a say in defining application requirements.
-
Finance Driven Development: Useful when saving money is the major consideration. The methodology is characterised by ruthless cutting of corners rather than code.
-
Google Driven Development: Development by way of this methodology is popular when the project team doesn’t have a firm grasp of the technology involved. Consequently the team spends many hours filling in the gaps via the well-known search engine.
-
Helicopter Driven Development: This occurs when the effort is lead (piloted?) by someone with a birds-eye of the project. Difficult and nitpicky details tend to be glossed over, much to the distress of developers.
-
Idiot Driven Development: This is where the project decision-maker has strong opinions coupled with little sense. See this post on Scott Berkun’s blog for more. Note that he uses a stronger, perhaps more appropriate, word to describe the decision-maker. This methodology is also known as…
-
Jackass Driven Development: See Idiot Driven Development above.
-
Killjoy Driven Development: Is when the project lead is a confirmed pessimist who keeps going on about how the team’s never going to make the deadline.
-
Luck Driven Development: This happens when the team hasn’t a prayer of making the deadline. They press on regardless, relying on Lady Luck to do the right thing by them.
-
Myopia Driven Development: This is when the project lead and the project team have no visibility of the project beyond a few days. Some dignify this mode of working by claiming they’re using Rolling Wave Planning. Don’t be fooled, though; they really don’t know where they’re headed.
Admittedly, these methodologies aren’t as well known as others that have gained acceptance through their utility or agility. This post is my small contribution in increasing general awareness of these (strictly non-agile) development methodologies.
Stay tuned for N to Z.
Seeing through the hype
The trade media plays a major role in indoctrinating informing corporate IT decision-makers about new idealogies developments in enterprise technologies. In fact, many IT folks first hear of a new technology (or architecture, or whatever) through journals such as Computerworld, and before we know it a shiny new bandwagon starts to roll. It was therefore refreshing to see this article in CIO Magazine, reminding corporate IT punters to be wary of media (and vendor) generated hyperbole regarding emerging trends in technology. In this post I offer my approach to dealing with this issue.
The questions one should ask when evaluating new technologies are age-old ones: what, why and how. I elaborate below.
-
What is it about? The first step is to understand what the technology is about. You don’t need to figure out all the nuts and bolts at this point. What’s needed is a high level understanding, untainted by media hype. You may need to consult your in-house experts for this, but beware of distracting them from their ongoing work. Armed with an understanding of the technology, you can move on to the next question which is…
-
Why do you want to use it? Or stated another way, would your business benefit by using it? There could be several good reasons for implementing a new technology. On the other hand, there will be several more bad ones. You need to ensure that your reasons are the former, not the latter. In this context, it helps to focus on business benefits rather than technology. You’re unlikely to get the go-ahead if there is no demonstrable business rationale for implementing the new technology. If you find there’s none – stop! Else, proceed to the next question which is…
-
How do you implement it? Before you present your recommendations to the business for approval, think about how you will proceed if you did get the go-ahead. Some senior managers may want to see this information before they give their approval, so it is important you have it on hand. Things to consider include: implementation steps, personnel involved (internal and external), rough estimates on budgets, schedules etc.
Now you have enough to build a business case detailing the benefits of using the technology, and how you intend to implement it. Your business case should enable senior management to make a well-informed decision on whether to go-ahead with the new technology or not. If you do get the green light, the work you’ve put in evaluating the technology will also help in developing a project plan.
Trade journals will continue to promote technologies, often uncritically. The responsibility for separating the grain from the chaff lies with those who work at the interface of business and technology. The winnowing begins with the simple questions: what, why and how.
Eight to Late 