Some of my thoughts on how that role might play in IT Service companies.

IT service companies have matured their offerings in last few decades. Types of the projects they handled have grown from BPO operations for noncritical processes to business critical solutions being delivered.

The value the service they are delivering thru consulting for both IT and business are helping clients improve business efficiency. The IT Talent now has a deeper knowledge of core domain of the customers business, apart from technology know how.

The service companies have long and mature relations with the customer organizations. Earlier we assumed that customers ‘Know what they exactly want’ and consultants could respond to the ‘Request for proposal’ was the mandate. A problem with that model is by the time the solution is developed the business needs would have changed, and at times, millions of dollars worth solutions do not remain relevant at the time of delivery.

Companies should change their approach from ‘Give me a problem and we will build a solution’ to ‘We know your business pain areas, and this is what we propose as a way forward’ Model. In this new paradigm, consultants do not make big plans, instead, engage few bright resources, quickly build One select feature, test, deploy, and slowly increase functionality as required.

Today no one wants to invest in multi-million dollar rigid and monolithic solutions. Instead, quick responses to solve smaller pain points of users and at times integration of appropriate tools to get the clients started with bare minimum functionality and then slowly add more features to the solution makes sense. Sometimes change course or scrap early pilot solutions, constantly recalibrate and iterate scope of the projects.

This agility of the development process combined with the business understanding and more importantly user understanding are evidently required to achieve the above.

The role of Chief Design Officer in a service./ consulting company might have to be slightly different. (This is just my thoughts)

One main difference, I think would be Domain knowledge:

A CDO in a product company might acquire deep knowledge of the organization’s domain being a full-time employee. But for a service company design professionals need to acquire the domain knowledge or partner with appropriate stakeholders throughout the life cycle of projects. Subject matter champions will need to be included in the projects.

CDO will have to take an additional responsibility of establishing tools and mechanisms to quickly ramp up the ‘design team’ on the domain of customers. Some of these tools could be simple questionnaires or process templates.

CDO Responsibilities in IT Service company

1) Establish pain points of the users [Product manager kind of role]

CDO would be far more valuable in establishing what needs to be developed, to address specific pain points of target users. Having a rock start User research team and empowering them with robust processes of establishing identifying and prioritizing pain points of users will be very useful. The CDO team should practically play the role of a ‘Product manager’ for the projects. [this role typically I have seen missing in service companies. most of the teams have ‘Business Analyst’ who does partially a similar job, but CDO office should have some ‘Product management skills’ in their team, who could establish, & prioritize the project scope if customers have not already done.

2) Robust and Flexible design process:

CDO should define User Centered Design process which is flexible (and modular) enough to be molded for a variety of projects. The process needs to be aligned with different development processes those are engaged. Aligning the Standard design UCD process for Waterfall, Agile, RUP, and any variations the same is one of the toughest challenges the design strategy leader might face.

Instead of a rigid design process, mentor the design team to be little agile would help. Though process templates may evolve based on the type of projects; for example, UX process for the web portal, etc.

CDO office should define the design strategy for types of design projects. defining and enforcing ‘Design policy‘ for the type of projects.

3) Exposure to latest UI technologies

Building fixed design guidelines, or pattern libraries for ALL projects may not be feasible just because of the variety of projects, technologies, teams, and even requirements. Having a good understanding of latest UI technologies, frameworks, would be crucial here. I would suggest, the front end development team should roll up into the CDO so that the Design and UI implementation are entirely owned by the Design teams.

4) CDO in service industry should define and own ‘Design quality metrics‘ for ALL projects:

CDO should be empowered to STOP a delivery of a project on the grounds of ‘Bad quality Design, or Bad UI implementation. Defining design quality metrics could be difficult based on sheer variety and speed of projects, but I think, governing the design quality is one of the primary tasks for CDO

5) CDO should have an ability to see the BIG PICTURE :

CDO office could be involved in scoping for the ‘complete’ experience and not just designing one portal. for example, if the team is designing a CRM system for a customer, trying to establish and influence the design of the other customer touch points, (Like the Support portal for that matter.)

This ability would make the CDO office an integral part of the solution, and customer facing teams.

6) CDO should plan to induce design sensitivity and Design thinking in every department of the organization. and at times should be doing hands-on workshops for establishing the appropriateness of solutions with the customer organizations.

7) The organizational structure for the CDO office.

There could be a number of approaches here,

First option: A centralized CDO office having a core team of design strategists, Design process experts, Thinkers, UX architects User researchers would make a lot of sense. The centralized CDO office could, in turn, govern different smaller design departments which might be owned by different business units, each being lead by a Design department head.

Second option : A completely centralized design team reporting into a CDO, here practically all ‘design projects are owned by the CDO

Responsibilities of a DCO in a service company need to evolve based on the organization and culture of the parent organization. anyways, the ability to see the BIG picture, and ability to communicate with the key decision makers from the customer organizations will make the DCO role much more valuable to service companies. Frankly, the C-level executives from the customer organizations would love talking to a design strategist to establish what needs to be developed rather than discussing with a business analyst.