Ensuring that “Top Down” and “Bottom Up” meet in the middle

30 Jul 2012

A recent meeting with a company was a rare thing for an industry analyst – a meeting where there was little disagreement, bar one small area – which I will touch on later.

From Quocirca’s point of view, technology for technology’s sake is a complete waste of money. Re-inventing the wheel through coding “new” functions where these functions are already available either within an organisation’s existing software assets, or where they could more easily be brought in through the use of off-the-shelf external code is crazy, as the organisation then has all the costs of maintenance, where an off-the-shelf function shares these costs amongst all users. 

But overall, the idea that a business should make a decision, tell its IT department what that decision is and then expect it to create and manage a project to meet the business need is just not right in today’s climate. Why not? To start with, this confuses two different areas – the first is that the business is setting the strategy as it should do, but rather than the implementation of the strategy then being driven from the top down, IT tries to do what it can from the bottom up. So historically, for example, where the board-level command has come down as “We have a problem with our customers”, IT has heard this as “Implement Siebel”, or what was a business issue around managing stock and inventory turns was heard by IT as “Buy SAP”.

Bringing the business and IT together is a theme that Quocirca has long stood on a soapbox over, and published a report about ensuring that technology was implemented purely to meet business needs a couple of years back called “Cloud computing – taking IT to task” freely available here.

So, a meeting with a company called SIG (the Software Improvement Group) proved interesting. Expecting a discussion around code inspection and the lowering of coding errors, to find that the company was a project-driven professional services company was a bit of a surprise, but as we dug beneath the surface it became apparent that SIG is a pretty useful company.

Its project teams (generally consisting of four people) work against a priority list of research topics. Sitting down with their customer, SIG teases out the main areas that are of concern and then carries out a set of in-depth technical and business analyses to identify where things are sub-optimal. Often, this could be in how the code is written – or it could be in how the various functional pieces of code are working together (or not). SIG then provides a set of recommendations to the customer, based on providing a range of possibilities where the variables of risk and cost are balanced against the business’ needs. This is the basis of Quocirca’s Total Value Proposition that its analysts use with its own customers.

SIG works from what it calls a “fact-based” platform. As the project progresses, for instance using SIG’s

Software Risk Monitor or Application Portfolio Analysis, measurements against expected outcomes are carried out and reported back. If there is any deviance away from the planned outcomes, this may not be a problem. The key here is that the real world has a strange way of disrupting longer-term plans. The majority of projects pick a desired outcome that could be, say, eighteen months off, and keep aiming towards that. A “good” project is one that meets that desired outcome in time and within budget.

But, what if the desired outcome should have changed, due to market conditions, the activities of competitor or a merger or acquisitions with another company? Blindly heading towards a preconceived desired outcome has shades of continuing to building aircraft carriers when the aircraft for them are no longer being bought.

What SIG does is keep reviewing the desired outcome to make sure that it is still the best outcome – and that small changes can be made during the project stages to ensure that the real end result is the right end result.

Again, if this is compared to Quocirca’s Hi-Lo road map, it is pretty much the same approach. Quocirca’s belief is that trying to predict more than a year out is not just crystal gazing – it’s more like navel gazing, even for an analyst. The best that can be done is to make a prediction across a range of possibilities for a specific time out in the future and aim for it. Let’s say that this is 3 years in the future. Then in a few months’ time, come back and review that prediction – and keep the end prediction as 3 years from now – and make changes as required along the time line to keep the long-term aim true.

This may mean changes being made to what is going on now – but these changes will be small and of a much lower cost than having to change direction by a much larger amount later on in the project.

So, SIG is a company where Quocirca feels that there is a lot in common between the two companies’ models – which makes it difficult for Quocirca to criticise the company. For organisations attempting to keep current with the pace of change in their markets and within IT, and therefore looking to a more dynamic means of dealing with projects via adopting approaches such as Agile or Scrum, bringing SIG in could ensure that the top meets the bottom in the best way.

However, as stated at the beginning of the article, there is one quibble. The company’s full name is the Software Improvement Group. Sure – it does that. But it is so much more than this – it could so easily mature into a business transformation company that helps a customer to achieve desired outcomes from a much earlier stage than when IT has already become involved.

To that end, once it has worked its way through the low hanging fruit of organisations that understand what SIG does, it may need to rebrand so that it doesn’t spend the first hour of any meeting explaining that as SIG, it is not just about software…

Clive Longbottom, Service Director, Business Process Analysis

blog comments powered by Disqus