Two distinct speeds are all the rage, but can you box your operations in? And should you?

One of the most intriguing sections of Deloitte’s new Tech Trends 2016: Innovating in the Digital Era report discussed the right speed for IT. Moving beyond the current, hyped-up two speed approach, the report highlighted speed-related considerations CIOs must take into account: business process-related, architectural, and organizational.

The tension between the need for stability and agility has resulted in the widely recommended two-speed (or bimodal) methodology for IT. “On one side are the predictability and controls necessary to manage risk while delivering large-scale enterprise IT with reliability, scalability, security, etc.,” said the report. “On the other is the push to drive discovery and experimentation around new features, tools, and technologies.”

However, according to Deloitte, in proposing the bimodal theory we may have oversimplified the conflict between these extreme sides. At the same time, we’ve offered little guidance on managing the unavoidable gap between the two priorities.

Many organizations are coming to terms with the idea that different types of business requirements require different speeds and IT must support a continuum. The Deloitte report offered these considerations for CIOs to keep in mind when forming expectations around speed.

Business Process Considerations

Finance management: Budgeting, prioritization, allocations, and accounting treatments all need more flexibility than annual appropriations, rigid planning cycles, and depreciation schedules do. Failure to address the differences in time-consuming finance management processes as part of an overall right-speeding initiative is a missed opportunity.

Procurement and sourcing: Similarly, multi-month RFP processes, drawn-out vendor assessments, and sourcing strategies focused on cost takeout are sometimes appropriate. But they also are not the only game in town. Codify paths to adopt open-source solutions such as platforms, libraries, and code-bases that could jumpstart efforts.

Vendor and contract management: Revisit nondisclosures, intellectual property protection clauses, and traditional segmentation of provider tiers. Consider creating new categories of engagement that can be deployed against efforts beyond simple fixed-scope and traditional service-level agreements. Encourage value-based arrangements where vendors are compensated based on outcomes.

Solution shaping: Beyond determining the recommended end-to-end architecture, ascertain the appropriate speed for a given project or product. Offer the team guardrails as they combine governance, controls, delivery model, enabling processes, and stage gates to balance business impact, technical vision, and risk.

Stakeholder communications and expectation management: Don’t hold back for a large periodic release. Instead, increase the number of releases or user previews to demonstrate progress. Gamify testing and reward members of the user community for providing feedback. Even if these releases are not destined to be put into production immediately, providing users and stakeholders with evidence of tangible progress can make the process seem quicker.

DevOps: Try to determine the granularity of control points, formality of reviews, and the appropriate level of automation that will be needed for the effort. Right-speed IT efforts often coincide with investments in autonomic platforms that can help move more of IT’s underlying workload to labor-free, seamless tasks (or at least introduce automation to eliminate waste in the end-to-end lifecycle).

Architecture Considerations

In order to assess the right speed for IT initiatives, Deloitte recommended CIOs zero in on three main domains: design, master data and integration, and building to run.

Design as a discipline: Emphasize user engagement and a persona-based approach to project delivery. Regardless of speed or mode, solutions should approach problems from the user down, respecting but not being constrained by systems and data implications.

Master data and integration: Designing new capabilities specifically for eventual reuse can help expand the library of APIs and extend the reach of data management efforts. Though expectations will vary based on the size and mode of the project, adherence to existing data and interface standards should be a universal mandate.

Building to run: Embed tools geared toward ongoing monitoring and maintenance of solutions. Instrumentation, management consoles and script, and hooks for in-line monitoring of system and higher-level business performance should be considered. Coverage and granularity of controls need to be able to scale up or down depending on the mode of delivery. But a playbook of potential options, supported by shared libraries and code snippets, will help make adoption systematic.

Organizational Considerations

The third speed consideration involves talent and organizational constructs. Deloitte suggested that changing IT’s reputation as a static, sluggish organization to one that delivers solutions dynamically and at the right speed requires a purposeful focus on four key areas:

Mindset/culture: When it comes to successfully increasing the speed of the processes your IT organization uses to deliver solutions, instilling an engineering culture that emphasizes both accountability and flexibility is critical. Your employees’ mindsets will drive them to learn new ways of working and delivering business value.

Leadership: Culture starts with leaders, and it is shaped by your leaders’ actions and decisions. Leaders can mentor their people to work differently and more flexibly to provide the right project controls and deliver faster.

Talent: Recognize that different personalities and skill sets will be better suited for different IT speeds. This requires a deeper understanding of your talent pool: each individual’s capabilities, passions, aspirations, work styles, and attitudes. Develop learning and development programs to nurture new capability building and knowledge transfer across the organization.

Structure: With their reporting models and career incentives split between the P&Ls and their jobs, IT workers are no strangers to highly matrixed environments. Orienting evaluations and formal feedback around project objectives can help remove confusion and align everyone working together around common goals.

Incentives: Rethink metrics and measurements across the board, from project tracking to individual performance management. Create explicit goals that teams can rally behind, ideally linked to product accomplishments or business outcomes versus tactical behaviors that address empty organizational constructs.