This article was published by me on LinkedIn earlier.
— — — — — — — — — — — — — — — — — — — — — — — — — –
Disclaimer:- All of what is written here is my own opinion. ‘nuf said.
Raise your hands if you have heard / said these lines before:-
- “This is not our job, this is the job of documentation team”
- “I’ve many important things to do and deliver, I don’t have time for process”
- “Process, what is this? We are doing fine here without it, we don’t need process here”.
This term ought to take the cake for oft abused / misused one apart from “housewife” (that is the MOST abused term on this planet IMHO. I think they deserve a LOT more respect than they get, but i digress).
I also think that knowledge of process is an evolutionary primitive to move up the corporate ladder because nothing provides a better view of the corporate than process.
This post is an attempt to explain the term from my perspective. Suggestions, remarks, feedback are welcome.
MYTH #1 — Process means documentation
Process is a way of doing things.
That’s it.
That’s what process is — A way of doing things. Say this again, and again and again, till your mind hurts and you cannot think further.
If you are following some steps to achieve an aim and if you are following a path (Ok, any path, your path, my path, some path) you are following a process (whether you like it or not). If you dream of reams of documentation in your sleep with reference to process, then I am sorry because it was never meant to be thought of in such a way.
Let’s pick some very common processes:-
- The process of going from one place to another
- The process of translating requirements into working software
- The process of capturing requirements from client;
- The process of eating / sleeping / buying things / selling things ….. you get the drift.
Just because it has not been documented, doesn’t make it a non-process.
MYTH #2 — It’s not process if it ain’t best practice
Now, this actually hurts. Best practices have a way of hurting like no one else. We have gotten results — good results, with satisfied customers — with less-than-best-practices. Also, has anyone seen a definition of it, lately?
Practically, if it works for your team, helps you repeat the success again and again, then I guess it is a best practice, for your team.
Ok, if you insist, call it a better practice. But please, don’t call it the best, because it depends on a lot of things (# of people required to execute it, can it scale up/down, efforts required to implement it, clear ROI, etc.).
MYTH #3 — If it works for company A, it will work for company B
Nothing can be farther from the truth.
The line, when corrected, would include “may” instead of “will”.
A successful process implementation answers the following questions:-
- Does it account for the existing capabilities of the team (in other words, can the existing team do it, with their current skill set)?
- Does it provide a way to not only repeat the success, but also to record the failures?
- Does it take the number of people into account (in other words, process that requires 200 may not work for 20 member team, and vice-versa)?
Successful processes depend a lot on the balance between other 2 factors — people and technology (and here i was thinking that it is just for feel-good factor and CYA, meh). Which means you will not be successful if:-
- Technology and process is appropriate but people with required skills are not put to implement the process;
- Technology and people are appropriate but the process is outdated (e.g., no review mechanism, no record keeping even though technology implemented supports it, etc.);
- Process and people match but no technology in place to help them (e.g., a very complicated, industry-recommended and proven process to handle incidents without tools to identify them in the first place, no-IDS, anyone?);
Please let me know if these myths exist or it is just a figment of my imagination. Any feedback is welcome.
