This is the third and final part in a multi-part post inspired by
Robert Pirsig’smasterwork,
Zen and the Art of Motorcycle Maintenance. In
Part 1 (titled “Reflections on ‘Zen and the Art of Motorcycle Maintenance’ 38 Years Later “) I discussed the implications for IT professionals of Pirsig’s musings on ‘classic’ versus ‘romantic’ worldviews, and his struggle to resolve these.
In Part 2, (titled “Zen, Motorcycle Maintenance,
Design Thinking and Information Technology”) I teed up my observation that this classic-romantic balanced approach is embodied in the “
design thinking” movement, popularized by
Tim Brown and
Ideoand exemplified by companies as diverse as
Apple,
Proctor & Gamble,
Herman Millerand
GE. I discussed why Design Thinking is becoming increasingly important to the IT profession. Among the reasons for the rising importance of Design Thinking in IT:
- Thanks to the likes of SAP, Oracle, et al, and the growing base of cloud-based ‘applications as a service,’ most of the opportunities to improve or automate transactional business processes have been exploited. Today, businesses are increasingly searching for product, service and business model innovation.
- As we accelerate the move from custom development to personal apps, reuse, and “mash-ups,” much more emphasis is placed on synthesis rather than analysis – leveraging widgets and components rather than coding solutions from scratch.
I will pick up in this final part where I closed Part 2, with a discussion of three roles that are key to instilling Design Thinking in an IT organization.
Key Roles for Design Thinking in IT
Achieving the classic-romantic balance in discovery and solutioning involves many IT roles, but there are three roles that I believe are key:
Roles – Not Necessarily Jobs!
Before we examine these roles and how they work together, I want to emphasize I am talking about roles, as opposed to jobs. The distinction is important in that the notion of organizing around roles imparts flexibility and variety for a workforce, whereas jobstend to constrain people in boundaries defined in job descriptions. An individual typically will hold only one job, but may fill multiple roles. For example, my job is Principal in a consulting firm. In some engagements, I am the Engagement Lead. In others, I might be a Subject Matter Expert. In still others, I am the Client Relationship Officer. Beyond engagements, I might be a Research Program Leader or a Research Associate.
Also, these roles are typically instantiated with all sorts of labels – rarely the label I’m using here. For example, I’ve worked with Business Relationship Managers (BRM’s) who were called Business Partner Director, Account Manager, Client Relationship Manager, IT Business Partner, Business IT Partner, IT Demand and Account Manager, Client Engagement Director, and so on! And the specific missions, visions and implementations of the BRM role has been as varied as their titles!
Nevertheless, let’s drill into these roles and how they relate to each other and to moving IT to more of a Design Thinking philosophy.
Business Relationship Manager
I’ve posted extensively on this role in the past – it’s the role that sits between the IT organization and its business clients. As such, it both represents the business clients to IT, and IT to the business clients. This role has surfaced over the last 10 years or so. I don’t know what percentage of IT organizations have this role today, but as an indication, LinkedIn hosts 2 groups dedicated to the role. One group –
IT Business Relationship Management - currently boasts over 1,800 members. The other group,
Professional Business Relationship Managers currently has over 2,600 members! (In the interests of full disclosure, I co-manage the latter group.)
As the bridge between the business and the IT organization(s), the BRM plays a key role in moving above and beyond the traditional “requirements analysis” to an approach to discovery and solutioning that is more:
- collaborative
- abductive
- experimental
- integrative
- outside-in
- human-centric
- innovation-biased approach
As such, the BRM has to understand Design Thinking, and ensure that the qualities listed above are brought to the table and play together effectively and efficiently. The BRM herself does not have to be expert in these qualities, but must be an effective “broker” ensuring that people with the needed competencies and incentives are at the table. These competencies will often be found in the other two emerging roles – those of Enterprise Architect and Product Manager.
Enterprise Architect
As with BRM’s, Enterprise Architects (EA’s) come in all sorts of flavors with a variety of titles. The major distinction I would make is with what are generally called IT Architects. Enterprise Architects are clearly focused on the business, business models, major business processes, business-IT platforms and the ecosystem within which the business operates. IT Architects, by contrast, are focused on the technologies, their standards and how they inter-operate.
… the process of translating business vision and strategy into effective enterprise change by creating, communicating and improving the key requirements, principles and models that describe the enterprise’s future state and enable its evolution.
Practitioners of EA call themselves enterprise architects. An enterprise architect is a person responsible for performing this complex analysis of business structure and processes and is often called upon to draw conclusions from the information collected. By producing this understanding, architects are attempting to address the goals of Enterprise Architecture: Effectiveness, Efficiency, Agility, and Durability.
As with BRM’s, the EA role has been growing in prominence over the last 10 years or so. Typically, it is complementary to the more technical roles of IT Architect, Information Architect, and so on. Also, as with BRM’s there is little that is ‘standardized’ about the EA role, and by many measures it is something of a stretch to use the term “profession” when talking about EA’s, in spite of the efforts of bodies such as
The Open Group Architecture Framework (TOGAF®), and my old friend,
John Zachman and his
Zachman Framework for Enterprise Architectures.
Again, as with BRM’s, LinkedIn is home to an
Enterprise Architecture Network, with an astounding 85,000+ members! As an example of the passion exhibited by this group, a recent comment that stated, “EA is often left in IT because it can only handle tame problems” garnered 572 comments!
At its best, the EA helps bring to the business-IT discovery and solutioning table some of the competencies from my bulleted list above.
Product Manager
The third role in the triad that can help IT organizations introduce more Design Thinking into their activities is that of Product Manager. This role is far more scarce in IT organizations than either BRM or EA. It is, however, universal in product companies, including information technology product companies.
Wikipedia defines Product Management as:
…an organizational lifecycle function within a company dealing with the planning, forecasting, or marketing of a product or products at all stages of the product lifecycle.
The role consists of product development and product marketing, which are different (yet complementary) efforts, with the objective of maximizing sales revenues, market share, and profit margins. The product manager is often responsible for analyzing market conditions and defining features or functions of a product. The role of product management spans many activities from strategic to tactical and varies based on the organizational structure of the company.
While involved with the entire product lifecycle, the product management’s main focus is on driving new product development. According to the Product Development and Management Association (PDMA), superior and differentiated new products — ones that deliver unique benefits and superior value to the customer — is the number one driver of success and product profitability.
Of particular note, Wikipedia goes on to note that:
Product management often serves an inter-disciplinary role, bridging gaps within the company between teams of different expertise, most notably between engineering-oriented teams and commercially oriented teams. For example, product managers often translate business objectives set for a product by Marketing or Sales into engineering requirements. Conversely they may work to explain the capabilities and limitations of the finished product back to Marketing and Sales. (Emphasis added.)
The Design Thinking Triumvirate
So, the keys to getting more Design Thinking into Business-IT solutions lies in the triumvirate of Business Relationship Manager, Enterprise Architect and Product Manager, with the BRM as the broker and orchestrator of these roles. There are, of course, other roles played – e.g., business analyst, project manager, program manager, and so on, but I wanted here to focus on those roles which are less common but in the ascendancy.
