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 “separate yet connected” set of documents we designed allowed teams to work on what they knew best and kept a single point of authority for each documentation chunk needed, without a bunch of Copying and Pasting. The resulting confidence that people had in the quality of the document they used resulted in 80% reduction in project ramp up time and 70% less ambiguities during build phase.
It was decided early on that going after small improvements in individual team methods was not going to net an improvement and that we needed to look across several teams work flows to find opportunities for streamlining.
By using research methods that focused on the real people doing the work we identified the things people were already doing to make up for inefficiencies in the established processes. By focusing on places where the process was working already and finding ways to do more of that, and we used ideas people had been wanting to adopt for years.
It turns out (no surprise) people like talking, and working together, and everyone was frustrated with the waterfall process of “throwing documents over the wall”. By orchestrating teams to work more closely earlier in the process, we were able to get teams to avoid defects by testing assumptions earlier when risk is less.
Establishing clear ownership of documents, criteria for completion, and ways to connect multiple documents that were no longer aggregated into a monolithic super-spec, we established a clear path to the truth for requirements while fostering a greater sense of ownership in the creators of the documents.
As teams had grown apart following a waterfall methodology, documentation had grown unwieldy as groups would demand more and more precision from document providers to try to avoid defects later on. It wasn’t uncommon for there to be 100 pages of documentation or more to document a single screen of functionality, and those specifications frequently had errors based on them being aggregations of multiple teams into single massive documents.
To make matters worse, with new devices being developed for, the need was multiplying as projects launched in overlapping releases in an integrated release cycle typical of waterfall processes used in large corporate environments.
Management knew there needed to be a solution but attempts in the past had focused on iterative process enhancements and more reviews or “governance” and no matter what they tried people would either fall back into old ways or find ways to avoid the process. They knew there needed to be a cultural change and that takes looking at every touchpoint in the process, getting people to contribute and buy in to the ideas, and good training and change agency to ensure adoption and reap the improvement they knew then needed.
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.
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:
what area they thought they could reimagine for maximal gain,
what an optimized document set might look like, and,
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.
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
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.