Why should always be there – “Process Management in IT”

So while I could not find a right place for some interesting observations I thought I can write it on my blog. This way I at least have a record to verify how much of this is correct. There is a important lesson which I have learnt in almost all situations I have been. Do not waste your knowledge, time and energy on justifying a right thing to someone not worthy of it.
Now getting to the point. I am trying to derive some conclusions worthy of a look based on my experience in a support environment. All these are meant only for IT services industry (team work and all that )
So let’s do it the hard way. Point by Point –
Fallacies and truth
Fallacy No 1 – Inexperienced people cannot contribute to the process.
Truth – Your process itself might be faulty. An intelligent professional is one who knows to pick whatever he finds interesting from which ever means possible. After all when did innovation know boundaries ? When things are not falling your way you got to give way to free thought. Sometimes the most silly ideas can set things right. Now for silliness you need out of the box thinking and for that you need inexperience .
Fallacy No 2 – You need people to provide the right kind of support
Truth – Note I intentionally removed the word right before the word people. Whenever you provide support the process has to flawless. Remember humans cannot be perfect but processes can achieve perfection. If you have the right process the yields of it are right documentation and right outcomes.
For providing support efficiently you need an average guy with the right documentation and not a genius with state of art tools in hand.
Fallacy No 3 – The deliverables are more important than the process itself.
Truth – This applies to all environments – not just support. After why the hell did they create standards ?
a) Documentation – People have spent ages telling us that the outcomes of a project is 40% code and 60% documentation. Most would agree that they follow this. But I had say 70% code and 30% documentation. But something which is accurate and meaningful. No point creating 80K lines of code if it’s not doing what it was intended for. Similarly no point keeping a 1000 page documentation when it’s not updated and accurate. If you have the right documentation (one in which you cannot afford to have even a spelling or grammatical mistake) half the job is done. And most importantly a “why“ at every stage is paramount for the success of that documentation. Blindly doing things is going to land you in a lump of shit one day or the other.
b) Actual Objects – Whenever you add something extra to a system already stable the only way you can ensure correctness is by first starting with a workflow then moving to rigorous testing and thirdly steps to deploy in way that even the dumbest person on earth can do it. The only way to achieve these objectives ( as far as I can think ) is to be harsh on yourself. If you don’t understand the ground reality ( that is how the deployment is actually happening ) or choose to ignore it by observing the outcomes. Without a tinge of doubt you are pushing yourself towards disaster. The apparent outcomes are in most cases right it’s the one you could not think of that are a cause of concern. To rule those nasty ones out you need to make sure that the part of the developer ends with the development f the code and ensuring that the supporting doc is correct. If you think the developer is a also a important part of the release your process is at fault.
Fallacy No 4 – People will share information.
Truth – You don’t really need people to run a environment. You need information to run it. People will come and go by but it’s your process which can extract information from them. However good they are nobody is going to provide you with information. The process has to extract information from them or rather force them to share information.
For e.g. A guy created a marvelous thing. You appreciate him the thing works fine unless he leaves you. It’s important to make sure that he is forced to share his information with the team so that not only they understand the workflow they are aware of the possible flaws. Simple technique ask someone (other than the guy who created the object) to fill a information template get it reviewed by the developer. Ask the developer to create a workflow – although if your development process is right this should be the first step. It’s important to understand the difference between a document and a workflow. A document is collection of figures and text describing everything in detail. A workflow serves just the process of describing the inputs the flow and the outputs mostly by the use of a Object Oriented design or a flow chart at bare minimum.

Contd onto second part……..