People vs Tools and Techniques

One of the things I am doing at the moment is reviewing our delivery methodology, looking at how different techniques and can be used with the current stack of Oracle BI tools to effectively deliver projects. This involves looking the tools currently on offer, such as OBI EE or Warehouse Builder and a number of different design techniques such as dimensional modelling, dashboard design and various agile/RAD methods, and seeing what we think works the best.

<p>My path into IT was a Software Engineering degree, so when setting out on these types of tasks I naturally revert to this subject area to feed into the process. One of the references I was using was book <a href="http://www.amazon.co.uk/Facts-Fallacies-Software-Engineering-Development/dp/0321117425">Facts and Fallacies of Software Engineering by Robert Glass</a> (review <a href="http://www.codinghorror.com/blog/archives/001083.html">here</a> &#8211; I would also recommend the whole <a href="http://www.codinghorror.com/blog/">Coding Horror blog</a>).</p>


<p>The book starts with a section about management and a couple of comments struck me. First he quotes Alan M. Davis (<a href="http://web.uccs.edu/adavis/UCCS/index.htm">here</a> and <a href="http://en.wikipedia.org/wiki/Alan_M._Davis">here</a> &#8211; not the comedian):</p>


<p><cite>Good management is more important than good technology.</cite></p>


<p>And the first two facts in the book are:</p>


<p><cite>The most important factor in software work is <em>not</em> the tools and techniques used by the programmers, but rather the quality of the programmers themselves.</cite></p>


<p>and</p>


<p><cite>The best programmers are up to 28 times better than the worst programmers, according to &#8220;individual differences&#8221; research. Given that their pay is never commensurate, they are the biggest bargains in the software field.</cite></p>


<p>These are long established facts/opinions (maybe controversially) and the cornerstone of books such as <a href="http://en.wikipedia.org/wiki/Peopleware">Peopleware</a>.</p>


<p>So, I then have to ask myself if we are wasting our time putting a lot of effort into setting out a project methodology, should we just concentrate on recruitment?  If we get the right people in, will our projects always be successful?  As we are a service provider/consulting company trading on providing an expert service, based on experts we employ, we hope that this is something that we have got right, and (with my selling hat on), I believe that&#8217;s one of the reasons we are used.</p>


<h2>Why care about tools and techniques?</h2>


<p>Taking tools as an example, say an organisation is fully committed to using analytics for competitive advantage and this was driven and supported from the highest level in the organisation, then would it really matter if they use the Oracle stack or Cognos (IBM)?  Sure, it may be easier to integrate if they chose the same vendor as their transactional systems, but the choice wouldn&#8217;t be the critical factor that determined the success of the project, the implementation of it would be. As a quick aside there is an interesting article <a href="http://www.intelligententerprise.com/channels/business_intelligence/showArticle.jhtml?articleID=207200401&#38;pgno=1">here</a> looking at the offerings of each of the &#8216;big four&#8217; BI vendors.</p>


<p>Similarly with techniques, there are probably a number of approaches that could work, <span class="caps">HOWEVER</span> as a service provider/consultancy I think it is important to have a clear approach. We offer services in a niche area, and organisations will often get us in because they do not have not expertise, or enough of that expertise in house. I feel if we can initially give people a roadmap of how the project will progress, what resources will be required when and when deliverables are expected then this has got to be a good starting point, and I think our clients look to us for something like this.</p>


<p>I think the really important thing to realise is that by following this (blindly or otherwise) will <strong><span class="caps">NOT</span></strong> just mean the project is automatically successful. It is everything that happens after day one that will determine whether the project is successful, and this comes down to people, how the project is managed (some of which will come from our methodology) and how good the developers/consultants are. Similarly with tools, there will be features and functionality that differentiate the tools and chosing the right one will give you a better chance of success, however what is important is what the development team do with that tool after day one when it has been chosen. That is what will determine the success of the project.</p>