Maximize the Minimal – Minimally Viable Deliverables

Massive project schedule and cost over runs. Impossible deadlines to complete a strict set of templates. Cookie cutter project deliverables. No one said being a Business Analyst was going to be easy. Being required to produce documents that create massive information bloat and don’t add value is frustrating as it slow projects down and creates additional project cost that isn’t needed. It’s a headache for Project Manager, Business Analyst and everyone on the team. What information or deliverables do we really need for the project but that won’t bury us in information overload.

What we need is the smallest set of information that can be verified and validated quickly that directly ensures the highest quality outcome of the project. So why does minimally viable even matter. We need Minimally Viable Deliverables.

What is minimally viable? Typically, you will hear minimally viable in reference to products – not project deliverables. 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? 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 but simply filling out a form doesn’t replace good critical thinking and analysis. Use templates as a starting point and add any additional topics or information needed to ensure a comprehensive understanding.

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 (or audience) to understand what they require for documentation and communication. Review documentation and communication planning carefully and set expectations on the content of deliverables with your customer (or audience) prior to delivery.

Building communication – gain agreement on deliverable communication needs and deliver consistently. Doing what you say you will do builds trust and makes future communication easier. Weekly communication should be delivered the same time on the same time as it builds consistency.

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. Dumping large amounts of information and can result in the communication being ignored because it’s too complex to handle easily.

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. Be prepared to add, modify and delete as needed for the project to keep the communication clear.

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.