Balancing outsourcing with Agile development
- 15 April, 2015 16:07
The ‘keeping mum effect’, or reluctance to report bad news about a distressed project, is alive and well in our time-compressed, competitive, uncompromising and globalised business environments.
Learning from the mistakes of others on the Agile journey can be a valuable exercise, however many project failures do not make the light of day for a range of reasons. These include job preservation, the risk to organisational reputation and brand damage, and adverse impacts on the company’s stock price.
Troubled projects, unless they hit the media or end up in legal proceedings, are likely to remain obscured, while project successes are actively promoted by organisations, as well as the vendors that had a part to play in that success.
Managing an Agile project that involves an ecosystem of vendors presents its own unique set of challenges, too.
Yet the ultimate success of the overall project may have less to do with technical competencies or intrinsic capabilities of individual vendors, and more to do with:
- The quality and value placed on the intrinsic relationship between IT and your organisation (being a peer to the business, not a subservient cost centre);
- Having a clearly articulated locus of accountabilities for your vendors and your own teams;
- Not underestimating the demands on team members by managing across diverse time zones and cultures;
- Maintaining a healthy, cohesive team that clearly understands common goals, irrespective of whether the team members are from your organisation, the vendor or elsewhere;
- Ensuring that the intent and experience of both the vendor and your organisation on any Agile initiatives are clearly understood;
- Developing a common set of values and expected demonstrated behaviours between the various teams, as well as;
- Effective diligence in vendor selection. Engaging a vendor whose staffing strategy is based on a revolving door of short-term contractors, or who ships the work out the back door to other providers, may just be your first mistake.
When the pressure is on, and cracks start to form in your Agile project, if the perceived responsibility for failure lies with any vendor, this increases the probability of your staff reporting the bad news upwards, rather than resolving the issue within the Agile process itself.
This has a potentially corrosive influence on the bonds of trust underpinning any high-performing, multi-sourced Agile environment, and may push your vendor relationship down the ‘blame-game’ and adversarial path.
Adding to this mix, vendor contracts that are poorly structured and positioned along conventional aspects such as technical specifications, deliverables, roadmaps, outcomes and penalties may wind up the Achilles heel to any multi-sourced Agile project.
If the contract’s intent and terms are not in line with the expectations of operating within a somewhat less predictable Agile environment, you could, in fact, be setting the vendor (and your project) up to fail well before you start.
The big question therefore is: What measures are you going to put in place around your Agile project to ensure your sprints do not result in your project being run as a badly coordinated three-legged race?
Rob Livingstone is a respected CIO with more than three decades of industry and ICT experience, the last half as a CIO with several multinationals, most recently Ricoh. He is the owner of Rob Livingstone Advisory and a fellow of the University of Technology, Sydney. Rob delivers the Pathways Advanced and Business ICT Leadership programs in conjunction with the CIO Executive Council.