Showing posts with label System Analyst. Show all posts
Showing posts with label System Analyst. Show all posts

Thursday, May 27, 2010

CSS3 and html5

tools & resources for web professionals

the best site for understanding and creating online code of css3.

http://westciv.com/tools/gradients/

http://westciv.com/

what you can do by using cc3. http://www.everydayworks.com/css_typography/HTMLCSSrotation.html

i like it. alot. :D

http://creatingsexystylesheets.com/

Sunday, November 2, 2008

ye haath salamat khan jab tak







Ye Haath Salamat Hain Jab Tak

Is Khoon May Hararat Hai Jab Tak

Is Dil May Sadaqat Hai Jab Tak

Saturday, November 17, 2007

CRM: Identifying Customers & Their Characteristics


The first step in developing a customer relationship marketing strategy is to gain knowledge of individual customers.  Using existing systems and services, create a list of all customers who receive the goods and services offered by your organization.


 


Gather Customer Data


 


The relationship management approach recognizes the unique characteristics and preferences of customers.  To learn about these factors, gather both the traditional transaction-based data about each customer as well as information about preferences and special requirements.  This may require additional research beyond the information available in current systems.


 


For example, the traditional data sources include:


 


·          purchasing history and products selected,


·          credit history,


·          demographics,


·          channels used for purchasing products and services.


 


The additional types of data that are not generally sought out but provide a basis for developing and strengthening customer relationships include:


 


·          personality type,


·          preferred mode of contact,


·          customer views on your organization’s products and services and those of competitors,


·          customer opinion of your organization in comparison to competitors,


·          preferences, expectations and special requirements,


·          influences.


 


Identify Chain of Influence


 


The value of a customer to your organization goes beyond the individual and extends to others who influence and are influenced by the customer.  For example, in a consumer relationship, a customer’s purchasing decisions are influenced by and influence family, friends and co-workers.  In a business to business relationship, the chain of influence includes the customers, suppliers, intermediaries and partners who work with your customer.


 


As part of this data gathering exercise, identify the businesses or individuals that form the chain of influence for each customer.  Sources for this information include referrals, purchases on behalf of other individuals or businesses, relationships with other individuals within your organization (e.g., friends, family, investor, and professional associations).  On an ongoing basis, this information is collected during interactions with the customer.


 


 http://blogs.ittoolbox.com/eai/implementation/archives/crm-identifying-customers-their-characteristics-20556



Wednesday, November 7, 2007

what Alexexmachina says...

 


To Kill A Project: Part I - Timelines


 


Alexexmachina (Technical Specialist) Posted 11/2/2007


In my experience there are common behaviors, paradigms, attitudes and fallacies which permeate the management of IT projects that are directly responsible for the obscene rate of project failure. In the first part I'm going to talk about how unrealistic timelines will ensure failure.

The number one attitude I see blowing timelines and killing projects is something I call "false urgency". False urgency is creating a false atmosphere of time pressure for no justifiable business reason. An example of false urgency would be me insisting on an arbitrary deadline as though it weren't arbitrary. There are enough time pressures on a project team to make reasonable deadlines while hitting all the functional requirements and ensuring quality in the design and implementation of your solution. Why decrease your chances of getting something you actually want just because you've grown accustomed to our cultural 'I need it yesterday' syndrome.

Here's what you're either too busy to notice (or forgetting) when you rush an IT project: it won't get done like you need it to get done. Then you'll do one of two things, you'll throw it out, which means you've wasted resources, time, money, opportunity and demoralized the project team or, even more costly, you'll make a sunk cost justification (if you don't know what that is, read my post on sunk costs here) and try to salvage the project through endless iterations of continuous failure.

It's a lose-lose situation which will put a serious drain on your budget, your patience and your sanity. Is this the only thing causing unreasonable schedules? On rare occasion I've seen timelines emerge from real business requirements which have an absolute inflexible deadline. Although you can't really do anything to change those deadlines, there are other ways you can adjust.

Expect to hear this next bit from me over and over again: Time, cost, resources and quality requirements are inversely proportionate to the quality and scope of the deliverable. Duh, right? Because I'm a particularly slow learner when it comes to setting realistic expectations for individuals managing IT, I am continuously astounded that those individuals have managed to obtain jobs in management while failing to grasp that very simple concept. In case I was vague or you didn't catch it, I'll put it another way: you can't make a gourmet lasagna for four with no recipe, a broken oven, moldy cheese and $2.00 of ingredients. There are individuals out there who will tell you that you can, but I assure you they are either lying to you or they're idiots.

If you find either of these factoring into why your projects aren't making their deadlines, don't feel bad. I'm not actually suggesting that its simple or easy to manage project timelines and I don't have 10 steps to guarantee you can do it successfully every time. (if I did, I'd write the book and retire) But I have been fortunate enough to work with exceptionally gifted managers who taught me a sane way to get reasonable time estimates and work within time constraints. Next time you're ramping up a new project, consider this:

  • Assess the business drivers behind the need:

    • Is there actually a fixed time line associated with the need?

    • If there is a fixed timeline, what additional costs can you support?

      • Additional budgetary costs?

      • Additional resource costs?



    • What consequences can you live with?



  • If your requirements are reasonably complete, request a conservative estimate from the project manager.

    • Did he ask his technical leads?

    • Did they account for QA and bug fixing?



  • If their estimate is unacceptable you have one of three options:

    • From the beginning provide whatever additional resources they need to complete the project.

    • Cut functionality down and plan future feature releases.

    • Start planning for the disaster recovery, because your project will fail.




Now, as I will talk about in my upcoming post on Defining Project Failure, qualitatively, some projects may 'fail' less than others and get you what you need by the date. But don't think those failures don't carry additional, sometimes hidden, costs. As someone who felt forced to leave a position because of constant, unreasonable time pressure, I can tell you that high turnover can be one of those costs.

I hope this has been helpful to someone. Unfortunately, my experience has been you either get this or you don't. Getting this point across to someone who's been managing IT projects under unreasonable deadlines for a while is near impossible. They believe that missing functionality, low code quality and missed deadlines are just part of the business. As someone who's seen it done right, I can assure you they don't have to be.