fbpx

Copy of Zombies (3)Is project documentation wearing you down into a zombie-like state? Are you spending all your time updating requirements and managing sign-off instead of helping your team think strategically about the value you are providing to end-users and the organization?

Most teams spend too much time on documentation and review. When planning, elicitation, and analysis are done well, documentation and review become simple and speedy.

But reducing documentation seems to remain a struggle for many. Team members ask me:

  • What should I be documenting? What should I remove from my documentation?
  • How do I know when it’s good enough?
  • How will my developers get the code right if the details are not in my specs?
  • How do we know if all of the requirements have been met, if the documentation does not include detailed requirements?

 

Well, of course the answers to these questions vary based on your project circumstances, but VALUE should be the judge of every proposed piece of documentation. Does this provide value? What is the thinnest/lightest version of documentation we can use to deliver value? More is not always better!

Consider these factors to evaluate documentation:

  • User: Think about who will be using the documentation and how they will use it? What level of detail do they really need? Discuss documentation reductions with users and experiment.
  • Lifespan: Determine how long the information will be used and how long it will remain accurate.
  • Cost: Think about who would be willing to pay for this information and why. Estimate how much it will cost to generate the documentation and determine if the cost aligns with the value?
  • Fear: Explore the possibility that fear motivates excessive documentation (aka Cover Your A**?) Does that fear-based mindset boost solution value or does it increase time and cost?

 

Also, be open to the format you use for documentation. Do your requirements need to be written in a template? Do they need to be entered into a tool? Depending on your team structure, documentation might be post-its on the wall, drawings on a white board, prototypes, notes on a napkin or even a series of discussions/demonstrations.

Above all, strive to create an environment that allows for constant collaboration and meaningful dialog with developers. Change the mindset that thinks requirements are DONE when we hand them off to our techies. Instead, be in it together from start to finish.

Here’s hoping you get out of zombie land and join the land of the living!