Leverage or Perish!

The scenario is an all-too familiar one: meet the Head of Application Development for a multi-billion-dollar revenue firm with global operations. For this account, we shall call him “Mr. Stockbridge” for his territoire includes all software old and new, building, maintaining, upgrading, and further integrating the application portfolio – sometimes referred to as “the app zoo” – as well as R&D, and which is delineated in jovial collegial “Upstairs, Downstairs” manner, literally by a flight of stairs and if by Higher mandate from the realm of his peer, the CTO and “the guys down below” who worry about such seemingly trivial ‘plumbing matters’ as infrastructure, hosting, datacenters, data privacy, overall systems performance and security, etc.

Mr. Stockbridge – a lot less standoffish and snobbish a man than his celluloid namesake, the Marquis acted out to perfection, of course, by the loveable Anthony Andrews opposite the venerable Gordon Jackson – has a problem, a big one, and a hard one as such, but he’s not alone with it (oh, what I meant: unfortunately, he is all alone with his own problem, but other Heads of Application Development at other firms have it, too).

You see, his boss, the company CFO nonetheless (incidentally, in many a corporate hierarchy nowadays a most logical configuration, for whose avuncular fingers are better equipped to clip the wings of Icarus, to curb IT’s flight too close to the sun of techiedom, and to keep in check that otherwise rampant overreaching, overspending, and overpromising that’s supposedly just what ‘we IT guys’ do), has returned from his prolonged budget meeting on Mount Olympus to make the following pronouncement which surprises no one but likewise scares everyone: the current headcount will stay flat until year-end, though an imperceptibly small budget increase for new “specialty” hires has been approved for those projects dear to the CFO’s heart. IT is expected to not only maintain but to increase productivity and project output by an estimated 30% (take that to your next Committee hearing on the “jobless recovery,” Mr. Bernanke). To make matters worse, the technology mix has shifted considerably over the last 12 months thus challenging the ‘skills readiness’ of a good portion of the staff to be able to outperform (if even just to perform) in their present jobs. Plus there are some further hard architectural choices to make (for that global webification push!) that demand more than just the proverbial blood, sweat, and tears – they require the brains of people not distracted by playing perpetual catch-up with that ever-growing backlog of ‘IT business requirements’ dispatched, unfortunately, by those who pay the bills, the business owners. And lest I forget, Mr. Stockbridge, the charismatic new head of Sales & Marketing with that operatic temper (charming only to the colleagues in Italy and Spain) is loudly asking about the new CRM rollout that was promised this quarter (there we go again). The United States Marine Corps has a saying to sum up such rank sentiment: “the beatings will continue until morale improves.”

In fact, I’ve just returned from a visit to Stockbridge’s office-cum-requisite-war-room, a cerebral but no less acute situation desk to make General Petraeus proud – with, surprisingly, no blood on the floor but rather a set of well-thought-out, high-level objectives on the white board:

  • Make do with what we have;
  • Make small changes (that’s all we can afford) that make a big difference;
  • Leverage the existing team (never forget: team motivation is key!);
  • Create an elastic and offshore-leveraged workforce (review local consultant spend vs. a “global flexforce”?);
  • Assess offshore readiness (who on the team can manage in a distributed project environment?);
  • Assess skills gaps in the organization (and how do we bridge them?);
  • Up-skilling / right-sizing / bringing in external help (caution: difficult conversations ahead!);
  • Shorten the path-to-beneficial-use for upgrading internal or importing external “new” skills (if third-parties, whom to trust?; and sorry, no, we cannot afford IBM or Accenture);
  • Centralize solutions portfolio / central hosting / local configuration / create global best practices for deployment (divide and conquer: local vs. global teams);
  • A focused, effective, and realistic approach to upgrading our project management skills to improve outcomes (but please no Greek letters!);
  • Go make it happen!

It won’t come as a mortal shock to my regular readers that the aforementioned white board scenario represents a near-perfect use case for why IT leaders should consider remote staff augmentation. Together with the right remote staffing partner, you will selectively and quickly deploy IT professionals located offshore and manage them as a virtual extension, so to speak, to your own team. Your staff will not panic or lose morale, as you’re not really offshoring entire projects or outsourcing entire functions (and remember the old adage that you should never outsource your problems). These remote IT professionals can either be tasked to maintain legacy code, while your local team can be charged to tackle the new and technically more cutting-edge projects, or vice versa (if perhaps you’re lacking those ‘hot skills,’ such as Ruby on Rails, internally). Furthermore, by having your line managers manage these resources as part of a distributed work team, you will quickly realize improvements – by “gentle necessity,” that is – in project management skills and outcomes, as your people will bring just a little more forethought, discipline, and governance to bear on these distributed projects. No McKinsey, no Six Simga needed.

Good luck, Mr. Stockbridge, who incidentally just called back after somebody had ‘misplaced’ a flipchart of additional “what remote staff augmentation can do for you” notes in his office:

  • Typical savings range from 30-50% compared to the cost of local consultants;
  • Stretch the budget to really do more with less (e.g., eliminate project backlog, improve IT’s responsiveness to business requests);
  • Acquire IT skills that don’t exist in-house or are scarce in the local market;
  • Rapidly deploy IT professionals (individuals or teams) as contractors without additional staff overhead;
  • Handle fluctuations in project demand through “talent on tap” (smoothing out the troughs and valleys in workload while maintaining fixed staff level);
  • Enjoy the direct benefits of going offshore without the hidden costs / risks (no set-up cost, no minimum project size); and
  • It’s a solution that works for companies of all sizes and is viable at any project scale.

The Death of Distance – The Sequel

Call me a techie, something of a science-minded Skeptic who looks upon the ever-growing shelf of self-help titles for the executive set (and aspiring cadre) with a mixture of some bewilderment, little amusement-cum-disdain, and lots of professional jealousy. How come “they” have it and “we in IT” don’t? Meaning the inspired and adapted learnings of history’s greats to better one’s management skills. Just imagine our very own reading list: “Metternich on Winning Over Business Owners,” “George Smith Patton III, the Gatling Gun, and the Importance of IT,” or “À la Bonaparte – Supreme Power to the Little Guy” …

Nothing, however, beats management by Sun Tzu, his 6th century BC The Art of War a timeless classic on military strategy and thought. This enduring treatise which is, of course, shockingly contemporary in parts, stresses the importance of deception, cunning, and spying on others; not doing what you say you’re going to do emerges as the leitmotif, while it offers helpful advice on how to turn spies, punish turncoats, poison wells, and generally deal away with modern-day peasants in feudal lands, speak voiceless underlings. Self-proclaimed Machiavellian corporate strivers and intriguers may be strangely drawn to Il Principe, short enough of a posthumous Renaissance political essay to be digested between cafeteria lunches, where readers will be instructed in the method of acquiring necessary ends by any means, even if they are cruel. Supply chain management (SCM) types will find well-founded solace in being the rightful heirs to no other than Gaius Julius Caesar, partly-Consul and mostly-Dictator of the Roman Republic, his only regret when crossing the Rubicon not having had the SAP BI Platform to help track the dwindling corn supplies which would cripple his Gallic campaign. And finally, if you’ve been too successful a manager, beaten the competition to a pulp, and even your grinning shareholders are worried about your Emotional Intelligence (EI) score, there’s always Hildegard of Bingen to help you get back in touch with your inner Medieval Benedictine abbess, herbalist, poet, and channeller (the lesson there: don’t be afraid of your own success!).

But no, we (in IT) shall have none of that! We prefer such solemn encouragement as “attitude is a little thing that makes a big difference” from noted statesman, gifted orator, and arguably one of the greatest 20th century task masters in a distributed environment, The Right Honourable Sir Winston Churchill. Churchill managed one of the largest physically distributed field operations of his days by a set of rules that are prescriptive for any remote IT engagement:

  • Plan (vigorously);
  • Communicate (constantly);
  • Collaborate (and get the best out of others);
  • Be proactive (and always visible);
  • Govern (keep and refine metrics of success);
  • And, of course, persist (never, never, never give up – remember this is the man who said: “If you’re going through hell, keep going.”).

To optimize outcomes, Churchill was fond of running alternative scenarios, a quick A vs. B “hypothesis testing” for every decision he made. I’ve applied the same method, including some probing questions, for helping us determine an optimal approach for setting up a remote resourcing environment:

  • Captive vs. Non-Captive:
    The benefits of a captive offshore operation are obvious (dedicated resources, significant cost savings after start-up costs are recouped / no middleman, full control / security, quality imprint, in-house culture / communication, in-market sales presence, etc.); but some of the drawbacks may be less obvious (static resourcing / difficulties with right-skilling and load-balancing, dependence on single geography / economy / labor market can mean wage inflation / talent shortage / staff attrition, bench- and lead-time challenges responding to user demand, etc.). What criteria would you use to weigh the benefits/drawbacks of a captive vs. a non-captive offshore operation?
  • “DIY” vs. Managing Vendor:
    Faced with the task of setting up and managing a portfolio of multiple, sequential vendor relations, what ‘value equation’ would persuade you to outsource vs. in-house the management of that portfolio? (E.g., managing-vendor expertise, economies of scale associated with managing the costs of (sequential) vendor discovery, setup, transition, and ongoing coordination, etc.)?
  • Single Partner- vs. Multi-Vendor:
    When considering a non-captive offshore operation, what decision criteria would you use to establish a partner-based vs. a vendor-based approach? (E.g., cost- / risk-sharing, price breaks based on volume, other commitments from a single partner vs. “best-of-breed” every time / breadth and depth, flexibility / no single point of dependence when sourcing from multiple vendors, etc.)
  • Tier-1 vs. Tier-2:
    What is your experience working with tier-1 vs. tier-2 vendors? (E.g., professionalism, process maturity / CMM:5 vs. entrepreneurship, “working with heroes,” etc.). Can you relate to the statement “quality is not a function of size”?
  • Offshore Success – Inhibitors vs. Enablers:
    In your experience, what are some of the key inhibitors (e.g., potential lack of capital, scale, reach, process maturity, ‘hidden costs of offshoring,’ etc.) and enablers (e.g., people, process, technology) to offshoring success? Do effective Service Level Agreements (SLAs) increase the chances of success?
  • India vs. ‘The Rest of the World’:
    Have you had experience resourcing from some of the “other” offshore regions: South America (e.g., Argentina, Brazil), Eastern Europe (e.g., Romania, Ukraine), North Africa/Egypt, Southeast Asia (e.g., Vietnam), China? How would you relate this to your ‘India experience,’ if any, in terms of critical success factors (e.g., quality, flexibility, cost – i.e., is India – with its ~30% staff turnover and ~20% wage inflation – trending after Ireland which priced itself out of the call-center business in the 90s?)?
  • Synchronous vs. Asynchronous:
    What are the key drivers for you to insist on time zone overlap to enable synchronous (e.g., U.S. / South America) vs. asynchronous collaboration (e.g., U.S. / India)? What experience have you had, if any, with more advanced “follow-the-sun” and multiple-shift 24×7 development / support models?
  • Standalone vs. Distributed:
    Have you noticed an increase in complexity managing remote resources as part of a distributed (onsite-offsite) team vs. managing them on a standalone basis?
  • The “Impossible Triangle” of Quality, Flexibility (Availability), and Cost – Tradeoff vs. Optimal:
    Trying to optimize all three dimensions (quality/flexibility/cost – or for project-based work: scope/schedule/cost), how would you prioritize them in order to further drive profitable growth? Furthermore, how important is the “4th” dimension (control)? Does the (relative) importance of control (project management / outcomes ownership) influence your structuring of offshoring engagements: staff augmentation vs. project outsourcing, Time & Materials (T&M) vs. Fixed-Price Contracts?
  • Today vs. Tomorrow:
    Is the impending shortfall in workers and skills (“Talent Shortage/War For Talent”) due to demographics / macroeconomics already impacting your firm? Or, impacting your future resource planning? And, given how technology and globalization are re-shaping both the workplace and the workforce, are you looking at alternate strategies for sourcing and deploying talent (globally, virtually)?

Agile for the Enterprise

What is the difference between a 4-year-old’s birthday party and a seminar on Agile software development? The good news: there is only but one similarity, I’m pleased to assure you, and I’m speaking with the hands-on authority of somebody who just celebrated his daughter’s b-day (in the company of her closest, 20-odd fellow pink-is-my-color-princesses) and also just last week hosted a gathering of an impressive PMO Roundtable in the Midwest. This is the story of having one’s cake and eating it too (in our case, a shockingly elaborate and yes, dominantly pink-colored “Disney Princess” cake) and the PMO’s mandate of managing IT projects at the portfolio level and with annual, upfront budgets while whole-heartedly, and so it would appear, embracing Agile as a way to improve the outcome of aforementioned projects. A contradictio in terminis or simply a meltdown (as experienced when the first guest princess bit into my very own princess’s gateau) of conventions?

In what is to follow, I will be blogging about “Agile for the Enterprise” – a topic that couldn’t be any more topical, as CIO Magazine and Forrester reported only last week as well that “Agile Software Development is Now Mainstream” – and that, my dear reader, is a pronouncement that is making me incredibly nervous … And I will tell you why “Agile for everyone” is making me just a bit uneasy – there are two reasons: first, my company Talent Trust is in the business of helping clients meet their IT staffing needs by provisioning highly skilled IT professionals located offshore. If there’s one thing we’ve all heard about Agile – as even the Rugby term “Scrum” would imply – it’s that teams need to collaborate very closely in so-called “Scrum meetings” – and now I’m selfishly wondering if the world is going all-Agile, what’s going to happen to our remote services business?

My second issue is that many of my clients are PMO Professionals – and now I find myself having admittedly bizarre conversations that go along the following lines: “Sorry, Mr. Client, but you insisted on using Agile, so we’re not going to tell you how much this project is going to cost upfront, but please bring a blank check – not entirely blank, all blank that is but for your CFO’s signature, and yes, I promise you’ll be pleasantly surprised – at least I hope you will – and yes, I very well understand: hope is not a strategy – and, furthermore, if I may, please don’t disturb the artist at work – for software development is now apparently both art and science …” You get the picture.

Of course, I’m just setting the stage for my next blog where I will attempt to tie these themes together for us:

  • There are good reasons why Agile has become mainstream;
  • You can do Agile development with geographically and indeed globally distributed team – which is a fact of life for most enterprises (and hopefully means that I’ll stay in business as well!);
  • And that Agile and the PMO can work together – to potentially achieve better results in software development while conforming to such key concepts as governance, budgets, stage-gates, project management, and so forth – again all elements of how IT is managed within the enterprise.

I will be the discussing the following Agile best practices in the “how-to for the Enterprise” context:

  • How the effort estimation / budgeting process works with Scrum, and how Scrum follows project phases (stage gates);
  • How the Project Management Office (PMO) tracks actual-versus-estimates and measures performance, e.g., by Key Performance Indicator (KPIs) / Key Success Indicators (KSIs);
  • How the partnership with the business owners is established and how their collaborative involvement throughout the project is managed (potentially leading to a better alignment between IT and the business);
  • How IT managers build and deploy effective blended (onshore / offshore) teams, using some Scrum-centric best practices and monitoring tools for working with distributed resources;
  • How onshore and offshore (e.g., Argentina-based) resources collaborate as if they were in the same physical work area, delivering Agile benefits as well as cost savings;
  • How Scrum works with other Software Development Life Cycle (SDLC) approaches.