19th May, 2014
There are two parts to the above question – (a) how to start with OPD (b) what tools to be used. I think the part (a) needs a more definitive answer. One suggestion I have is to have a brainstorming session within the organization with key stakeholders (process managers, process leads, etc..) for identification of processes and their interaction with each other. I use an innovative method for this. I call this brain-storming session as PIV Workshop (Problem Impact Vision) Workshop. In this workshop, along-with identification of processes and their interactions, the problems were also identified which were Project-Related, Process-Related, Client-Related, Supplier-Related, People-Related, Resource-Related, Govt.-Related, etc. After, identification of processes, the impact of these problems is identified and VISION was created that how future processes (that will be deployed through OPD exercise) will address these problems. This leads to the creation of robust processes which incorporated solutions / remedies to existing bottle-necks.
The part (b) of the question is with respect to the tools – there are various opinions which advice caution and some of them are adulatory about the tools. It is definitely an excellent idea to determine a tool that is best for you on basis of a formal DAR or by a process of brain-storming.
We have seen Share-Point, Al-fresco, SVN, VSS, etc. being used as a tool to manage the PAL (Process Asset Library. On a linkedin Group, various members had referred to Wiki, TWiki/FosWiki, Confluence, Taskmap, Staged by Method Park, etc., and many other such tools.
Selection of tool and it is use is significant. With that, I would also like to highlight that it is important to develop a process writing / description guidelines, implementable across the organization, and are designed in such a manner that processes are able to accomplish what they have to. It is also important to determine the Process Hierarchy. The term process means different things to different people in different organizations. For a specific organization, process boundary / definition needs to be established, then sub-processes need to be identified within the process, leading to activities and then tasks within the activities. It can be assumed that the “task” is the smallest unit of activity which lends itself to meaningful understanding. All these definition about process-hierarchy have to be documented in the Process Writing / Description Guidelines and then the EPG / SEPG can pilot the OPD in the organization with or without using the tool(s). Further, the Process Hierarchy need not be waterfall type. That is just an example. It can take any shape and form. The idea I am trying to promote is that if you have to develop effective processes for your organization you need to have guidelines whether you use the tools or not. These guidelines have to be more than simply process-description templates like ETVX, etc. They have to go deeper to create a definitive grasp on the deliverables of the process so that you achieve what you want to achieve out of the process.
The general principles that I have evolved are as follows: (a) The first-point, that I recommend, is we should use the tool that is available for enterprise-wide usage and preferably already in use by the technical teams (project teams) so the efforts to popularize the tool are reduced. If the organization is using share-point tool for various activities and it is familiar to the technical team (project teams), then, share-point would be the most appropriate. Similarly, any tool that is in use at enterprise wide level is the best one to use. (b) The second-point, that I recommend, is the OSSP and PAL Library should be on a tool that also has the capability for implementation instead of being just a repository. For instance, a tool that is a repository and also provides capabilities for dynamic project management, issue management, metrics management, configuration management, etc., i.e., the tool that combines the capabilities of a repository and also execution would be the ideal one to use. (c) The third-point, that I recommend, is that the repository should be created in such a manner that it allows the access to the required artefact (template) in maximum three clicks. (d) The fourth point, that I recommend, is that the processes in the repositories should not be designed in a stand-alone manner but should be shown in the way that they are in real life. For instance, Project Management and Requirements Management may be two processes in the repository (PAL) but in real-life both the activities go hand in hand. The processes in the repository (PAL) should provide this real-life feel to the user. These are the successful ingredients for a real-life repository (PAL). Hope you will find these ideas useful. Each of these recommendations can be further detailed. However, I have tried to be brief.
Note: This question was posted by Robert Pletscher, Software Engineer at CTModule on the linkedin group: CMMI-Capability Maturity Model Integration (Main Group). The views expressed above in response to the question are of Rajendra Khare.
Published by CMMI Consultant
Previous PostHow important is Design Quality in our Software Industry and what are the Metrics used for the same?
Next PostWhat should be the guiding principle for approach to process-mapping?
Rajendra's LinkedIn Profile
Rajendra is a qualified and certified Lead Appraiser and Instructor for the following :
Rajendra is Lead Assessor for ISO 9001 (QMS), ISO 14001 (EMS), OHSAS 18001 (OHSMS) since 1994
International Automotive Task Force (IATF) approved Lead Assessor for Automotive Standard TS 16949:2009
Lead Assessor for ISO 27001 (ISMS) and ISO 20000-1 (ITSM)
Rajendra has 25 years experience in the industry.