Saturday, May 9, 2015

Determinants of Quality

The various Determinants associated with the quality concept in general and TQM philosophy in
particular is:

1. Quality of design: Intension of designers to include or exclude features in a product or service

2. Quality of conformance: The degree to which goods or services conform to the intent of the
designers

3. Quality of Ease of Use: Ease of use and instructions to use increase the chances but do not
guarantee that a product will be used for intended purpose and function properly and safely.

4. Quality of Service after Delivery: The degree to which goods or services can be recalled and
repaired, adjustment, replacement or buyback or reevaluation of service all come under this
category

Saturday, May 2, 2015

8 Common Reasons why Organizations Fail


These reasons are quite universal in nature, I just tried to summarized and rephrased to have in consolidated form.

1. Too much emphasis on short-term financial performance. Cost cutting, profit maximizing at the cost of social responsibility or employee motivation

2. Failing to take advantage of strengths and opportunities. where just for the sake of glory and high profits, organizations forget their core competence and opt for strategies and tactic which cause their downfall

3. Failing to recognize competitive threats. Quite often organizations decide to pursue status quo and ends up bringing no new product or service or even no innovation in its existing product or service line leading to lack of customer satisfaction, decline in profits and finally being declared a failure

4. Neglecting operations strategy. This is definitely the most important reason of failure; organizations often end up employing non-productive techniques which lead to inconsistent and failed operations

5. Too much emphasis in product and service design and not enough on improvement. Differentiation in terms of service and product, American companies in 1980s did that they never introduced incremental refinements rather went for big changes and thus lost to Japanese competitors

6. Neglecting investments in capital and human resources

7. Failing to establish good internal communications. Matrix organizations or hierarchy or
such a strong structure that often the structure does not allow communication.


8. Failing to consider customer want s and needs. This is actually indicative of an organizations lack of marketing research skills. This also shows that there is no respect to Customer Relationship Management Concept and certainly no respect to the customer.

Many Thanks.

Wednesday, August 13, 2014

Who is responsible?

Is it true that
everyone’s
responsibility is, in
reality, nobody’s
responsibility?

Friday, June 21, 2013

Difference between Google and Microsoft approach....using 80/20 rule


 Microsoft’s own research found that the average user of Word uses only *8%* of the functionality, we can come up with the questions that :

If Microsoft had developed only the important 8% of Word, maybe they could still have captured the same market share? 

On the other hand, It’s also worth considering the impact on user experience. Google has shown us that users often prefer apps that do just what you want. That’s *just* what you want. And no more. The rest is arguably clutter and actually interferes with the user experience for only a limited benefit to a limited set of users.

- See more at: http://www.allaboutagile.com/agile-principle-8-enough-is-enough/#sthash.nuJ7cofF.dpuf

Why we need Agile Practices



The use of the word agile in this context derives from the agile manifesto.  

A small group of people got together in 2001 to discuss their feelings that the traditional approach to managing software development projects was failing far too often, and there had to be a better way.  They came up with the agile manifesto, which describes 4 important values that are as relevant today as they were then.  

It says, “we value:


  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  •  Customer collaboration over contract negotiation
  •  Responding to change over following a plan

These are characteristics that are common to all agile methods, and the things that make agile fundamentally different to a more traditional waterfall approach to software development.  They are:


1. Active user involvement is imperative  
2. The team must be empowered to make decisions  
3. Requirements evolve but the timescale is fixed  
4. Capture requirements at a high level; lightweight and visual  
5. Develop small, incremental releases and iterate 6. Focus on frequent delivery of products  
7. Complete each feature before moving on to the next  
8. Apply the 80/20 rule  
9. Testing is integrated throughout the project lifecycle – test early and often 10. A collaborative & cooperative approach between all stakeholders is essential


See more at: http://www.allaboutagile.com/what-is-agile-10-key-principles/#sthash.QjxxM2Ke.dpuf


Thursday, June 20, 2013

Relationship between Agile and Lightweight process

Few days back, I came across quite good article by "Glen B. Alleman- Agile Methodologies", I found quite reasonable brief explanation of lightweight and measuring "agility" of the project.

Lightweight and Agile are not interchangeable words how-ever. This distinction is not well understood by many agile proponents,you can find the distinction below:

Lightweight describes the weightiness of the process and its artifacts. The amount of potentially non–value added artifacts produced by a specific process. 

This weightiness can be attributed to the undesirable consequences of the process – artifacts that don’t provide benefit to the out-come. This weightiness can also be attributed to the application of a specific process. 
"Agility" describes the behavior of the participants and their ability to move or adjust in new and possibly unforeseen situations.

Much like an overweight boat, airplane or athlete, the undesirable weight needs to be removed in order to increase the efficiency of the vehicle. This is a standard best practice in many engineering disciplines. 

Thanks