Save THOUSANDS on your next interactive project with this one easy trick

But what about…

The only documents that get useful feedback:

Charters, Charts, & Wireframes, all short, all written to an 8th grade reading level, & visually focused.

These documents facilitate empathy because they encode their message to fit the human condition.  The Charter sets the boundaries & goals.  Charts are the most efficient way to gain both a high level overview of business processes and granular details.  Wireframes, add a distraction free user interface to focus the discussion on accomplishing the charter’s goals as described in the charts.   The ease and efficiency of these documents radically improves the quantity and quality of stakeholder engagement.

Conversely, I’ve written some outstanding scope of work documents, but I’ve rarely gotten meaningful feedback from them.  So why write them?  Well contracts are why.  I don’t know of a development, creative, or marketing shop, especially independent contractors, that have NOT been ripped off by otherwise respectable members of the business community.  If you must have a scope of work I’ve made a Application Project Management Plan template to make the process as painless as possible.   However, if you can, don’t.

An alternative middle path is to add accountability to these documents by requiring key stakeholders to physically sign off on each document before proceeding to the next one.   If you feel like you’re working with the type of people that would always ask the professor “will this be on the test?”,  then you’ll need them to sign on the line.  If you do end up needing signatures consider a service like Panda Docs for e-signatures they really take the hassle out of getting signatures remotely.

Charters

IMHO, the most underrated project document.

The Project Charter briefly describes:

• why we’re doing the project
• who the primary stakeholders are
• description of primary personas (a.k.a. the apps imaginary friends)
• what the timeline or runway is
• what the budget is
• who the leadership team is, and what to expect from them

Then importantly a formal authorization for the project to begin.

Why we’re doing a project, and who we’re doing it for, serves to focus conversations on project goals.

Timeline & budget bring tasks into line with reality.

Explicitly defining team leadership allows accountability to be aligned with authority, an essential attribute of a well running project.

Keep the charter short and focus on chunking so folks will actually read it.

Project Charters are a big topic, check if your organization already as an approved template for them.  If not, be ready for a wide variety of opinions.

Charts

Flowcharts communicate processes more efficiently than words.  They quickly communicate not just the ideal path, but alternative paths, looping processes, and other tangles of complexity.

Flowcharts also focus conversations on exactly how business objectives are met.  Without the distractions of fonts, colors, logos, & images.

I’ve never produced a flow chart for a process and not had 2 things happen:

1. the discovery and resolution of problems
2. stakeholders visibly relax after getting a deeper understanding of how things will work.

At a very high level SAFe Agile uses value streams that can be a great place to start.  Value streams represent how value continually flows to the customer.   They are low on detail, but high on context, so they make an effective introduction.

When you’re ready to get into the weeds swimlane diagrams  integrate personas with flowcharts.   Each row represents a different persona responsible for the actions or decisions within it.

Don’t assume that anyone has memorized what the various shapes in a flowchart mean.  Include a basic key defining the most important shapes, and label things thoughtfully. Particularily around the decisions, that’s the diamond shape, where labeling the true and false lines is helpful.

Flowcharts build on the project charter to give a couple levels deeper description of what the project involves.  Crucially flowcharts encode essential business outcomes in a quick and easy to understand way, facilitating a more productive conversation.

Other charts you may find useful are sitemaps and work breakdown structures (WBS).  Depending on the project type & size these may be essential or unnecessary, you’ll find people that say both, emphatically.

While Ms Visio is the industry standard for flowchart type diagrams, I prefer LucidChart.com & Gliffy.com. Especially for their collaborative features.

Wireframes

This is where the real money is saved.  It turns out humans are social animals and we learn best through play.   Charters & charts are not particularly fun, but they are a LOT more fun than a pile of paper so I tolerate them.  Interactive wireframes should be a little fun because we get to interact with them.

I prefer that wireframes, at least initially, be black & white line drawings to avoid the distractions of branding & content.  A traditional wireframe that is just a static drawing does not get the participation that we need for great feedback. Static, non interactive prototypes take approximately the same amount of time, and provide less than half the value.  With the right tools there’s just no reason to for exclusivly static wireframes, prototypes, or mockups.

Interactive Wireframes build on the charter & charts by taking that information and applying a napkin drawing level UI to accomplish what they describe.

What this gets us is something everyone on the team can play with, and point to for discussion.   With tools like MockFlow interactive wireframes are easy to make, easy to share, and easy to change.  Also as a bonus most wirefame tools also produce sitemaps, static exports, and even powerpoint slides if you find the odd terrorist.

Often with big paper scope doc’s I’d only get feedback from the most dedicated and/or paranoid of senior developers.   With interactive wireframes business subject matter experts that may be intimidated by digital are comfortable telling me I’m completely wrong and it should work like “X”.  Then I can make a edit in under 15 minutes and we can do another review cycle.   In this way I can knock out a several feature iterations in a few hours or a day or two.   Something that could take months working through a 2 week sprint iterations.

Once the application goes into production, fewer change requests can be anticipated.   This saves us money, preserves client confidence, and improves team moral because they’re not bogged down with as much rework.

How much is just enough?

When folks are asked why Waterfall is bad, the frequent reply is a huge investment in documentation that ends up being wasteful.   Then for Agile we need to use “just enough” documentation to accomplish our goals.

So what’s just enough without being wasteful?  This is the kind of question that can start some very tedious arguments, but in my experience it’s this; only write detailed plans for as far out as you feel comfortable predicting the future.  For the most part I don’t know much about what I’m doing this time next year, but for the next month I have a fair idea.   A month is roughly 2 Scrum iterations so that’s generally what I have planned out in detail.

Now if I had a startup I was trying to get funding for I would wireframe the entire MVP and run a handful of usability studies before I presented it to investors.  I’d do this because I think it shows the entire concept in a very convincing way, and would help with pitching investors prior to having a fully functional app.  Also I think every experienced dev has been burned by a startup by now so showing an extreme level of preparation would build confidence.

Value throughput over a perfect plan, SCRUM’s guidance on time-boxes is an important tool to avoid analysis paralysis.

How will I know if these documents mattered?

If you get feedback that stings because it rings true, or feedback that feel like a punch in the gut because you made a mistake, your documentation is working.

If you get feedback that makes you want to roll your eyes because it’s so off topic and irrelevant, it’s time to change your message encoding.

If you get feedback, early, that everything looks GREAT! You’re a complete failure at engaging in a useful conversation with your stakeholders.

If you ask the dev team what they think and they say your haircut is ridiculous and you smell of elderberries, congratulations they like you and have nothing to add.

If you get useful feedback for a couple iterations, then the stakeholders seem satisfied, AND can paraphrase the project back to you in a way that makes sense. Then you’re ready to move forward.

The point of the charter, chart, & wireframe documentation is to get useful feedback as early and as cheaply as possible.   Useful feedback is usually hard on the feelings, probably for you if you care enough to read an entire blog post on documentation, and likely for other stakeholders.  However, that’s a good indication you’re getting the good stuff.

The exact implementation of your charters, charts, & wireframes will depend on who your stakeholders are, so take time to get to know them, their technical tolerances, and communication styles.

Success in the product owner or product manager role is dependent on stakeholder engagement.  You get the engagement by properly encoding your planning communication to them.   And finally you learn how to encode the message to your stakeholders through empathy.