Managing Offshore IT

Get techies talking about certifications, and the debate is sure to get interesting. I have my opinion on the topic, including on the merits/challenges of continually ensuring (re)certification; but this entry is not about my viewpoint. Bloggers and the tech media regularly pick on the topic to fuel a debate (and possibly readership). A week ago, I was intrigued to receive an internal mail featuring Amit Jnagal, an Architetect based offshore, who has also recently donned the Corporate Blogger hat. The mail was intended to motivate fellow employees in our practice unit on the organizational drive towards employee certification.

The note began with Amit talking about his earliest mentor in the IT world who motivated him to look at certifications as an opportunity “.. There is a new technology, a new framework or a new product springing up every other week. It is impossible for our customers or managers to gauge how technically sound a person really is. Since we cannot do the evaluation ourselves; we, and more importantly our customers, have started relying on certifications a lot…” Amit was told: and did he take this to heart?

Amit has successfully cleared close to forty technical certifications and has three technology patent applications pending. He justifies the need for certifications by stating “nothing stops you from being good at a technology or a product and also certified on it. Bear in mind that a lack of certification can really hurt you when it comes to two equals. It is not worth taking this chance. Please do not let this pesky little hurdle come between you and your career growth.” And just to drive home the point, he adds “Einstein was lucky to not have worked in our industry, our age or with our global competition!”

I guess there is no debating this matter with Amit!

ps: List of Amit’s Certifications begins with

• Sun Certified Enterprise Architect
• Sun Certified Business Component Developer
• Sun Certified Web Component Developer
• Sun Certified Java Programmer
• IBM Certified WebSphere Specialist
• IBM Certified XML Specialist
• IBM Certified UML Specialist
• IBM Certified eBusiness Solution Designer
• IBM Certified Enterprise Connectivity Specialist
• JCert Certified Enterprise Developer
• IBM Certified WebSphere Administrator
• Certified TOGAF Practitioner
• ... etc...

Posted by Mohan Babu K. at 05:59 AM | Permalink | Comments (3) | TrackBacks (0)

My team is working on a large proposal for a prospect that is looking for a revamp of its Enterprise Architecture Strategy. This prospect, and as other clients are also increasingly doing, asked to speak with a few past clients where we had done similar work. And here, it was not one or two but nearly half-dozen references they were asking to speak with. Those who have worked on pre-sales support initiatives probably realize the significance of such a request.

It is one thing to get an existing client to agree to use a reference to the work we have done as a case study but getting them to actually talk with another prospect; well that’s where things get interesting.

While working on the reaching out to our internal project and account teams, I began pondering over the client request. Years ago when we were newly married, my wife and I went to a nearby photo-studio for a portrait. The photographer did a great job and was pleased enough with his art that he had a request for us: could he blow-up a copy and use it in his studio as a reference? My wife and I were (obviously) flattered but told him that we would think over his request.

Client references – for case studies and referrals -- to vendors perhaps mirror our personal thinking. For many of us, it is one thing to showcase a portrait in the family living room but not everyone wants to be featured in a public shop/mall. Similarly, some organizations don’t want to have their projects and work featured for competitive reasons while others may have organizational and cultural reasons not to do so.

The flip side to this mindset is when one wears a buyer’s hat: when we go to a service provider, we either want a referral or want to review prior work: a photo album/portfolio in case of an individual at a studio or past client case-studies and references in case of software services. Wearing a buyer’s hat, I could see why the photographer wanted to showcase our photo: the photograph was as much about his skill as it was about my enigmatic smile (well I would like to believe that). Similarly, client references and case-studies for vendors are as much about showcasing their skills in solving complex problems as it is about the client’s projects.

Bottomline: if you are the kind of client that asks the vendor for case studies and speak to their references … you should have a policy of allowing vendors to use your projects as references; right?

[ps: In case you are wondering if I agreed to the photographer’s request? Well, I did what most gentlemen would do: let their stakeholder decide]

Interesting blog posts on this theme

• How to Select an Outsourcer: “"One of the most important things is whether the vendor has bona fide, provable experience," Pollock states. "Can it provide a list of customers, case studies, and referenceable clients?"
• Take Note Before You Hire a Sourcing Advisor: the best incentive for sourcing consultants is to earn referenceable clients and repeat business, so in most cases, they work diligently to overcome all of these challenges.  Just take note of these potential obstacles, as you would before you dive into any major investment with the goal of a positive return.
• 12 Keys to Tuning Up Your Sales Force: Intellectual Capital. What is that, you say? These are your referenceable clients. Other than your employees, they are your most valuable asset.
• Are Your Client References an Asset?: One powerful, but often neglected intangible asset is a firm’s list of client references.
  

Posted by Mohan Babu K. at 11:11 AM | Permalink | Comments (1) | TrackBacks (0)

In my previous post, I talked about the extending role of Enterprise Architects at services firms into Marchitects. This ‘selling’ of architecture services is no different from what our peers in client organizations undertake too.

Enterprise Architects, many of whom report into a CIO/CTO organization are also under continual pressure to ensure that the organization derives an optimal ROI from their IT investments, which means they need to ‘sell’ the value of robust, scalable architecture, planning and roadmaps to their stakeholders, some of whom may be focused on the tactical: ensuring that the quarterly targets are met, budgets balanced and operational challenges addressed. Even the ‘strategic’ focus may sometime involve reacting to external trends (read between the lines: it is the economy, slowdown etc)

But back to the challenge of selling that Enterprise Architects at service firms face:

• Thinking beyond revenue and dollars: Most service firms aspire to move up the proverbial ‘Value Chain.’ And when it comes to technology services, what better value chain than consulting with client CxOs on their Enterprise Architecture? However, this ‘move up value chain’ is not as simple, or even sexy as it sounds. Why? Because sales teams at services firms are geared towards (and rewarded for) ‘downstream’ and ‘incremental revenue.’ The challenge is that when consultants work with clients on their EA strategies and roadmaps, they shouldn’t - and generally don’t - have downstream-dollar-signs in their eyes…. which doesn’t always please internal sales teams. [footnote: taking this high-road is not always practical since reward (and bonus) structures for individuals, including architects at service firms are geared towards meeting unit, group and organizational numbers.] 
• Being unbiased while recommending solutions: Another challenge consultants, especially from larger services firms face is while recommending solutions and technology options to clients. Architecture consultants from a product vendor organization may have their account teams tacitly leaning on them. The reason is not hard to find: most service firms have their proprietary solutions, frameworks and toolkits for myriad technologies. Consulting organizations make considerable investments in developing such solutions and the ROI can be derived only when sold/deployed by clients. There are times when these toolkits and products may be an ideal fit for a client need; but not always. Consulting Enterprise Architects need to be unbiased and be willing to push back their Account management teams when need arises. [Again, taking the high-road may come at a personal cost: internal bonuses and incentives]

Clients have an opportunity (and perhaps responsibility) to ensure that the high-end consultants they engage continually provide unbiased inputs. In a sense, the challenge faced by consulting Enterprise Architects is an opportunity to you, the client. You can efficiently leverage their ideation, selling, persuasion and presentation skills to help your internal Enterprise Architects and CXOs sell the ideas and strategies to your businesses and stakeholders. By doing so, you let consultants gain the privilege of being trusted advisors, which in some cases may lead to additional downstream and business for their firms.

Posted by Mohan Babu K. at 04:05 AM | Permalink | Comments (0) | TrackBacks (0)

It is rather unlike me to be off the blogsphere for an extended hiatus, but I guess even corporate bloggers have to occasionally field life's curve balls.

Anyway, back to the theme of this blog; while reading Andrew Manning’s blog entry on “Enterprise Architects: Time for more job titles?”  I began thinking about a barbeque I attended at a friend's place few weeks ago where colleagues and peers had gathered. It was interesting to observe that folks who had gathered were finding it hard to pick on neutral topics beyond the day’s weather and the difficulty in maintaining the lawn, using the host’s backyard as a case-in-point. It was not hard to see why.  A few were from the ‘sales’ side of our business – account managers, engagement leaders and the like – and others from the consulting side - IT architects and consultants. And not surprisingly, it was the few Marchitectects in our midstwho were trying to find an icebreaker.

Going back to Andrew’s list, I guess, one title, I would add is Enterprise Marchitects: folks at service firms who act as a bridge between sales and consulting. The “Enterprise Architects” at service firms - many of whom are also Marchitects -  have a distinct role to play in the industry. The role also comes with its share of challenges for obvious reasons:

• Consulting Architects are generally sought ought in the industry and are well compensated, because of which their services also command premium/higher billing rates. From a software services context, it also means that Architects can add to a significant ‘cost’ component of a typical project. Cognizant of client’s cost constraints, the some Account Managers are more comfortable underselling the need for an architect to ensure a bigger pie of rest of the project rather than translate ‘cost’ to demonstrate ‘value.’ This means the architect, who is already under pressure to be continually ‘billable’ also has to juggle the hat of a Marchitect
• Architects also need to accept the fact that though they bring a specialized/niche skill to the table, they are still considered as ‘resources,’  both to a firm’s own sales folks and of course to client’s FTEs and program stakeholders who naturally look at external consultants as hired-guns.
• Another Marchitecture dimension is to juggle the buzz from internal and external spin doctors. Those of us who have been in the industry long enough know what I mean by spin doctors: folks who can take archaic sounding acronyms coined by industry analysts, visualize a few possible ‘scenarios’ and ‘solutions’ and start preaching it to clients, all with the conviction of a convert.

Enterprise Architects with service firms juggle the above challenges, along with their day-jobs of helping clients architect robust, scalable technology and business solutions. Which brings us back to where I started: the delicate balance between Architecting business and technology solutions - which architects are skilled at – and the business of architecting technology solutions (read ‘selling’ architecture as a service) which is a skill Architects try to acquire. Now, this yin-yang has another dimension to it: measuring the ‘value’ that a consulting Enterprise Architect/Marchitect brings to the table. …

I will continue the line of thinking in my next post

Posted by Mohan Babu K. at 10:37 AM | Permalink | Comments (3) | TrackBacks (0)