Thoughts on Processes

The other day I was talking to a friend working for the Indian subsidiary of an MNC on the different processes they followed in their software delivery model. Since the MNC primarily grew as a consulting firm and then had diversified into technology outsourcing, I was expecting that they would be having a bunch of very well defined processes. However, contrary to my expectations, my friend informed me that processes are not as well defined as in another top notch tier-1 Indian software company, Infosys, where he had worked earlier in his career. He said that processes in his present company are often defined by the processes required by the client. This observation rings true with my current and prior experience also. In order to bring in well defined processes and quality levels, extra effort has to be expended. If the client is not willing to take the cost of that extra effort, there is no incentive for a vendor to follow detailed processes which incur more effort or cost. But the story does not end here. He told that in Infosys, the rigour on processes came naturally. It is something which is ingrained into all Infoscions. May be that is what makes Infosys outstanding. 

A VisionPlus BA (or a BSA)

Today I was speaking to a colleague who expressed a desire to become a Business Analyst. He wanted to know how to become a VisionPlus BA. He works on VisionPlus, which is a credit card management application. I have had several discussions with other coworkers on the concept of a VisionPlus BA and the correct usage of the term. In what we have seen of job roles of a person referred to as a VisionPlus BA, the most important ones are to convert the requirement specifications which are given by the business into functional specifications. In order to do so competently, they have to have 2 hard skills: Good understanding of the credit card business (or the consumer lending business in a broader way), and Good knowledge of the product i.e Vision Plus in this case.

In what I have observed of the VisionPlus BAs, I think that they are mostly VsisionPlus functional (or sometimes technical) specialists who have an in-depth knowledge of the VisionPlus application. They know which parameter can be changed to produce what result and whenever the business comes up with a requirement, they propose how the solution can be achieved by using the VisionPlus system. I somewhat don’t agree on using the term Business Analyst for this role. Please check the post for a discussion on the role of a BA. Some organizations, mostly in telecom billing, use the term Business System Analyst (BSA). I think this is the right term to be used as these guys have specialized in a particular business system and use their knowledge to provide the business with solutions.

PSI

While doing some more research on the web for the elusive probability of success of a project, I came upon the PSI. PSI stands for Probability of Success Indicator for a project. I have not gone into details of the same but apparently, it is a scoring system which can predict the success of a project. May be this is what I am looking for. It is in a book called How To Run Successful Projects III: The Silver Bullet by Fergus O'Connell. He has compared the software development project with that of film making and talks about a method called “Structured Project Management” in his book. There is a list of 10 steps which are advocated in the book. They are:

1. Visualize the goal
2. Make a list of jobs
3. There must be one leader
4. Assign people to jobs
5. Manage expectations, allow a margin of error, have a fallback position
6. Use an appropriate leadership style
7. Know what's going on
8. Tell people what's going on
9. Repeat steps 1-8 until step 10
10. The Prize

The author says that any impending disaster in a project can be identified much before it has struck.

Probability of Success for a Project

I have been thinking about something lately: How does a project manager know at any point of time in his project, what is the probability of success for his project? There is definitely a need for such a tool which will help the project manager quantify where the project is headed. This would help him in taking corrective and preventive actions in various areas so as to bring the project in track. As of now, there are various metrics collected for a project. The metrics collected differ in different stages of the project. But if you ask for a single figure which will gauge the probability of success, I am not aware if there is anything which can help. Presently, I would say that most of the project managers go by whatever discrete metrics which are collected and their individual gut feel to assess the pulse of the project.

The more I think about this, the more I am convinced of the need for such a tool. For example, during the initiation of a project, there are certain parameters that should be measured. Similarly, during the requirements stage, certain other parameters needs to be measured. Similarly during the design, development, testing and implementation phases, other parameters are measured. All these parameters should be combined in a way to give us the success measure of the project.

The risk metrics may be the one that represents the probability of success of a project closest. Somehow if the risk metrics can be combined with the review effectiveness at each stage, the defect leakage for each stage and the cost/effort and schedule variance, along with a parameter to quantify the trace-ability, and may be many other metrics, we may be able to come up with a general dashboard which can give us the pulse of the project. It should factor in any dependencies between various parties involved in the project.

Some of the things mentioned above are reported in status reports. But as someone had stated, Status reports are rear-view mirrors. They show what has already happened. It may sometime give us a leading indicator of the success or failure of the project. The Traffic Light reports with Green, Amber and Red colors tell us where the project is headed. But again, it is very subjective and not quantifiable.

Document Effectiveness

In my experience of being in part of development as well as testing projects, I have observed that about 50 – 60% of the effort is spent on preparing various documents like the Functional Specification, Design Specifications, technical specifications, etc. These are most of the time deliverables as part of the project along with various other artifacts. These documents may be the interim outputs which will be used to generate other deliverables / documents downstream or may be the end product itself for some projects. Almost all of the deliverables for a software testing project are also in form of documents: Test Strategy, Test Plan, Test results, Test Closure Summary Reports, etc. Unlike the development projects, where the code is the deliverable, in testing, the documents themselves are the deliverables. Each document is created based on certain inputs and assumptions, thoroughly reviewed may be multiple times, comments and corrections incorporated and finally signed off. Some documents go through many revisions based on updates received after the documents are released. Some others go through various revisions because of comments or corrections that need to be incorporated. I was wondering if there is something like a measure of the effectiveness of the document which can be assigned to each document that is a deliverable. This would help a team to track the quality of their output.

Any technical document can be evaluated for a set of attributes. The most obvious attribute for a document is the presentation and organization. The next general attribute will be the language. However, there are some other attributes which impact the downstream activities. These are: clear scope, coverage, completeness. To evaluate a document on the coverage and completeness, perhaps each section and each functionality of the document should be rated. For technical document scoring, the attributes have to be identified separately for each type of document and evaluated according.

Probably the person doing the reviews and giving the signoff for the document should rank the document for a set of attributes, which can then be given weights and a final score from each reviewer can be obtained. The average of the scores for all reviewers of the document can then be taken as the document effectiveness metrics. In addition to this, the feedback comments should be analyzed and defects related to the document classified. These should also be factored into the document effectiveness metrics. This can serve as a feedback to the author of the document so as to take corrective actions or improvement initiatives for the process as a whole.