Documentation Overload
This week was clean your computer day. Conveniently scheduled the day before Valentine's Day. Apparently all effort must be redirected to shredding documents before any true romantic wine and dine experiences can begin. So I decided to check out the files on my laptop and network drive to see what could be cleaned up. After playing Indiana Jones for an hour or so, I got to thinking about all the documentation created for our projects.
As part of the lean methodology, we throw around the words "Minimally Viable" when talking about releases of our product. Should it apply to documentation as well?
But let's step back a moment, what is minimally viable? Typically, you will hear minimally viable in reference to products – not project deliverables or documents. A minimum viable product has only the core features that allow the product to be deployed, and no more. It’s a strategy targeted at avoiding building products that customers do not want. "The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." [Source: Ries, Eric (August 3, 2009). "Minimum Viable Product: a guide"].
Well that’s handy information but how does it relate to project deliverables and documents? For that we need to adjust the definition so it makes sense in terms of project deliverables. So let’s flip it around a bit “what is the minimal amount of information and documentation needed to ensure the maximum amount of communication and learning for unambiguous and clear communication throughout the project?”
Use of the words maximum and minimum means it is decidedly not formulaic or predetermined and requires judgement and analysis to set those boundaries. More on that in a bit.
Although this is sounding project manager focused, it’s important for the business analyst and all team members to consider this concept. For most projects the answer is “we typically do these types of documents”. In a few cases all you get is a checklist with a list of documents that need to be completed. A better way is to create a common understanding of what is needed for each team member, stakeholders and sponsors. That means eliciting their requirements on the documentation and data they need to be successful on the project.
A while ago I was engaged on a project for a website upgrade. The project was critical for re-branding the company. I wrote up a significant amount of documentation on every element that was needed on each page and felt I had all my bases covered. I then presented it to the web developer in a meeting. His response? “I don’t value reading”. Okay so my jaw hit the floor. So this guy is illiterate? I asked what was wrong with what I provided. The developer responded back, “You didn’t ask how I needed the information. This is great but everyone in user interface design is visually oriented”. He went on to explain that they learn and develop faster with visual references. A part from loving pictures, I further learned they preferred to ask simple questions in instant messaging and longer more complex questions in face to face meetings.
As you can image that was a tough meeting. I returned with the minimally viable deliverables (or document). I made sure I was always on IM – those user interface guys type damn fast on IM. We had several meetings face to face on more complicated issues. I applied that same level of analysis to the DBAs, Architects, Quality Assurance, Project Manager, Stakeholders and Sponsors. What is the minimum that they personally needed? How should I best communicate with them?
Each of these team member had specific needs from documentation. Quality needed a requirements traceability matrix to ensure no requirements were missed in the development. Stakeholders needed process flows for the new processes and training to make sure their team was on board day one with the new system. The developer wanted wire frames and an info graphic to understand the scope – perfect. As a business analyst you have a tool box full of techniques that you can use to be minimally viable.
Stop being a template zombie. Filling out a form isn’t what makes a project successful. Yes organizations require certain types of documents for legal or regulatory reasons.
Define the boundaries of the product or project before setting minimally viable deliverables. It’s difficult to determine the minimum amount of deliverables needed when the entire scope or context of the project is not understood at a high level. If you have no clue as to what the project will be producing, it’s hard to figure out minimally viable deliverables. Here’s a few other considerations:
Know your customer and audience to understand what they require and set expectations on the content of deliverables.
Building communication – gain agreement on deliverable content needs and deliver consistently. Doing what you say you will do builds trust and makes future communication easier.
Deliver the communication in chunks to avoid an information tidal wave. Human beings need time to digest and figure out what questions to ask next.
Change is coming – as the project moves forward expectations of minimally viable deliverables changes. Be alert and on the look out to adjust your deliverables to meet project team member needs.
Going against the “cookie cutter” or “these deliverables fit all projects” thinking is tough. Applying this on a small scale. Even as small as requesting a variance to a template, “I don’t know if this section of the document makes sense for our project” to as large as building a best practice for certain types of projects – such as all new campaigns on the CRM system should consider using these deliverables.