business process

Nov 18 2009   10:00AM GMT

Seven Key Factors for Business Process Management

Posted by: Jaideep
business process

Once you are in a situation where you understand your business processes (What-is), you need to know to manage them. Managing is not let-going, it is more than that. Managing is a regular process of understanding and improving. So let us discuss the major key factors that drive Business Process Management to make you understand if you are managing your business processes well or not:

1. Improved Process Cost: In past six months have you done any improvement in your existing process to make it more cost effective? If not, record it that there has been no improvement in this specific process past six months. It also proves that your Business Process Management is not effective.

2. Decrease in CoQ or Cost of Quality: If you are incurring the same cost on your process quality and there has been no reduction, it needs to be re-looked into the way it is being examined.

3. Improved PTT: Process throughput time should improve (decrease) gradually with the enhancement in the process.

4. Training Time: Don’t bother too much if your training time or training cost is going higher if you are meeting all other factors mentioned here 25% plus. If not, it would be a worry point.

5. Reduction in Internal Complaints: If process drivers and users have realized a substantial reduction in complaints pertaining to the process, you are definitely moving in right direction.

6. Reduction in Customer Complaints: The worst situation could be that customer has stopped complaining you about your product or system because you have stopped handling it. Jokes apart, if customer complaints have reduced and complaint resolution time has improved (reduced), it is a healthy sign.

7. Your ‘Surety’ about ‘Tomorrow’: If you are more confident ‘today’ about your ‘tomorrow’ than you were ‘yesterday’, you are steering your business process management well.

But mind it; this is an ongoing process itself. A small improvement and a big rest will make you worse than you were. You need to have continuous improvement.

Nov 16 2009   10:00AM GMT

Enter the Dragon – Business Process Management

Posted by: Jaideep
Business process management, business process, BPM

Are you ready for Business Process Management? As the title suggests, it is not an easy task or rather is an uphill task. You will find many roadblocks on the way to stop, deviate, misguide or befool you so that you are never able to reach your destination and wherever you reach – you will be convinced – as your destination. These roadblocks will be in the form of your peers, management, superiors, juniors and everyone else. Very few process owners will seriously cooperate you in this journey and the less you are aware about their business process, the more troublesome will be the journey for you.

When you start Business Process Management in any organization, your first task is to understand ‘where-is’ situation for all your processes. You will have to meet all business process owners – again and again to get more into it. The key factors of “Where-is” would be:

Process Cost: It is very important to estimate each process’ cost once you start this exercise. If you don’t know the cost of a process, you can’t manage that process, and you can’t understand what is lacking in that process and you can’t chalk out an improvement plan.

Cost of Quality: How much are you spending for the quality portion of a process? Is it visible and measurable? Or you might have to dig out further to arrive at this part. The cost incurred on finding/fixing bugs or errors is one of the major parameter.

Process Throughput Time: If you don’t measure it, start measuring it. If you don’t understand how to measure it, or what is it? There are ample ways to understand it.

Training Time: You might be incurring cost on trainings, have a record of all the trainings incurred ready.

Internal Complaints: Your process might comprise of say Hardware Support to internal customers within the organization. Analyze the data to assign various parameters that will help us in concluding certain facts at a later stage.

Customer Complaints (External): If the same process or system relates to external customers also, collect the data pertaining to customer complaints and resolution time.

Your ‘Surety’ about ‘Tomorrow’: If your processes are strong, your confidence will speak about it, if not, you will not be very much sure what is going to happen tomorrow. Check it – how confident are you?

And mind you, this is just the beginning. A lot more is yet to come…

Oct 26 2009   10:00AM GMT

Five ‘must-have’ skills to be a Business Analyst

Posted by: Jaideep
business analyst, business analysis, Project Management, Software Project, software, business process, business rule, customer requirement, software requirement, quality, process, Development, business knowledge, technical knowledge

As stated in my previous post, a Business Analyst is a quite powerful role that establishes the base of a project. It is the first visible pillar for a project which involves communication, leadership, writing, technical and functional skills together. A business analyst has to have a great depth of knowledge of the business on one hand, a sharp understanding power, strong writing skills, great communicator, and a good influencer. Let us see what are the ‘must-have’ skills without which a business analyst can not survive? And why are those skills so important to be a business analyst? Without any relevance to the order in which they are mentioned (as all are equally important) these skills are:

5. Business Knowledge: A good amount of experience/ exposure/ knowledge of customer business are very important for a business analyst

4. Listen and Understand: A business analyst has to be a good listener and with a sharp understanding power without which all the discussions with customer will be fruitless.

3. Technical Knowledge: There will be quite a few technical discussions at customer site. The BA has to be quite conversant with the technologies and methodologies present at his organization.

2. Communication: A business analyst has to be a strong communicator. During the customer meetings, if he does not communicate well about his organization’s capabilities to build up the trust and confidence, probably customer may not gel well with his ideas.

1. Writing skills: Very important skill required for documentation and for conveying the right messages across the board.

Oct 23 2009   10:00AM GMT

Various roles of a Business Analyst

Posted by: Jaideep
business analysis, Project Management, Software Project, software, business process, business rule, customer requirement, software requirement, quality, process, Development

Business Analyst is a quite powerful role forming the base of a project. It is the first visible pillar for a project which involves communication, leadership, writing, technical and functional skills together. A business analyst has to have a great depth of knowledge of the business on one hand, a sharp understanding power, strong writing skills, great communicator, and a good influencer.

For a software company having various new development projects a business analyst has to understand the existing business processes, methodology, rules etc. of the customer, document it (which itself is a specialized task) and hand it over to development team to embed the customer requirements into the software to be built.

For a software (or IT) sales company a business analyst has to sit behind the sales/ business development teams – understanding their current process of acquiring new business or sustaining current business and bring out a better approach, methodology, process to enhance business in terms of new business and holding current business.

For a manufacturing company a business analyst has to understand the process, re-engineer it to enhance the production, product yield, thereby increasing customer satisfaction and reducing defects or rejections.

A business analyst ‘s various caps thus include – business process analyst, business strategy analyst, business methodology analyst thereby becoming a backbone to business process managers, sales teams, management, development teams , product teams, quality teams etc.

Aug 7 2009   10:00AM GMT

Ten Mantras for a software developer

Posted by: Jaideep
Software developer, software development, Application development, Software application, software testing, bug-free, Bug, software, application, bug identification, application building, code writing, application performance, business requirements, Business Rules, code validation, business process, process owner, end user, collaboration, tester, application functionality, software functionality, software performance, quality, customer experience, software build, bug fixing

Lot of efforts can be saved in terms of time and money if we reach to a stage of ‘first time right’ in application development. It has been proven largely that no good application can be built and released without extensive testing. Testing is not developers’ ball game – this is also a well proven fact. Reasons are many as far as it is concerned that why developers can’t build a bug-free application, or why can’t they test on their own. We are not going to discuss those reasons here. Focus here would be on what developers should keep in mind while building an application that it requires minimum efforts and time in all testing stages. As we all know the cost of bug fixing goes manifold, depending on how much distance (in terms of time and project stages) it has covered after development for bug identification. The bugs identified at a later stage, say during UAT cost more significantly as compared to the bug identified by the developer himself immediately after writing a code. Few qualities if a developer acquires and keeps in his mind while writing codes would not only benefit him but the organization he is working for and their customer also for whom the product is being built.

1. Commitment to application performance should be kept in mind while writing a code.
2. Clarity of business requirements and rules/ validations that are being translated into the application with real aptitude of business and not a developer. Don’t imagine and build. If there is some lack in clarity – discuss, record and build.
3. Treat yourself as the business process owner and end user – and build the application accordingly as if you have to use it. Don’t think yourself as a bartender, think as if you are preparing the drink for yourself.
4. Collaborate and build – rather than building in isolation- collaborate with other developers working on the application, the end user, and the testers.
5. Optimize your code – don’t just write it. There are n numbers of optimizers almost in all technologies. Use them and build a strong application in terms of functionality and performance. Be quality focused. Don’t do efforts that call for more efforts later.
6. Be focused. Don’t work on various applications development at the same time unless it is too mission critical.
7. Gain customer experience after launch of your application. It will certainly help you in your future builds. Build a customer satisfaction metrics.
8. Don’t take short cuts in fixing bugs – whatever stage they are identified. That way you will build more bugs while fixing identified bugs.
9. Work like a champion. There is a difference between playing a shot and playing an accurate shot.
10. Be loyal to yourself, your organization and your work.

Aug 5 2009   10:00AM GMT

User Acceptance Testing (UAT)

Posted by: Jaideep
UAT, user acceptance test, testing lifecycle, software testing, product testing, software product, software development, customer specification, interfacing, functional testing, functional requirement, functional specification, business rule, business process, integration test, software build, validation testing, defect fixing, bug fixing, software defect, software bug, appearance testing

UAT or user acceptance testing comes as the last exercise in software testing lifecycle. It is probably the first phase or beginning of customer preparing to takeover the charge of the product. Actually this is a sort of test drive by a perspective buyer who has studied well about a car, has made up his mind to buy it but wants to satisfy himself by actually sitting in the car and driving it. Even if you have made up your mind to buy a particular model and after sitting in the car or after having the test drive, something does not suit you, the decision can take 180 degrees turn.

The same usually does not happen in UAT because the unlike car the software has been built as per customer specifications. UAT usually includes interfacing (if any), look and feel, ease of usage, functional requirements, integration test etc.

Like a car test drive, here also use runs the complete software to assess if the software is meeting their requirements completely or not. It is the last place where the user gets to determine whether or not the software meets his or her requirements. But one thing is very clear – whatever defects occur during UAT, their fixing cost goes manifold as compared to the same defects occurring during the initial building of software.

Main difference between the earlier testing done at development place by testers is that here the business process and validations built in the software will be checked by a business process owner with real data.

Probably in this busy world, if the end user, by any chance is available during the development and testing phase to do appearance, functional, process and validations testing, it would save a big amount of time and money.

Mar 6 2009   9:42AM GMT

Why software testing effort estimation is important after functional specifications finalization phase?

Posted by: Jaideep
software testing effort estimation, software testing, testing effort, functional specifications finalization, functional specifications, sizing of software testing effort, test case, testing time-line, testing timeline, testcase, quality standards, tester, testing, Test Plan, testing plan, test result, test report, development team, developer, software development, bug report, bugs report, testing guidelines, test plan guidelines, test estimation guidelines, testing knowledge, business rule, business process, functional coverage, bug-proofing

If we go by quality standards the sizing of software testing effort has to be done before the tester(s) start writing the test cases for the purpose. The estimate will clearly draw out of the functional specifications signed off between the customer and vendor. Without sizing the Testing manager can never create a testing plan based on which he will decide the number of days and persons required to write test cases, perform testing, draw out the testing results, submit the result report to development team and get the reported bugs resolved. The plan will comprise of time-line and no. of persons required for each of this phase in the sequence mentioned above.

To calculate a reasonable testing time-line estimate based on functional specifications there are certain guidelines that need to be followed: the person who is planning has to have ample business and testing knowledge. Unless (s)he has the right business knowledge (s)he will not be able to select the right persons for writing test cases, or able to guide them on the critical business rules and processes written in the software to hit upon. In that case the best of the test cases will lack the complete coverage and accuracy in testing. The software may lack bug-proofing at the end and customer will be the sole sufferer. Ultimately it is going to effect the software, and the organization that built it.