Site Search

My status

News


Recent Articles



Advertisements

  • Digg
  • del.icio.us
  • Furl
  • Reddit
  • StumbleUpon
  • Technorati
  • YahooMyWeb

New Wave Consultancies

You would think that there wouldn't be a conflict between delivery vs methodology, but for a number of the New Wave Consultancies ( NWC ) this is a major issue. If you are not following their methodology to the letter then you are not delivering and you can only deliver if and only if you follow their methodology, to them and their acolytes it's that black and white.

These are the same types of consultancies who are happy for their staff to announce that individually, to their customers, they have never delivered anything into production for 9 years, but during those 9 years they never deviated once from the company methodology; therefore to a certain degree it must have been successful somehow .. Doh !

These same individuals continue to post blog comments about various aspects of software development, which are then read often 10's of people, some of which believe what they write, and thus continue the charade that as long as you are following the company mantra to the letter then delivery can take a second place because it's guaranteed and if delivery fails, it must have been the customer to blame

Delivery into production has to be the end point of any software project. Unless you are in academia and your sole purpose is to waste years trying to teach, as new theories, what we have all been doing in the real world for years, then its delivery that pays the bills, pays the mortgage and feeds the wife and kids.

We have all worked on projects which have not gone into production, this can happen for any number of reasons, lack of funding, lack of backing in the final stages, changing goal posts which mean the end result is no longer needed, or even (god forbid), we got it wrong and it doesn't work. One or two failed projects under your belt gain you experience, they teach you why things go wrong (hopefully), and they teach you what a failed project looks and feels like, but a whole career of failed projects has to be questioned, you have to ask are you the unluckiest developer on the planet, or are you a contributing factor to the failure of the project.

NWC's are often built around the fact that they have applied their methodology to a project and it succeeded, and therefore because it succeeded once or twice it is a pattern for guaranteed success on every project.

NWC's are more often than not driven by a sales force, an army of people who know how to smooze senior management with tales of winning glory, and how that glory could only have ever been achieved through the use of their methodology. Failures are ignored or glanced over as problems with the customer as smoozing goes into over drive and they bring out some Industry luminary who now works for them in a consulting role, spending his or her days not actually involved in the software industry anymore, just writing books about what they think the industry should be. If you are really lucky, they may have even invented the initial methodology and saw it work many years ago on a couple of projects, unfortunately sales people don't like change, they can't sell changing things, they need to sell the same thing over and over and over again because the more they sell, the easier it becomes to sell and therefore the higher the margin in winning the sale and thus that methodology blueprint becomes their can of baked beans, or Ford Mondeo, and they try and stack it high and sell it cheap.

What is needed are Consultancies who ( like Ronseal ) do what it says on the can, listen to the customer, and provide useful pragmatic advice that brings value. There is not and never will be a one size fits all methodology for the software industry. What there are, and this has been proven in the patterns movement, is tried and tested rules, methods of working, processes and, yes, patterns that contribute to success. What is need is a new new wave of Pragmatic Consultancies who come armed with a toolbox of useful patterns for software delivery and can apply some of them to a particular problem.

You employ a consultant because of their experience that they have gained, not what they have recently been taught. A consultant should be able to answer every problem with the standard response "We used process/pattern X on project Y and it worked like Z and provided these benefits.". They should then work with the customer on how best to re-implement that pattern/process for the benefit of the customer. There are of course going to be times when the toolbox doesn't have a solution appropriate, but what you are then paying for is for that consultant to be able to tailor one or two of the existing elements into something that works.

  • Digg
  • del.icio.us
  • Furl
  • Reddit
  • StumbleUpon
  • Technorati
  • YahooMyWeb