Standard Processes and Templates!

When I opened that product release notes which had a number of headings and sub headings in the glaring arial font with the "not applicable" in most of the section text, I was least interested in knowing what that release has in store. Since that portfolio of products came under me, I sent it back to the product manager asking to revise the release notes. A prompt response came with the copy to the documentation team lead, saying the product release contents are correct and requesting the help of the tech writers to revise it. Again a prompt response from the documentation team lead came saying that's our standard template! Ahh, standard templates and processes!! 

Do we ever spend some time to understand what are these standards? Why it is getting formulated? What does it contain? Who formulates these and who benefits/ what beneficiary? Who approves it? When was it last revised? Did any feedback obtain on the usability of this template? Is it enough to have one template that fits ALL? What is important, to release a notes that is in company's standard template or one that is readable, make sense to the reader?

Hence this post on what should be our standards....

1.Let the standards( templates or processes) reminds the basics and gives the flexibility to be creative/ informative. Let it not be the other way, constraining and conforming.

Layout is up to the imagination and creativity of the one who documents it, the contents are by the product team, but it must contain certain important information/ details. 

For example, a release template need not dictate that it should have " the new features, the fixes and the enhancements", as some of these sections are not applicable for a patch release for instance. But it can always dictate, the release notes must contain the product name, logo, version, the support center contact coordinates, the support center operating hours, a link to the knowledge base/ the user community, the confidentiality statement, etc.

The must have details might sound so obvious to you, but I have seen people are so engrossed in the so called templates, missing out these obvious ones, for example in an event invitation, the focus was only on the glaring black/ maroon color coding and missed the venue details. It was not a onetime mistake, it was a  standard mistake and a common joke/bet to wait for the second mailer with corrected details.

2.Let the standards( templates or processes) focuses on the contents, not on the formats.

It always amuses me to see such a substandard documentation in the name of standards. Let's take here an example of an user manual. It is hilarious to see a screen shot and underneath for each field, texts like " enter name" ( it won't even say whose name  ), as so called explanation while the label for the text box also would read the same. On top of this, a voice over is also provided to make it sophisticated!!! Instead shouldn't we define the standard as that one focuses on the need of that particular feature, explaining  how it'd benefit ( say for example, in a email filed, one may document " in case of security breach, the security pin will be sent to this email id to lock/unlock your account", instead of " enter valid email id in the valid format xxx@domain").

3.Let the standards ( templates or processes) facilitates on the productivity, let it not take away the productivity. 

Let's take an example of minutes of the meeting. Let the standard be, the MoM needs to be circulated within 2 hours, instead of that it should be as per the company template. In the digital era, it's fine to take a photo of the white board and circulate(so the actions can be accomplished) rather than circulating MoM for audit sake after a week, or just before the next meeting ( next audit?) in a proper template. Alternatively we can take the photo of the notebook page where the notes are taken. Yes, here is another standard you may want to consider, no laptops in the meeting in the name of recording notes. As far as I know, people just physically present while checking the mails and chats during the meeting.

4.Let review and revision of the standards( templates or processes) be the standard of the organization.

Agile is just not only an engineering model, agility is the mindset, culture. It is essential that we look into our standards/ processes periodically to assess whether it makes sense, caters to our present needs. 

For instance, when I took over a team, a status report has been sent every week indicating red, Amber, green ( yeah, you guessed it right, it's always green). When I asked to include the plan against which the status is marked, the lead refused stating that it is as per the organization standard. Fine, when I asked to share the plan separately, I received 4 different versions in 4 different formats in 30 minutes time frame. Though the lead has confusion on the plan, absolutely no confusion on the ever green status. 

Another classical example, when an associate decided to move out, a replacement request was raised immediately. When I had requested an explanation/justification of the load, it simply stated, replacement and the lead argued that's how the process works. 

So, make it a standard to review / revise the process every time an opportunity presents itself, if not, make an opportunity to review/ revise the standards in your organization for the betterment.

5.Let the standards( templates or processes) be standard for everyone in the organization. If it varies with people/rank how can it be a standard? Let me rephrase it, a standard has to become stringent as we move up along the rank, it can remain the same, but certainly can't be lenient for the people of higher ranks.

Does this even need an example?

Epilogue : Ok, in short, let us form the standards (templates or processes) based on the core value/ principles of the organization to stand out as a standard.