Articles

Innovate or die. That is the mantra of successful organizations that compete in a fast-transforming digital world. Those who harness social media, mobile, analytics, cloud computing, and Internet of things (SMACT) to digitize the business win in the marketplace. Those who don’t, lose. It is a wild, wild digital world out there.

Business architects embedded in successful organizations need to innovate as well or lose relevance. The world where business architecture matters has changed. Old paradigms give way to the new. One area that needs rethinking is how business architects define a business capability.

The "Big Picture Thinker" and the "Aspiring Developer"

Every Agile team has experienced the frustration of working with a Product Owner who is very well intentioned but unable to provide the clear requirements that the team needs to build the most valuable business solution.

This is the first of two articles that address the specific challenges that you may be facing (or will most likely face) in your work with Product Owners. In this article, the focus is on two of the most common types of challenging Product Owners: The "Big Picture Thinker" and the "Aspiring Developer."

The "Big Picture Thinker" Product Owner is an epic thinker, able to give the Agile team a high level description of their requirements but unable to describe (or to decide on) specific system behavior. Their inability to provide the team with adequate detail could be due to several factors, including their limited depth of knowledge and their fear of being responsible for decisions.

At a recent engagement, I encountered several departments that asked me to help write their departmental policy on a particular subject. When I inquired as to the governance process for changing existing company policy, they looked at me blankly and said no, I didn’t understand – they needed a new policy, just for their department. After a little probing into the governance of their company policy (this enterprise had a single policy covering everything), and some further discussion, we ultimately settled on writing a new procedure and developing accompanying forms and workflows. I ended up helping this department rewrite their documents into the appropriate format, and working with them to better understand the hierarchy.

This got me to reflecting on how many times in my career I’ve heard confusion about policies, standards, procedures, and guidelines. Reasonable people will differ in their definitions, but here’s how I understand them to work best.

Is your improvement project failing? Depending upon which study you reference, roughly two thirds of projects fail to produce their promised outcomes. Such failures result in a tremendous waste of resources and even more unfortunately - lost opportunities to seize advantage over competitors. Looking deeper, we often find failure is almost preordained. Projects are pushed out of the chute armed with confusing directives and inadequate resources. Once a team is assigned to address an opportunity, invariably the first task is to translate leadership intentions into a realistic deliverable. Such translations can be overly challenging to make. In the name of expediency, project teams are routinely asked to run out on the ice before strapping on their ice cleats. Without stable footing, epitomized by a well-defined mission and clear field instructions, they lack the foundational necessities to hit the ground running.