Technology plays an incredibly important role in the idea economy, where business innovation is dependent on the software that powers the business. Speed and agility in IT are key to a competitive advantage in this modern economy, in which small startups with disruptive ideas are competing with well-established enterprises and industries. Consider how Uber and Airbnb are challenging taxis, rental car companies and hotels, all based on the power of an idea and software. Yet, traditional enterprise IT struggles to deliver at the speed business demands.

Have you ever heard a business leader say, “Our IT teams are extremely responsive and very fast”? The typical response is quite the opposite. IT is commonly viewed as a bottleneck to business innovation and, in many organizations, the business simply avoids IT and instead creates some form of shadow IT.

Step 1 of 7

14%

Which of the following best describes how you currently monitor and manage systems across your hybrid cloud environment?(Required)

Multiple separate tools for different environments

Multiple separate tools for different monitoring and management functions

Single consolidated dashboard

Custom built monitoring and management solution

No full monitoring and management solution

Don’t know

How valuable would it be for your monitoring and management solution to incorporate predictive analytics to help you identify and address system issues that are critical and not waste time or effort working through all the data and “noise” that is not critical?(Required)

Extremely valuable

Moderately valuable

Somewhat valuable

Slightly valuable

Not valuable

How do you most typically address potential system issues BEFORE they impact your operations?(Required)

Automated workflows and playbooks to remediate potential issues as soon as they are detected

An orchestrated response process that leverages automation, AI, and human expertise to rapidly respond to potential issues

Advanced monitoring tools such as predictive analytics and anomaly detection to proactively identify and address potential issues

Respond to issues as they arise, using manual processes and troubleshooting techniques

A combination of automated remediation, orchestrated response, and/or proactive monitoring to address potential system issues

Don’t know

Other

What methods does your organization use to control and monitor cloud/IT spending?(Required)

Centralized procurement processes

Pre-approved budget thresholds

Automated cost monitoring tools

Department-level spending controls

Regular cost audits and reviews

Cloud cost optimization platform

Approval workflows for resource provisioning

Native financial operations tools provided by the cloud provider

No formal controls in place

Don’t know

Other

Please specify:

Which methods do you rely on most to detect security vulnerabilities in your systems?(Required)

Automated scanning tools

Manual assessments

Vendor notifications

Threat modeling (for early detection)

None of these

Don’t know

Other

Please specify:

What are the TWO most common ways you prioritize vulnerabilities to address within your environment?(Required)

Based on potential impact

Based on exploitability

Regulatory compliance requirements

Based on CVSS scores

Risk-based analysis of multiple factors

First-in-first-out approach

No formal prioritization process

Don’t know

How do you typically handle system updates and security patches?(Required)

Automated updates and patches

Manually review and apply updates and patches on a regular schedule

A combination of automation and manual review

Apply updates and patches on an as-needed basis.

Outsourced update and patch management

No defined process

Don’t know

Other

Δ

IT Governance, the Old Way

The principles and practices of DevOps creates the potential for faster delivery and higher quality. However, one of the largest sources of friction is the traditional focus on IT projects and project governance. Consider this definition of a project from the Project Management Institute:

“A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who don’t usually work together – sometimes from different organizations and across multiple geographies.”

Given that projects can be expensive investments, and because of limited resources, enterprises justifiably carefully prioritize and plan which ideas and initiatives should be approved.

Faced with limited resources, enterprises expend significant effort to prioritize, optimize and fund only the most important projects. But no matter how well-intended, this governance approach also struggles to respond to the speed and velocity required in the idea economy. Indeed, the typical portfolio-planning and project-management approach is often an underlying cause of dysfunctional IT behaviors such as excessive requirements, throw-it-over-the-wall deployments and questionable quality—none of which are pleasant.

Consider how the business approaches user stories and requirements management. In a traditional, project-driven world in which the project is a one-time opportunity, businesses often are given an exhaustive list of ‘must have’ features in their user stories. This behavior is understandable—given the ‘feast or famine’ nature project, funding businesses need to make sure their future needs are included, even if the need isn’t immediate.

Sadly, this introduces both technical debt and excess complexity from the very beginning. Especially, when you consider that only a fraction of those ‘must have’ requirements will ever be actually used. In fact, a recent IEEE paper noted that 28 percent to 45 percent of software features often go unused.

Consider how “project success” is typically measured. Project teams typically are evaluated on their ability to deliver on time and on budget, along with other various quality and satisfaction measures. The emphasis on schedule and cost can drive sub-optimal decisions, as deadlines and cost pressures loom. As a result, testing is often abbreviated, as the schedule compresses. Sometimes the scope is reduced to conform to the deadline. This routinely leads to challenged releases in which the service desk is left holding the bag, which ultimately degrades trust and teamwork.

After the project is completed, the project team often redeploys to other projects, depending on demand for specific skills. The accumulated knowledge and wisdom of the team is lost and there is no further incentive to invest in automation or process improvements because the team has disbanded.

The DevOps Shift

DevOps is a very different approach that requires rethinking how work is funded and governed. Fundamentally, a DevOps team is charged with delivering small, high-quality releases, very quickly. The team embraces fast feedback to remove bottlenecks and waste and utilizes relentless automation to make tasks repeatable and efficient. Given that the team will deliver dozens or more releases per year, it is incentivized very differently from the traditional “project” team. The DevOps team often “owns” the application in Development, Test and Production, and has a shared accountability for the value it delivers. The team reduces handoffs and delays and implement small, frequent changes in response to business demand, customer feedback and system performance.

The friction of traditional governance needs to be addressed using DevOps to enable the enterprise to thrive. One of the ways to remove the governance friction is a paradigm shift from projects as described above to products. It is vital to focus on value and business results along with employee and customer satisfaction. The key difference is that a product is funded for the long haul:

• A product team delivers ongoing value and the business can count on improvements to meet market demand.
• A product team does not form and disband depending on funding.
• A product team is focused on delivering value through the product and will naturally enhance and improve their processes. CIOs and senior leaders need to consider using the Product model as an alternative way to fund and govern their initiatives.

I’ve talked with several IT leaders who are exploring how to evolve the concept of the traditional project toward a longer-term product orientation. Some organizations explicitly make the change to products, and others are taking a more evolutionary approach. Regardless of the path, the need to evolve the funding model is clear.

Consider how product governance is different from projects. The product team, in partnership with the business, is funded for a sufficient period of time (year, half-year, perhaps quarter) depending on the business needs. The product team then delivers fast releases of business-driven innovation and rapidly updates the system based on feedback from continuously assessing the product. As the team remains intact, it is able to learn and improve while also accelerating delivery. Additionally, because the product team is able to deliver quickly, the incentive to overload releases with “nice to have” features is greatly reduced.

Here’s how the mindset is different:

Project                                                                         Product

Short time frame                                                   Long term commitment

Limited funding                                                     Predictable funding over time

Team disbands                                                      Team owns the product and results

No incentive to automate                                   Automation improves quality and speed

Incentives based on schedule/budget            Incentives based business value

This does not mean there won’t be projects in the future, but there will be a combination of products and projects in most large enterprises. Most likely, we will see projects will be the way new products are proposed, evaluated and conceived. However, once the product is launched, the product team then will operate under a product model and mindset.

About the Author/John Jeremiah

John Jeremiah leads the Digital Research Team with the HP Software Applications Delivery Management team. He is a software professional with over 20 years of experience including a variety of leadership roles with the U.S. Navy, IT consulting and Fortune 500 IT organizations. His previous roles span from application developer, project and program manager, Director of Testing Services, and Delivery Process and Methodology Director. Prior to joining HP, he was director of Testing Services and Project Delivery Services for Thrivent Financial for Lutherans, where he led the adoption of CMMI Maturity Level 3 process framework.