I am working with an ISO firm and we are trying to achieve CMMI certification. In my early carrier I did not bothered about these terms. But nowadays these terms are somewhere hindering my work or they are giving me a real boost at some points.
I had given a thought about what should be the quality and these big wordy things are trying to achieve. I had also observed and discussed with many of my friends about these quality defining terms. I still am not very comfortable with the way they are followed in day to day life. I am a very guy who values simple things since they are always effective on longer run. I must say that the inspiration behind my process philosophy is also an article on “Mumbai Dabbawalas” and way of their work and simplicity in their lives.
So here goes my process philosophy.
It should create Guidelines, Tools and frameworks as well as best practices to address critical business problems.
Process should go further and create models that addresses to particular type of business areas/solutions or categorize the problems that we frequently face.
Process should be treated as a critical project on which the organization’s business success will be defined.
No matter, what price the organization has to pay for following this process discipline should not be broken at any of the projects whether they are of bigger size or smaller or in-house projects.
Off course, I believe that project is going to succeed with the creativity of project’s team members. So process should offer freedom of creativity between the process frameworks.
I also believe the project teams should take advantages of these inbuilt expertise provided to them in the form of processes and also if they want to be part of process improvements they are always welcome.
We depict the process as some “Black magic box” which accepts the disorganized inputs in the form of data and turns into organized information that is more useful and holds more value to project team.
When we think in terms of our users, that are project team members, we know that they see the process as overhead on top their mission impossible tasks. We agree, that process build some overhead in project’s childhood, but when the process is absorbed and turns a habit for team members, the team definitively realized the golden values unleashed by following process.
The comparative larger overhead factors can be seen in deception phase of project and it gradually decreases when project moves into successive phases.
It has been also my experience in this field[software] that the greater the inertia for adopting the process and greater the questions asked for the importance of following the process, greater the team’s percentage of following the particular process, since they understood it not merely follow it.
The ardent opposition becomes your devoted followers when they see the value of following what you tell them to follow that is something like universal truth for human beings.
The process definers should create a faith element in the process followers. Any project team member believe you only when he has to face some situation and then process outcomes/outputs shaves his work or keep his word.
This sort of experiences helps us to turn the team members into good process followers.
It has been always a risk for the members that follow the process without really understanding the value and importance of process.
These blind followers create the illusions around the processes and try to follow it only by that way. These kinds of team members does not follow process for the benefits of process, they follow it since processes are imposed on them by their successive bosses. These team members often fall into pitfall of minimizing the benefits of process and see the output of process as the only documents or some kind of review compliance. These people neither build their project on the infrastructure provided by the processes nor contribute to enhance the process life time in a greater sense.
But be very sure that, Still these kind of blind following to the process at least do not contribute to the project failures rather they still minimizes some risks associated with processes.
Best practices to define the process:
1. Process makers should always look for helping their “customers”.
2. Process in fact should tries to minimize the overhead in terms of documentation and other outputs using various techniques.
3. Best guidelines are the actual examples that are available in terms of project documentation or project presentations or code.
4. Process should always be self sufficient. That means after taking the inputs, for processing it should not be dependent on anything.
5. Process should always comes up with easily available help, best practices, guidelines to follow process and training material and example project and MUST provide references and literature that process address.
6. It is good for any organization that if it will create a modular application example with all process followed within it with the importance explained.
7. Process should be simple, meaning non ambiguous to its followers.
8. Process owners/definers should always have good communication and spent more of their time with process consumers.
Process should have following characteristics:
- Clearly set entry and exit criteria with it
- Definitive inputs and outputs
- Independent of any technologies
- Based on its core values and principles
The process Life time is also a important factor while defining the process.
It is dependent on factors such as business goals changes, environment in which process has implemented changes etc. process definers should always think of how they can increase the life span of the process and how it can be done.
To judge the expiry time of process, we need to apply process measurement measures mentioned above.
You are welcome to share your views on the process.