Saturday, November 25, 2006

Write the requirements Right the first time


In most of the software projects that I had worked with, the requirements are not captured and analyzed properly. This is one of the main reasons for the many problems that are being faced in the project. The requirements are written in an ambiguous manner and without analysis or application of mind and in most of the cases, the User Requirements Document seems to be a Vomit of the Customer (instead of Voice of the Customer). This is primarily because of the lack of understanding and analysis of the so called Business Analysts (BA); the BA’s emerge as Business Analysts by accident and not by intend.

The Wikipedia definition of Business Analyst (BA) is “A Business Analyst (BA) is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers.”

The BA should help the customer in identifying business problems that they have in their day today operations and propose solution so as to incorporate in the software application that is being built. To do this the BA should have a thorough knowledge of the customer’s business. Is it possible to have a thorough knowledge of the customer’s business? The answer is NO. Customer definitely knows his business better and much more than a BA would. Then, what is the value addition the BA can bring in to the table. The BA by his analytical skills should be able to point out the problems (or pain areas) and suggest alternate solutions(s) to solve these problems. The BA should be able to suggest innovative ideas in solving and sorting out the problems. For this the BA should have a good background about the industry in which the customer is in as well as draw an analogy to other industries as well. The BA should have a decent amount of technical expertise, he should be conversant with the usage of UML (Unified Modeling Language) with respect to Use Case Diagrams, Sequence Diagrams, Activity Diagrams etc., The BA should also be able to do a feasibility mapping of the requirements with the tools and technology that is being used to build the software application. These would help in better and uniform communication among the various stake holders, thereby BA performing a liaison function between the business side of an enterprise and the information technology department or external service providers.

The above qualities are clearly lacking with many of our BA’s and they really become Back Ache’s rather than Business Analysts in the project value chain.

Friday, November 24, 2006

Who is responsible for Quality?


Many of us think that Quality is a value addition that we provide to our customer; but actually it is not. It is one of the parameters of the service that we provide to the customer which will also act as a marketing tool for getting more business or sustaining existing business. Customers are really concerned about quality nowadays and expect quality out of every penny they spend. Also, they don’t mind spending a little more if they could get good quality product. GE’s Jack Welch ably summed up the importance of quality - “Quality is our best assurance of customer allegiance, our strongest defense against foreign competition, and the only path to sustained growth and earnings.”

In a software project, who is responsible for a quality product?

If you ask the Customer, he would say that the Software Vendor is responsible. If you ask a Project Manager, he would say that the Software Engineers are responsible. If you ask the Software Engineers, they would say that it is the job of the Project Manager to ensure Quality. The fact is that everyone is responsible for the quality of the software product.

It is an accepted fact that software (or rather any product for that matter) cannot be 100 % error or bug free. There will be errors or bugs, but at the same time there should be acceptable limits to the errors or bugs that would be present in the software. This is what I would call as “Acceptable Quality”.

The Customer would be responsible for defining the “Acceptable Quality”. Without the Project Manager agreeing on the “Acceptable Quality” with the customer and setting guidelines, standards and checklist, the product will not be of acceptable quality. Similarly without the Software Engineers adhering to the guidelines, standards and checklists, the product will not be of “Acceptable Quality”. So, everyone will be responsible for the quality of the product.

Electronics giant Siemens has the quality motto: “Quality is when our customers come back and our products don’t.”

Thursday, November 23, 2006

Welcome to My Thought Leader Blog

Hello Friends,

Welcome to My Thought Leader blog.

"Thought leader is a buzzword or article of jargon used to describe a futurist or person who is recognized among their peer mentors for innovative ideas and demonstrates the confidence to promote or share those ideas as actionable distilled insights"

I wish i will become one such Thought Leader in future and i will be sharing my thoughts and experiences through this blog site.

Regards
Deviprasad K