Applying service design processes internally to create a solution that gets people collaborating again

Working end-to-end to facilitate conversations with teams who normally passed documents to one another to surface real opportunities to transform a software development lifecycle

Cross-team documentation process improvement

When a Large National Bank realized they were collapsing under the weight of the documentation and process they had created, I was chosen to lead a cross-functional task-force charged with finding a better way to maintain clear documentation, and react to the proliferation of new devices their software needed to be delivered on.

The Details

The problem


Redundancy, bloat, confusion & the onslought of multiple devices

Pictured here is over 400 pages of documentation to describe TWO SCREENS. Granted, complex screens, but, the same information was in 3 places across 3 documents: something had to change.

Lack of role clarity, siloed processes and teams who had grown away from true collaboration over decades of waterfall process led to documents that described everything and nothing at the same time. Work created by one team was copied and pasted into various other documents, creating massive specs no one could understand. Once team would do another teams work not understanding that the work had already been done; they just didn’t know where to look for it, so they Copied and Pasted and tried to give developers something they could use.

Plus, with the ever increasing number of devices – browsers, phones, tables, watches, possible other devices like cars – the current practices were just not sustainable.

Problem definition workshop


Cross-functional managers identifying project goals

It’s important at this stage for everyone involved to accept that there is a problem worth fixing. It’s going to take work, and the path might get rough at times, and people might get upset, or feel defensive about territory, or be overly invested in how they’ve always done things. That’s why we have to all agree that there IS a problem, WHAT it is, and that we’re committed to solving it.

We brought together managers, and project leads from the Business Analysis group, Project Management, Quality Assurance, Design and Product Management to look at exiting process maps, existing documents from all across the Software Development Lifecycle (SDLC). Each group had a chance to present examples of what had gone wrong on projects in the past and talked about where they were trying to improve their own teams tools, documents and processes. Notes were kept in either a Journey Map style swim-lane where pain points were added or in cross-team parking-lot lists for Process, Tools and Document opportunities

After getting to know each other’s worlds and processes, and having seen the good examples and some needing attention, we broke into 4 teams and each team discussed and drew (at a very high level) 3 things:

  1. what area they thought they could reimagine for maximal gain,
  2. what an optimized document set might look like, and,
  3. what an ultimate process could be if we had no constraints

After lunch we went into the first of two prototyping sessions: to take all the documents that were on the walls, cut them up and reassemble them, including adding (either typed or drawn) new document sections that would help make the best documents.

This was followed by a second, more theoretical, prototype build to describe what processes or tools would be needed to make the new, optimized document possible.

Ethnographic research


Direct observation of individual contributors fosters insights

I shadowed Designers, Business Analysts, Content Strategists, CMS Authors, Quality Assurance Engineers, Developers, Technical Architects, Project Managers and Product Managers. We watched how they created and consumed documents, gathered information, made decisions, found answers to questions.

I sat with them at their desks and joined them on project conference calls. We watched how they captured information they needed, filed it, stored it, printed it, marked it up with colored pens and hiliters and stuck had drawn notes and PostIts on it. I noted the different systems, web sites, tools and apps they had to go through to get their work done.

These observations helped form a set of questions that drove the next research activity, the Document Journey Map

Process mapping


27 Subject Matter Experts teach us about their reality

I interviewed over two dozen developers, business analysts, product managers, customer experience designers and content authors to map on a timeline of the Software Development Lifecycle (SDLC)  the documents they handled, used and created. We discovered where they got them, what worked, what didn’t, what they had to do with them and where they stored them. We also had them map out the rest of the documents not in their direct control but which they were comfortable mapping.

On a timeline of the SDLC we mapped on color coded labels 1) what the document was, 2) who created it and 3) what tool or system was it made with/in. We captured commentary and verbatim on video and in notes as to the efficacy of each document, each translation step and the work involved.

In a post interview survey once we had broken each teams work into a process we asked about 1) job satisfaction and 2) confidence that the work could be repeated and 3) confidence that the output of each step was giving the next process step the inputs it needed to do its job correctly.

External research partner engagement


We brought in a prominent industry research firm to benchmark peers facing similar challenges

The task-force wanted to know if other industry leaders in software delivery were having similar struggles, and how they were adapting to the challenges. We engaged Forrester Consulting to conduct an industry study where they would interview both other financial institutions and similarly sized technical organizations in other industries such as Telecommunications and Retail.

Synthesis, pilot and recomendation


Three simultaneous pilots, and exhaustive synthesis of the inputs led us to a recommendation for group collaboration and a new method of shared documentation

We had good ideas as to how to proceed, but we wanted some validation. We had multiple project teams at working on projects of different levels of complexity try three different methods, allowing for real-time adjustments where they found our recommendations lacking. These real-life innovations were the kind of shape our recommendations needed to add detail and reality to process hypothesis.

Based on those pilots, we codified what we could including a guideline for successful project collaboration and a definition for what deliverables should document what aspects of each design element – from requirements through final code. This included behavioral aspects, functional details, accessibility requirements and most importantly, the needed traceability, or association of design components between the documents.

Visual training guides


A series of illustrated presentations explained the new processes step by step and added detail where needed for different teams

Process work is dense. Process improvement is tedious. There’s no way around that. There are unimagined details and every time you “peel back the onion” there are more inter-related details waiting for explanation.

To simplify this so working teams could absorb the value of the new ways of working, new, more interpersonal collaboration episodes, so teams could learn this new dance, we created succinct, clear diagrams of when teams should come together to do join work, and when they should separate to do discipline specific work. The activities and outcomes were in keeping with a new trend of inter-team collaboration and transparency. Not handoffs, but reliance on team work and shared information.

These ways of working, reminiscent of how smaller, highly functioning teams of software developers work have paved the way towards an adoption of new more agile methods across the organizations Software Development Lifecycle.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.