Maintaining Outsourced Development Quality

Many firms that outsource want to reap all the savings from cutting costs on developers without accounting for the additional overhead they’ll need to manage developers who aren’t right down the hall. All the informal code reviews, requirements clarification, etc. that was done real-time and face-to-face must be made explicit and conducted remotely…often across multiple time zones. Furthermore, the project management performed by the outsourcing company is done for the benefit of the outsourcing company, not one’s own firm.

This overhead can only be ameliorated a bit with tools and technique: there is effort inherent in making inarticulate or tacit knowledge explicit. My heuristic is to add from between 25 and 33 percent more project management effort (beyond the typical in-house estimate range) to such projects.

From my comment on a long-standing LinkedIn post, this one on outsourcing QA.

More on why projects fail

This post on top reasons for IT project failure by Ron Sheldrick has up on LinkedIn for a while. Here were my two cents, nothing new if you’ve followed for a while:

@James Pastor [a fellow commenter] hit on the scope issue early on in this thread. Back in my SAP days we found that poor knowledge of the contract and SOW — especially among the project team and contractors — was a common thread among troubled projects. The strategic assumptions that underpinned the initiative were lost as the project devolved into satifying immediate, tactical needs…which deviated from the original plan.

We also found that stakeholder and communications went begging. While these stakeholder and communications management techniques are simple in form, we found that many project managers can’t muster the motivation or confidence to execute against them consistently. These “symptoms” are great non-obvious indicators for project health:

  • Projects that consistently linked stakeholder analysis, communications planning, and plan execution stayed out of trouble.
  • Project managers who did not fit into, or could not adapt to, customer cultures, mission-critical projects, etc. were reluctant to escalate projects quickly enough.
  • The most frequent communications mistake was failure to execute planned executive-level messaging, which eroded the project manager’s position in the eyes of sponsors and other leaders.

These stakeholder management findings correspond with recent external studies noting that communication breakdowns – especially “keeping quiet” about known risks or issues – are a primary driver of project failures.

A quick note on mobile BYOD vs. CYOD

As a practical matter, one needs to have different policies given the expectations in different part of the world. A mobile device isn’t always expected to come as a perk of the job in the US; however, it’s part of the package many other places. You’ll need to go CYOD in the latter, even if you go BYOD in North America.

From a comment on Sam Somashekar’s LinkedIn post on mobile BYOD (bring your own device) vs. CYOD (choose your own device) strategies.

A gloomy picture of how business perceives CIOs

I followed and commented on this Forrester article re: CIO/business perception, which Dan Muse (@dmuse) of CIO.com posted on LinkedIn.

Half the problem is that we don’t consistently come to the table with technology solutions for business problems/opportunities before being asked. In other words, we react and don’t anticipate what other functions will need. Either that, or we do it in fits and starts, especially if our proferred solution is shot down or unwelcome. Too often we withdraw into our shells — sometimes in a snit — then wonder why we aren’t at the table.

Give and take about initiatives is every other function’s lot in life. We have to persist in proposing new directions over time to have that seat at the table — and solicit, then listen to, the feedback about rejected proposals — so that our next great idea gets the hearing it deserves.

What do you do to get a better class of vendor cold-calls?

I posted this the other day on LinkedIn:

Now that I’m the head of IT, I get an impressive array of sales folks calling, emailing, and trying to connect via LinkedIn. I’m more than willing to talk to someone who’s coming in via an introduction, but the cold calls I almost always ignore.

That said, I appreciate that there’s potentially valid information in sales and marketing outreach, and I do find a few of these cold-calls useful or interesting. Sometimes the contact will be from a technology company I’ve heard is doing great things. Sometimes it’s a recruiter who shows some sensitivity or expertise re: our hiring market.

Unfortunately, the overall yield of valid contacts isn’t great. Is there anything that you’ve done to improve that yield?

There are a number of decent comments, but no magic bullet. Any ideas?

How can cloud computing help transformation projects?

I commented on a LinkedIn post re: cloud and “innovative” financing models. My take was that:

I’m wary of getting too close to full capacity on any potential constraint, as it means we can’t respond quickly enough to a potential business requirement. Zero slack often becomes a rationalization for a zero change or “we can’t do that” mindset.

Also, per David Kerr [a fellow commenter], the idea that the cloud will solve “speed bumps” driven by topics external to the project is dubious. If nothing else, you have to have this specific contingency in place during the project contract discussions. You’ll then have to navigate the flood of change orders that will cascade from invoking that contingency mid-project.

Not getting that promotion and handling failure

We talk a lot about the need to fail and there are lots of great nuggets of wisdom like “A person who never made a mistake never tried anything new.” and “Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.”  But doesn’t that all sound like a bunch of hooey when failure visits you personally?

The best example of this phenomenon is when one doesn’t get a promotion.   As Amy Gallo puts it in her HBR blog post “Didn’t Get That Promotion?

Getting passed over for a promotion can be disheartening and even humiliating. Whether you thought you deserved the job or were promised it, no one likes hearing that they didn’t meet the mark.

It is a rejection that’s more painful than any save for unrequited or lost love.  One can brush off a failed project or presentation fairly easily… at least compared to hearing that one didn’t quite cut it. 

Gallo and her experts hit on familiar points up front: act ( but don’t react), get some outside perspective, no whingeing.  However, I found the last two points the most valuable from my experience.  I would go even further: reframing the experience and reenergizing one’s network are essential to make the obvious work.  One can’t exercise patience, get “outside > in” feedback, then take appropriate action without taking those two steps first.

Follow

Get every new post delivered to your Inbox.

Join 1,358 other followers

%d bloggers like this: