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.

When you choose not to decide, you still have made a choice

That snippet of Rush’s “Freewill” ran through my head after I read Michael Krigsman’s post on developers’ perspectives on IT failure.  What caused my earworm?  It was this section, dealing with IT priorities:

The survey breaks out IT quality priorities by role in the organization, and yields an interesting gap between the project managers and business stakeholders. As the following table shows, project managers prioritize budget and schedule while people in the business seek the best solution. 

More interesting to me were the portfolio and strategy implications of the answers.

  1. It didn’t seem like the respondents understood that these options would require trade offs…every option received over 50 percent. 
  2. Where are the resource trade offs?  Resource constraints are much “harder” than cash budgets in my experience.
  3. I’m not sure how well thought through the survey was.  “Shipping when the system is ready is more important than shipping on schedule” and “Delivering high quality is more important than delivering on time and on budget”.  These are almost the same trade off, even if the “high quality” question slips in “budget.”
  4. Left unexplored are the tradeoffs within the portfolio at large.  It is great to say you’re willing to trade time and resources for quality or ROI.  However, that’s a point analysis that leaves out the opportunities foregone. 

One of the reasons IT projects are under such time and resource pressure is that there’s a domino effect.  In other words, if one project slips, the rest of the portfolio slips because you can’t simply plug in new resources, there are technical dependencies, etc.   And what else slips?  The benefits from these future projects.

Three comments on Michael Krigsman’s: The devalued future of IT in a marketing world

I had three quick points re: Michael Krigsman’s provocatively titled post “The Devalued Future of IT in a Marketing World“. This situation is as much opportunity as it is threat, so be proactive when addressing: 1.) Embrace your firm’s ability to shift funds from SG&A to revenue-generating functions. That was the idea behind more efficient and effective IT, right? 2.) Ensure that marketing colleagues are choosing their spend, not just deciding.. It is great that they want to decide spend…but not “all they can eat.”. In other words, drive portfolio prioritization of alternatives (don’t accept “all of the above”). 3.) Drive benefits measurement and realization. Probably the biggest gap in all PMOs across functions. A good first step is to insist on explicit value measurement plans in project plans.

Become Focused by Failure

Great WSJ article by Prof. Ken Bain that takes the Cub Scout motto of “Do Your Best” to the next level. 

It also hits home personally.  I was often praised for being “smart”, which is like being congratulated for being “lucky.”  The implication is that I didn’t have much to do with it.  That approach wasn’t too “smart” it turns out.  As Prof. Bain notes, for about 25 years social scientists have developed:

key insights into how successful people overcome their unsuccessful moments—and they have found that attitudes toward learning play a large role from a young age.

The most important attitude is a “growth mind-set”: the idea that knowledge comes from trying, learning, and yes, failing at, new things.  

Prof. Cain also references research that our brain makes more and stronger connections after exposure to novelty.  While he presents the research obliquely — as part of a psychology experiment about priming learning attitudes  — my understanding is that there is real neuroscience to support this insight.

I wouldn’t rely on the priming approach solely.  If you believe in priming, whatever you do don’t read this Nature article by Ed Yong on the problems with social science experimental design!

Follow

Get every new post delivered to your Inbox.

Join 1,359 other followers

%d bloggers like this: