Transparency in analyst analysis/ratings

Doug Henschen highlights (here) one of the mysteries of the analyst business — just how are those ratings calculated?  To Doug’s eye, Gartner’s 2009 BI platform Magic Quadrant’s rating of the combined SAP Business Objects portfolio does nothing more than split

the difference between its 2008 positions for SAP and Business Objects, as if SAP dragged Business Objects down from its front-runner status. In its “cautions” for SAP, Gartner cited… problems [that] were all evident (and cited by Gartner) last year, so I’m not quite sure what to make of the new position.

I share Doug’s hang-up with these types of rating systems — there’s not enough transparency about the “whys and hows.”  I also share his increased admiration of

Forrester’s Wave Reports, which include scoring grids that detail how the vendors fared and compared on as many as a dozen different attributes.  I know it kind of takes the “magic” out of the rating methodology, but in an age when visibility, auditability and good governance are valued, it just seems like a better approach.

People factors in managing consultants

Elizabeth at A Girl’s Guide to Managing Projects blogs (here) on a recent Forrester report (report abstract here) on people management in large IT implementations in Australia and New Zealand (ANZ).  As she notes, it is a useful twist that they focused on the challenges of managing third-party consultants.

I haven’t read the report, but it looks like it has some sound recommendations.  In particular, this suggestion may sound obvious: one should provide an “[i]ntroduction to your processes and procedures to ensure that the external consultants know how to raise issues and track progress.”  It can’t be that obvious, because I’ve seen exactly one customer who did so.

One caution about the study: the ANZ SAP consulting market is white hot.  It is probably useful that Forrester looked at such a challenging market.  However, keep in mind that some of the issues they describe may be driven by the tight market itself.

SAP, India, and Innovation — this article understates the impact

It isn’t that this article by Navi Radjou of Forrester is wrong (here), but it misses at least three areas in which SAP leverages India’s talent and mind-set  Sure, what Ranjan and the SAP India team have done (and are doing) is impressive, but the impact of India and a globally adaptive approach are far more widespread:

  • Solution Development: I won’t belabor this, but many key parts of the SAP solution portfolio are developed in India.  The various SAP Labs sites in India moved quickly from coding functions, to designing modules, to delivering entire solutions.
  • Global Services Delivery: Jan Grasshof’s team is much more than a simple “me-too” outsourcing shop.  I was in Bangalore last week and saw the sophistication and speed with which they could bring value to the table.   A great example — coincidentially with Nokia, also in Navi’s article — was when SAP Global Delivery both supply chain expertise and rapid prototyping to accelerate an implementation. 
  • Management Development: My organization’s management program includes one week in Bangalore, a measure of how integrated a global mindset has become in our way of working.  SAP sends executives and managers half-way around the world so they can feel, taste, and touch what this new business world is all about.  We also have exchange programs — even within projects — to ensure better, more consistent communications and understanding among our various teams.

IT Project Failure — executives asleep at the wheel

Laurie Orlov from Forrester has a great post about how inattention dooms so many transformational projects (here).  From her piece:

[T]here are many good ways to reduce project risk. And there are also guidelines on how and when to kill failing projects.  No need to belabor them.  But trumping all of these, in my view, is the go-to-sleep attitude of enterprise executives (maybe even including the CIO) as these projects proceed….

CIOs who let business executives off the responsibility and oversight hook, if they let them send underlings to meetings, if they provide a status and get no feedback, if the scope of deliverables is intergallactic, if development is not iterative,… are aiding and abetting [t]heir own project failure….

My experience is that CIOs get distracted by “strategery” and forget to focus on the basic blocking and tackling of project and development management.  Per my comment on Laurie’s post, CIOs who aspire to strategic archetypes of IT management (Laurie’s Forrester study is here, behind a firewall) get distracted because:

  1. They’re acting out according to an archetype they want to be, not what is required.
  2. They have a disinterest in building a solid foundation in core functions, so they end up ignoring, then fire-fighting, problems with utility functions like e-mail, voice, etc.
  3. They believe game changing initiatives have to be big, so none of them question a multi-year timeline.
%d bloggers like this: