Project Management in IT Career!

Project Delivery Management

2011-02-02T09:38:00.012+05:30

There are very basic simple steps for Project Delivery Management!

(1) Build the team right, at whatever costs. It is an investment, that takes you a long way!
(2) Dont take the advice from team members lightly, they are the future leaders, who might see something special.
(3) Communication is the basic stuff anyone looks for. Either with team or client, be clear. Dont hide anything.
(4) Take ownership. Dont have anyone do it for you, as you are supposed to be in control. Rain or Shine.
(5) Good team that performs, are built over a long term. Dont expect success in short term. Make them perform at least one year to get the best results.
(6) Family members of the team are crucial. Dont make the team overwork. Give them work life balance. Dont make them work your fancied work times.
(7) Look at the overall business scenario, over the last year - quarter on quarter basis - to make informed investments. Decisions should not be based on knee jerk reactions.

Happy New Year!

2011-01-01T09:46:00.000+05:30

Happy New Year! 2011! May the best come to you!

Saas Cloud

2010-08-24T10:57:00.001+05:30

Some articles you should read to know more about Saas and Cloud Computing.

http://en.wikipedia.org/wiki/Cloud_computing

In this article I found some real good tips, about the cloud products...

http://blog.softwareinsider.org/2010/08/10/tuesdays-tip-10-saascloud-strategies-for-legacy-apps-environments/

If you want to know more about cloud computing and its differences with Saas (software as a service ) read this

http://www.mindtouch.com/blog/2008/05/28/differences-between-saas-and-cloud-software/

When we talk of security, we need to look a step beyond the regular virus checks etc.

McAfee has a security suite....

http://www.internetnews.com/security/article.php/3890456/McAfee-Rolls-Out-SaaS-Cloud-Security-Suite.htm

--
Regards
Vijayashankar

Project Methodologies

2010-07-28T08:42:00.001+05:30

Tips for Implementing Project Methodologies (found on the net)

"What is a methodology"?

A methodology is a step-by-step method for delivering projects. It describes every step in depth, so that you know what you have to do to deliver your project. By following the same steps for every project you undertake, you'll save time and effort on projects.

"How do I select a suitable methodology?"

The first step is to define your requirements. You need to think about what it is that you want from your methodology, the type of content it should contain and the way in which you intend to use it.

For instance, your requirements might be as follows:

It needs to contain a complete Project Life Cycle
Every step in the life cycle should be described in depth
Each step should have practical templates and examples to help to complete the step quickly and easily
It needs to be based on worldwide project standards
It should suit all project types and sizes
It should be easily customizable.

The next step is to review the methodologies used currently by your organization. Why reinvent the wheel if you have something that works in-house? Look at every methodology used and compare them to your requirements to see if there is a good fit.

If there isn't a good fit, then you need to look at purchasing a suitable methodology toolset. Start by searching the term "project management methodology" in Google and comparing each methodology you find against your requirements.

If you find a methodology that has an 80% fit, then that's great. Just make sure you can customize the remaining 20% to meet your requirements.

Where you can't find a suitable methodology toolset, your only option may be to develop a methodology from scratch. This will be more time consuming and expensive than adopting an existing internal methodology or purchasing a third-party methodology.

"How do I implement my selected methodology?"

Whether you've purchased or built your methodology, the next step is to implement it for your organization. This involves:

Creating an Implementation Plan.
Customizing your methodology for each project.
Training your team to use the methodology.
Making sure your team follow the methodology.
Constantly improving the methodology.

Scrum Methodology

2010-07-19T11:13:00.001+05:30

Agile is the best methodology, while I have mastered scrum based on the patience and intelligence of the people involved.

Some info from Wiki would be very helpful here.. ( referencing with a link )

Here is a good article you should not miss. Excellent.
http://martinproulx.com/2009/07/02/what-is-scrum/

Software Technical Architect

2010-07-16T11:05:00.001+05:30

From a business-centric perspective, architects should be corporate assets, not code designers. There are five dimensions to a software architect role: 1. technology 2. consulting 3. strategy 4. organizational politics 5. leadership Technology should consume perhaps less than 20% of an architect's day. Projects don't fail because of bad design or ugly code or improper/inefficient testing or even a wrong choice of technologies. There is no such thing as a perfect technology for a task at hand, only bad leaders and poor visionaries. The above mentioned are but consequences of poor organizational choices and a lack of focus. And patterns? They are but a convenient communication framework of the day. Should we know it as architects? Yes. At least we should know where the repositories are, and how to look through the repositories for a match with a task at hand. Frameworks change. For example, is MVC in Struts really M-V-C? Some people would say no. Unfortunatelly, those are few in between, for Struts rules. Oh no, or is it AJAX that rules? Or maybe SOA and REST and web services? No, no, it's OOP and generics, and AOP. One interesting thing happened with software engineering after WWW hit the mainstream. Some became gods in their own minds, and everyone became an architect. Vanity rules, and it will come to bite the software industry worse than the dot.com crash did. For Bankers are not a very patient bunch. Remember Occam's razor. "one should not increase, beyond what is necessary, the number of entities required to explain anything." That's wisdom. Now, you Mr./Mrs. Architect, who got bitten more than once by your own vanity and have learned some valuable life lessons, you go and explain this to a young hotshot who thinks he's got it all down after two books read and three projects completed and left for someone else to maintain. Someone should teach a class titled: "History of software art" and make it a mandatory read.

From a career path perspective, the role of an architect progresses from developer, senior developer, solution architect and architect. Sometimes a senior developer can jump few steps and become an architect based on varied skills and experience. So, asking questions in core java tests if the candidate has followed a career progression path. Next, there are several types of architects in IT, not just J2EE architects. One can be a data architect, application architect, solution architect, operational architect and so on. These roles may or may not exist in all companies and some roles are combinedly assumed. When selecting an architect, it is important to test several areas right from business and functional requirements to troubleshooting a deadlock issue in a distributed transaction and things in between. Architects should have all skills. Most important thing is the ability to research and development, which is true particulalry in this age of "pattern a week, language a fortnight" (Patent Pending :-)) type of discoveries. This proves, the would be architect has 360 degrees experience gained the hard way in IT shops.

The scope of assessing an architect varies based on the role he/she is likely to play(Application/Domain Architect, Solutions architect and Enterprise architect). So mere asking some technical questions like final, finally and finalize will not help to select a good architect. Questions like the below one might be more practical:
For an Application Architect : 1. Give a project requirement and ask him to depict the Application and System Architecture models then start ur question based on it... that will give a good idea.
2. All NFR questions.
3. Design methodologies used, issues, solutions.
4. Give a scenario ask them to design... - classdiagram, seq or deployment or component etc...
5. Questions on design patterns
6. Question on Team lead and peer interaction, presentations.
For a Solutions Architect: Questions about the project dependent items - like Infrasture team, security, development team - should be asked.
For an Enterprise Architect: 1. governance capabilities
2. Future roadmap
3. procurement
4. compare products
5. Business Interaction for new proposals and vicecersa

Wish you good luck in your recruitment now in future.

Business Objects v/s Microsoft BI

2010-07-02T10:00:00.001+05:30

Business Objects (BO) is platform agnostic and so is MS BI to a "certain" extent. In BO, you can build a semantic layer (named Universe) and hide technicalities from the users. Users in turn can build their own reports using this semantic layer using a module called Web Intelligence or WebI (thin Client over the web). What makes the semantic layer so powerful is that it hides core stuff from the end user and you as a designer / architect give meaningful terms within the semantic layer which is visible to the end user. Security can also be built into the semantic layer. In MS BI, there is no such thing as a semantic layer. You build a report using SQL or a Stored Procedure and publish the report which can then be consumed by the end user. Both technologies allow report scheduling and delivery in various formats (Excel, PDF etc.,) although BO I personally like BO's report delivery mechanism.

BO supports report bursting (only relevant people can see relevant data), although, report bursting is not to be confused with security. MS BI has no such feature yet. (MS BI is still evolving in comparison with BO)

BO WeBI reports can highlight data changes between various refreshes, MS reports cannot.

MS BI includes OLAP technology. In BO, you can expose the OLAP DB as a universe to the end user. MS BI allows end users to access OLAP cubes via Excel Pivot tables. This is an excellent and an extremely powerful medium, especially to end users who love MS-Excel.

As for costs, BO is fairly expensive (depends on the licensing model and based on the modules you select such as Dashboarding, Scorecards, OLAP, Web Intelligence etc.,) MS BI can also be fairly expensive and if you are licensed to use the Enterprise edition of the SQL Server Database, you get OLAP, Reporting services as part of the package.

BO is fully supported on VMWare platform thus reducing the cost of running it on a physical server. This also helps you recover and be up and running quickly in case of a disaster. MS technology on the other hand does not explicitly support its DB / infrastructure on a VMWare platform since MS-HyperV is MS's own virtual technology. Installation wise, BO is a little involved than MS.

MS BI Includes an ETL layer called SSIS (SQL Server Integration Services) which you can use to get data from heterogenous systems. SSIS is part of SQL Server Enterprise edition and you don't pay extra for it. BO has its own ETL layer called Data Integrator and you pay extra for it since it is not bundled with BO.

There is always a learning curve with any BI tool, be it MS tools or BO or Cognos etc., MS technoloogy in my opinion requires a technical person to build reports for end users. With tools such as BO or Cognos, you build the semantic layer and using which an end user can build many reports. One very important point to remember when you build BI / DW subject areas for your company, please ensure your end user needs are met. "You build it and they will come" approach will not work, especially with a BI implementation.

The key benefits of the MS stack is a consistent security model and the ease (from a developer standpoint) of creating solutions. It is not easy for end-users to create or derive information and reports without the involvement of IT.

The key benefit of the BO stack is "ease of use" from an end-user perspective (with minimal training and Web Intelligence, end-users can be very "productive".

I put these in quotes because with the universe model (or a semantic model from other vendors... this is not a BO-only problem), it is as easy for end-users to get the wrong answer as it is for them to get the right answer. There is almost no way for end users and it is very difficult for IT professionals to understand why they got the right or wrong answer. Because everything is hidden behind the Universe model, tracking from a report back to the base data is a non-trivial task.

The security model under BO is highly fractured. Universe-level security bears no resemblance to report security which bears no resemblance to database level security which bears no resemblance to portal-level security. You have to get all these right to keep your data secure.

Because BO relies on other vendors for the data store (this may change now that SAP owns Sybase), performance tuning is also highly complex. There is no facility for aggregation (like Analysis Services or other OLAP platform). In order to get pre-aggregated results, you have to work with DBAs to manually create aggregation tables and integrate them into the Universe.

Managing and maintaining BO is also very convoluted. You have to understand that it is an amalgamation of products from Business Objects (prior to the SAP acquisition), Crystal Reports (prior to the SAP acquisition, CR was acquired by BO) and other vendors. They each have their own vision of security, management and administration. Then there is the data-store level (see above).

You need many disparate skills to do a full BO implementation.... Universe modeling/design/implementation, data warehouse modeling/design/implementation, Java skills, Tomcat (or other J2EE platform), security (AD integration is problematic, integration with other LDAP platforms is a nightmare).

Overall, I prefer the Microsoft stack. I acknowledge that it takes more effort from IT to get a set of reports going and new reports often require someone from IT be involved, but overall it is a more managable, more secure and less expensive solution. I see Business Objects as a consultants dream.... an endless font of billable hours.

While I agree with Philo that SSAS is an aggregation layer between transactional data and the business user, it is absolutely not a semantic layer.

A semantic layer provides translation services between an underlying data store and business-level language (the business semantics that end users will be familiar with). BO's Universe semantics layer does the translation between a business semantic (an Order, an Employee, a Line Item, etc) and the underlying data store (tables, joins, aggregation tables, etc).

Licensing and hardware costs fall under the heading "initial acquisition costs". Throw in the consulting and knowledge transfer costs (training, etc) and that will give you a pretty complete idea of what the initial costs will be for a solution (Business Intelligence, Data Warehousing, ERP, CRM, buying a car, buying a house, etc)

In any IT project, the bulk of the costs are day-to-day operations over the expected life of the solution (generally 3-5 years). Initial costs may be as little as 10% of the overall costs.

I'd rather spend $100,000 initially on a system that will cost me $500,000 over the expected life of the solution than $75,000 initially on a system that will cost me $750,000 over the life of the solution.

Yes, there are budget realities to be considered (I may only have $75K in my budget this year and no chance of getting the $100K... but amortizing the higher cost into the future may be acceptable).

What I like about the Microsoft stack is I can leverage skillsets that I already have in-house (SharePoint, Windows Server, SQL Server, .NET developers). With BO, I would need headcount dedicated to BO (Universe design, implementation, maintenance, security). Since BO skils are not generally transferrable to other skills I need, those extra heads blow the budget for me.

Webspam Projects?

2010-06-30T20:59:00.001+05:30

Reading an interesting article, I was amazed by the accuracy of Matt Cutts, the guru of online marketing and SEO, one year back.

http://www.mattcutts.com/blog/webspam-projects-in-2010/

Short, but Matt suggests the direction, what Google should look into.

--
Regards
Vijayashankar

Project Manager Vs Program Manager

2010-06-27T07:24:00.001+05:30

First of all who is a Proect Manager? S/he is one who execute a given project ( software or collection of activities ) in a systematic manner. Tracks and assigns resources. Take care of reporting the progress and ensures the deadlines.

So, project managers are the delivery managers who deliver specific deliverable's. They tend to be a member of the department which is responsible for that specific deliverable and have the necessary technical expertise. Delivery level managers, however, do not report to the PMO but to the respective line managers.

Program managers are assigned from PMO to ensure proper alignment between all project managers, and are responsible for:
(1) single view of the program; being the single point of contact and managing the central depository of information & status on the project
(2) hold the program plan integrating all project level plans, all inter-dependencies, all inter-project commitments and track them to resolution
(3) guide the program through the initiation phase; explain the strategic aim & business case to all stakeholders & project managers; organise kick off meeting
(4) determine the structure to run the project (incl which coordination meetings to be held), which could change during the course of the program; the governance structure; and the communciations plan. Eg, when we launched four major products for the World Cup recently, they can't all have their own separate marketing plan, leading us to have one marketing & communications workstream for all products within that program. And of course, one software project manager may be delveiring for more than one product and each product may require more than one software project manager's delivery.
(5) evaluate all information & development arising externally or from the projects and escalating to all appropriate persons for attention and/or action
(6) identify program level risks and issues (as distinct from project lelve risks); these largely arises from coordination & alignment, or strategy & benefits management
(7) render a single reporting to any stakeholder and senior management, aligning project level documentation & methodology where appropriate
(8) monitoring progress and removing roadblocks to implementation, especially with regards to process (getting procurement to send out a particualrly problematic PO) and project communications
(9) ensure benefits tracking is set up and, most importantly, organise the closeout party

I think that is about it. Based on this, the program manager will require the following skills:
(a) analytical skills to make sense of all information and reducing them into a single coherent picture
(b) strategic awareness as he/she will be the only person ensuring alignment of all efforts towards the strategic aims, while everyone is focussed on delivery
(c) interpersonal skills as you are getting information and delivery through other people
(d) communication skills as the single reporting goes out to so many disparate people (from CEO to technical delivery), there are so many different angles from which people can misunderstand.

--
Regards
Vijayashankar

Cloud Computing in Detail

2010-06-13T18:50:00.002+05:30

Cloud computing is heralded as the next big thing in enterprise IT. While corporate data centers and on-premise software are not going away anytime soon, "the clouds" will likely have a growing impact on enterprise IT and business activities in many large organizations. CIOs and other business leaders must look beyond the hype to see what opportunities and challenges lie in the cloud—and how this approach can be used to further the organization's strategy to achieve high performance.
Cloud computing is a classic disruptive technology. As such, it has its origin in the fringe of the IT market, i.e., the small and medium-sized enterprise (SME) and consumers, whose need for simpler and lower-cost or even free solutions is underserved by traditional packaged software. As cloud-based services matured, they started to win broader acceptance from mainstream enterprise customers. Now, they compete directly with on-premise and packaged software. The significance of the cloud, however, lies far beyond cheap computing. The Web-enabled, variable cost model represents a huge departure from existing practice, and carries far-reaching implications for IT providers and users alike. A new wave of venture-funded startups are likely to appear, offering an array of innovative solutions ranging from niche applications to cloud middleware and infrastructure services. The emergence of cloud platforms will significantly ease the entry barrier for such small players to develop, deploy, scale and integrate their services. The battle between pure Internet players like Google, Amazon and Salesforce and traditional enterprise vendors has just begun. Incumbents such as SAP, Oracle, and Microsoft have been investing aggressively to extend their on-premise capabilities into the cloud. For example, Microsoft has launched online services to offer its software in the cloud. It is also investing billions in datacenters to help confirm quality and availability. Microsoft has developed a Software + Services hybrid model to offer its customers a choice between on-premise, partner-managed or Microsoft hosted solutions.

One of the key challenges of cloud computing, which is defining successful business models and architectures for value creation in the enterprise. At this nascent stage both SMEs and large enterprises are just beginning to adopt cloud technologies, as CIOs and IT managers learn about how they can deploy the cloud in their organizations it will create business opportunities for startups and entrenched players to develop business models that are successful in serving their customers as well leading to the success of their own companies. .

So contact us for paid consultation.

--
Regards
Vijayashankar

Startup biz and development

2010-05-18T10:08:00.002+05:30

Nowadays you cannot run a startup in the garage mode. They say, if you code in a product, and lucky you get the rewards.

If you think about and are talking some bare min stuff - Doesnt work!

You cannot sell out! I remember the same suggestion people in 2000! I cut risks under a year after

starting the angel funded B2B messaging product and bailed out in 2002, when cash dried!

At least my plan is not to run a bareshell minimum garage startup now.

For 1 yr, you need 1 mil$. I had budgeting task as well in my prev job. I handled the center as P&L. Indian cars portal costed 6 crores on paper when the launch was done, in 9 months.

I will buy legal SW. Also there would be some advt. Decent office space cost a bit. A full page India wide advt in TOI or Hindu would cost 10 lakhs and above.

Local server would cost at least few lakhs plus the hosting costs. The biz in on net! Reliance quotes a 2MBPS line at 15 Lakhs a yr with dual loop 24x7

guarantee. VSNL might quote 8 lakhs.... reason, multi GB data transfer, with images, walkin video of properties...

I would hv to sustain for a year, with staff. I have seen some space for Rs 30 to 40 k for bare shell. It costs money for a decent fitting. Employees need a cozy setup.

There is huge overhead on running costs. I need some smooth talking, glib lingua MBA's for marketing.

No investor, is willing to invest risk capital in India now. Last time I got decent sum. Not the second round. This time I have commitment by friends for 25 lakhs. But wont help. Anyway once and angel comes in, much would come in trenches fro a stake.

PSG Tech park, Coimbatore costs about 15 Rs/sqft only. But still you have to spend on furniture and systems alone. They also have a per system plan. But if you are talking of customers visiting you, forget it. That idea works only, if you want to hack code. Not for a office presence. But you need to be in Bangalore / Chennai / Hyderabad...

Once the product is stable, I have plans of having some other development too.

A ordinary ink filling station franchise is costing upto Rs 6 lakhs, plus space cost. You might get some return, if you are lucky!

Recently I spoke to one guy, who is out of job for sometime, probably he could code. When I told him the idea, he wants a stake in the co. to work rightaway - not ESOP!

Well, people dont know how to value an idea or a startup biz.

Here is my usual pitch!

The idea is a portal biz, customised portal for each seller as a SaaS ( Frontend + backed CRM + eDataCenter ). Not something like a pure classifieds framework like indiaproperty.com, magicbricks.com or makaan.com

In USA, in time of adversities, online selling was at its peak, particularly auto.

I have 15 months of online portal related with selling, experience.

Also I rolled out Indian cars portal in India, they have 300+ individuals signed up as partners with a 6 crore t/o, probably doubled in 1 year time.

Investors are ready to buy out the concept, if there is working SW...

Many VC's say show me the working product.

Well even to develop that I need space, people and money. Only a part of the development is complete @50%. I need minimum Rs 5 crores to sustain for 1 year.

That would wipe out my entire net worth, if I were to invest myself.

I have a plan to develop it in 6 months with about 20 people. I can get it done with Open Source, and some Microsoft Silverlight stuff.

Ofcourse, the usual startup time - finding space, hiring - add 45 days, min. I can bring onboard some old hands, who worked with us.

Well it is very tough to find, people would would work for free (startup) but to gain exp. That is the option, many are approaching.....

--
Regards
Vijayashankar

Should Entrepreneurs Lie?

2010-04-14T18:05:00.001+05:30

An experienced VC fund manager I have known for years told me recently that if a person does not know how to seriously twist the truth from time to time, he (she) cannot be an entrepreneur.

I have had numerous conversations with entrepreneurs about lying. All are against it in theory, but in reality, most practice it to some degree. Some don't like the term "lying;" they prefer to call it stretching the truth, or even "marketing." But it's clear, many entrepreneurs feel they have to embellish or twist the truth, or outright fabricate some friendly "facts," to help level the playing field for their business.

Do you condone truth-twisting for entrepreneurs? Is scrupulously telling the truth a luxury that startups can't afford? If so, should we teach entrepreneurs when and how to lie or should we hold startups to the same standards as we now hold the most mature public companies?

Some years ago I worked with an entrepreneur who was raising his first $10 million of VC investment ("Series A"), without which the company could not proceed. One key element in the investment pitch was a strategic relationship with a multinational customer. The day before finalizing the investment, the customer announced that they were backing out. I advised my friend to inform his investors, but he chose to let them know at the first board meeting after the money was in the bank. I don't know how he told them, but there was no apparent negative fallout. Was I being naïve? "I might have lost the company if I had made a fuss over the lost customer." Today this venture has strong revenues, top-tier venture backing, and is a strong IPO or acquisition candidate. Was it acceptable for this entrepreneur to lie to save his venture?

I worked with another entrepreneur who had his marketing team print brochures for new products using language indicating that products had been installed and field tested, when they were still under development. American corporate customers treated this with understanding, but Japanese customers were horrified to discover that the product specifications were hypothetical, leading to a crisis in trust. Eventually the company went to NASDAQ. Should whether and how we lie depend on the culture we are working in?

Thousands of entrepreneurs knowingly inflate their forecasts expecting that investors will "haircut" these forecasts by at least half, certain that they will be penalized if they don't "play the game." As one pioneering and successful (another NASDAQ IPO) entrepreneur told me, whose actual sales were off his initial forecast by a factor of about 50, "We had no idea: this was an entirely new market, so we just put down numbers that the investors wanted to see." Is stretching the truth okay if the other side is expecting it?

One entrepreneur I know, whose FOPSE (For-Profit Social Enterprise) is in Africa, has adopted the "don't ask, don't tell" policy. He does not give bribes himself, but argues that, "we can only solve so many problems at once; I don't like it, but that is the way some — not all — countries here work." My friend structured pricing to distributors so that they had enough margin to make "facilitation payments" if needed. "Don't ask, don't tell" has been military policy for years: Is it good for startups?

When my two partners and I started our company, Triangle Technologies, in 1990, we stretched the truth about how many projects we had actually completed, and how successful they were. Over the years, we actually succeeded with enough projects that we could abandon the lying. It was a big relief. It was tempting to keep our marketing hype ahead of the reality, but gradually we felt that we could afford to be very strict about the truth. Is lying acceptable if you are committed to stopping when you can?

I don't have the right answers, but I do know that entrepreneurial lying (whether we call it marketing or raising capital or negotiating or selling the vision) is more prevalent than we care to admit. I have yet to see serious discussion of it in either academia or the real world.

So let's start it here: What do you think?

(c) Daniel J. Isenberg is a professor of management practice at Babson College

How does a PM differ from a TM?

2010-04-05T04:30:00.000+05:30

There are enough questions posted about the need of TM being a PM and PM also being a TM.

The confusion arises because of the misunderstanding of the roles and responsibilities of a PM. A PM is supposed to plan, manage and control the different aspects of a Project namely, Scope, Time, Cost, Quality, Risk, Human Resource and Communications (as per the PMBOK). So if we go by this standard also technology is not involved.

Taking it to the next level, a PM has to do all these project related responsibilities with the help of a "Team", and a Project Team according to me should be complementary to the PM and vice-versa. This team infact should have people expert and experienced in the technical aspects of the project (a Tech Lead, technical people like developers or testers or QA engineers etc).

As a combination these two (PM & Team) should work towards delivering the project successfully. You take any one out and the project is a disaster. Similarly you reverse the roles (a PM doing the Technical things; and the Team planning and managing the Project Scope, Risk, HR, Time, Cost Communication etc), and the project again will be a disaster.

The Deming System of Profound Knowledge

2010-03-29T06:20:00.002+05:30

The Deming System of Profound Knowledge

"The prevailing style of management must undergo transformation. A system cannot understand itself. The transformation requires a view from outside. The aim of this chapter is to provide an outside view—a lens—that I call a system of profound knowledge. It provides a map of theory by which to understand the organizations that we work in.
"The first step is transformation of the individual. This transformation is discontinuous. It comes from understanding of the system of profound knowledge. The individual, transformed, will perceive new meaning to his life, to events, to numbers, to interactions between people.
"Once the individual understands the system of profound knowledge, he will apply its principles in every kind of relationship with other people. He will have a basis for judgment of his own decisions and for transformation of the organizations that he belongs to. The individual, once transformed, will:

Set an example;
Be a good listener, but will not compromise;
Continually teach other people; and
Help people to pull away from their current practices and beliefs and move into the new philosophy without a feeling of guilt about the past."

Deming advocated that all managers need to have what he called a System of Profound Knowledge, consisting of four parts:

Appreciation of a system: understanding the overall processes involving suppliers, producers, and customers (or recipients) of goods and services (explained below);
Knowledge of variation: the range and causes of variation in quality, and use of statistical sampling in measurements;
Theory of knowledge: the concepts explaining knowledge and the limits of what can be known (see also: epistemology);
Knowledge of psychology: concepts of human nature.

Deming explained, "One need not be eminent in any part nor in all four parts in order to understand it and to apply it. The 14 points for management in industry, education, and government follow naturally as application of this outside knowledge, for transformation from the present style of Western management to one of optimization."
"The various segments of the system of profound knowledge proposed here cannot be separated. They interact with each other. Thus, knowledge of psychology is incomplete without knowledge of variation.
"A manager of people needs to understand that all people are different. This is not ranking people. He needs to understand that the performance of anyone is governed largely by the system that he works in, the responsibility of management. A psychologist that possesses even a crude understanding of variation as will be learned in the experiment with the Red Beads (Ch. 7) could no longer participate in refinement of a plan for ranking people."^[21]
The Appreciation of a system involves understanding how interactions (i.e., feedback) between the elements of a system can result in internal restrictions that force the system to behave as a single organism that automatically seeks a steady state. It is this steady state that determines the output of the system rather than the individual elements. Thus it is the structure of the organization rather than the employees, alone, which holds the key to improving the quality of output.
The Knowledge of variation involves understanding that everything measured consists of both "normal" variation due to the flexibility of the system and of "special causes" that create defects. Quality involves recognizing the difference to eliminate "special causes" while controlling normal variation. Deming taught that making changes in response to "normal" variation would only make the system perform worse. Understanding variation includes the mathematical certainty that variation will normally occur within six standard deviations of the mean.
The System of Profound Knowledge is the basis for application of Deming's famous 14 Points for Management, described below.

Key principles

Deming offered fourteen key principles for management for transforming business effectiveness. The points were first presented in his book Out of the Crisis. (p. 23-24)^[22]

Create constancy of purpose toward improvement of product and service, with the aim to become competitive and stay in business, and to provide jobs.
Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.
End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
Institute training on the job.
Institute leadership (see Point 12 and Ch. 8 of "Out of the Crisis"). The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.
Drive out fear, so that everyone may work effectively for the company. (See Ch. 3 of "Out of the Crisis")
Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
a. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
b. Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia," abolishment of the annual or merit rating and of management by objective (See Ch. 3 of "Out of the Crisis").
Institute a vigorous program of education and self-improvement.
Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.

"Massive training is required to instill the courage to break with tradition. Every activity and every job is a part of the process." ^[23]

Seven Deadly Diseases

The "Seven Deadly Diseases" include

Lack of constancy of purpose
Emphasis on short-term profits
Evaluation by performance, merit rating, or annual review of performance
Mobility of management
Running a company on visible figures alone
Excessive medical costs
Excessive costs of warranty, fueled by lawyers who work for contingency fees

"A Lesser Category of Obstacles" includes

Neglecting long-range planning
Relying on technology to solve problems
Seeking examples to follow rather than developing solutions
Excuses, such as "Our problems are different"
Obsolescence in school that management skill can be taught in classes^[24]
Reliance on quality control department rather than management, supervisors, managers of purchasing, and production workers
Placing blames on workforces who only responsible for 15% of mistake where the system desired by management is responsible for 85% of the unintended consequences
Relying on quality inspection rather than improve product quality

Deming's advocacy of the Plan-Do-Check-Act cycle, his 14 Points, and Seven Deadly Diseases have had tremendous influence outside of manufacturing and have been applied in other arenas, such as in the relatively new field of sales process engineering.^[25]

Quotations and concepts

In his later years, Dr. Deming taught many concepts, which he emphasized by key sayings or quotations that he repeated. A number of these quotes have been recorded.^[26] Some of the concepts might seem to be oxymorons or contradictory to each other; however, the student is given each concept to ponder its meaning in the whole system, over time.

"There is no substitute for knowledge." This statement emphasizes the need to know more, about everything in the system. It is considered as a contrast to the old statement, "There is no substitute for hard work" by Thomas Alva Edison (1847–1931). Instead, a small amount of knowledge could save many hours of hard work.

"The most important things cannot be measured." The issues that are most important, long term, cannot be measured in advance. However, they might be among the factors that an organization is measuring, just not understood as most important at the time.

"The most important things are unknown or unknowable." The factors that have the greatest impact, long term, can be quite surprising. Analogous to an earthquake that disrupts service, other "earth-shattering" events that most affect an organization will be unknown or unknowable, in advance. Other examples of important things would be: a drastic change in technology, or new investment capital.

"Experience by itself teaches nothing."^[26] This statement emphasizes the need to interpret and apply information against a theory or framework of concepts that is the basis for knowledge about a system. It is considered as a contrast to the old statement, "Experience is the best teacher" (Dr. Deming disagreed with that). To Dr. Deming, knowledge is best taught by a master who explains the overall system through which experience is judged; experience, without understanding the underlying system, is just raw data that can be misinterpreted against a flawed theory of reality. Deming's view of experience is related to Shewhart's concept, "Data has no meaning apart from its context" (see Walter A. Shewhart, "Later Work").

"By what method?... Only the method counts."^[26] When information is obtained, or data is measured, the method, or process used to gather information, greatly affects the results. For example, the "Hawthorne effect" showed that people just asking frequently for opinions seemed to affect the resulting outcome, since some people felt better just being asked for their opinion. Dr. Deming warned that basing judgments on customer complaints alone ignored the general population of other opinions, which should be judged together, such as in a statistical sample of the whole, not just isolated complaints: survey the entire group about their likes and dislikes. The extreme complaints might not represent the attitudes of the whole group. Similarly, measuring or counting data depends on the instrument or method used.

"You can expect what you inspect." Dr. Deming emphasized the importance of measuring and testing to predict typical results. If a phase consists of inputs + process + outputs, all 3 are inspected to some extent. Problems with inputs are a major source of trouble, but the process using those inputs can also have problems. By inspecting the inputs and the process more, the outputs can be better predicted, and inspected less. Rather than use mass inspection of every output product, the output can be statistically sampled in a cause-effect relationship through the process.

"Special Causes and Common Causes": Dr. Deming considered anomalies in quality to be variations outside the control limits of a process. Such variations could be attributed to one-time events called "special causes" or to repeated events called "common causes" that hinder quality.

Acceptable Defects: Rather than waste efforts on zero-defect goals, Dr. Deming stressed the importance of establishing a level of variation, or anomalies, acceptable to the recipient (or customer) in the next phase of a process. Often, some defects are quite acceptable, and efforts to remove all defects would be an excessive waste of time and money.

The Deming Cycle (or Shewhart Cycle): As a repetitive process to determine the next action, the Deming Cycle describes a simple method to test information before making a major decision. The 4 steps in the Deming Cycle are: Plan-Do-Check-Act (PDCA), also known as Plan-Do-Study-Act or PDSA. Dr. Deming called the cycle the Shewhart Cycle, after Walter A. Shewhart. The cycle can be used in various ways, such as running an experiment: PLAN (design) the experiment; DO the experiment by performing the steps; CHECK the results by testing information; and ACT on the decisions based on those results.

Semi-Automated, not Fully Automated: Dr. Deming lamented the problem of automation gone awry ("robots painting robots"): instead, he advocated human-assisted semi-automation, which allows people to change the semi-automated or computer-assisted processes, based on new knowledge. Compare to Japanese term 'jidoka' (which can be loosely translated as "automation with a human touch").

"The problem is at the top; management is the problem." ^[21] Dr. Deming emphasized that the top-level management had to change to produce significant differences, in a long-term, continuous manner. As a consultant, Deming would offer advice to top-level managers, if asked repeatedly, in a continuous manner.

"What is a system? A system is a network of interdependent components that work together to try to accomplish the aim of the system. A system must have an aim. Without an aim, there is no system. The aim of the system must be clear to everyone in the system. The aim must include plans for the future. The aim is a value judgment. (We are of course talking here about a man-made system.)" ^[21]

"A system must be managed. It will not manage itself. Left to themselves in the Western world, components become selfish, competitive. We can not afford the destructive effect of competition." ^[21]

"To successfully respond to the myriad of changes that shake the world, transformation into a new style of management is required. The route to take is what I call profound knowledge—knowledge for leadership of transformation." ^[21]

"The worker is not the problem. The problem is at the top! Management!" ^[27] Management's job. It is management's job to direct the efforts of all components toward the aim of the system. The first step is clarification: everyone in the organization must understand the aim of the system, and how to direct his efforts toward it. Everyone must understand the damage and loss to the whole organization from a team that seeks to become a selfish, independent, profit centre." ^[21]

"They realized that the gains that you get by statistical methods are gains that you get without new machinery, without new people. Anybody can produce quality if he lowers his production rate. That is not what I am talking about. Statistical thinking and statistical methods are to Japanese production workers, foremen, and all the way through the company, a second language. In statistical control, you have a reproducible product hour after hour, day after day. And see how comforting that is to management, they now know what they can produce, they know what their costs are going to be." ^[28]

"I think that people here expect miracles. American management thinks that they can just copy from Japan—but they don't know what to copy!" ^[28]

"What is the variation trying to tell us about a process, about the people in the process?" ^[21] Dr. Shewhart created the basis for the control chart and the concept of a state of statistical control by carefully designed experiments. While Dr. Shewhart drew from pure mathematical statistical theories, he understood that data from physical processes never produce a "normal distribution curve" (a Gaussian distribution, also commonly referred to as a "bell curve"). He discovered that observed variation in manufacturing data did not always behave the same way as data in nature (Brownian motion of particles). Dr. Shewhart concluded that while every process displays variation, some processes display controlled variation that is natural to the process, while others display uncontrolled variation that is not present in the process causal system at all times.^[29] Dr. Deming renamed these distinctions "common cause" for chance causes and "special cause" for assignable causes. He did this so the focus would be placed on those responsible for doing something about the variation, rather than the source of the variation. It is top management's responsibility to address "common cause" variation, and therefore it is management's responsibility to make improvements to the whole system. Because "special cause" variation is assignable, workers, supervisors or middle managers that have direct knowledge of the assignable cause best address this type of specific intervention.^[8]

(Deming on Quality Circles) "That's all window dressing. That's not fundamental. That's not getting at change and the transformation that must take place. Sure we have to solve problems. Certainly stamp out the fire. Stamp out the fire and get nowhere. Stamp out the fires puts us back to where we were in the first place. Taking action on the basis of results without theory of knowledge, without theory of variation, without knowledge about a system. Anything goes wrong, do something about it, overreacting; acting without knowledge, the effect is to make things worse. With the best of intentions and best efforts, managing by results is, in effect, exactly the same, as Dr. Myron Tribus put it, while driving your automobile, keeping your eye on the rear view mirror, what would happen? And that's what management by results is, keeping your eye on results." ^[2]

"Knowledge is theory. We should be thankful if action of management is based on theory. Knowledge has temporal spread. Information is not knowledge. The world is drowning in information but is slow in acquisition of knowledge. There is no substitute for knowledge." ^[21] This statement emphasizes the need for theory of knowledge (see: epistemology, Shewhart cycle, C. I. Lewis).

"The most important figures that one needs for management are unknown or unknowable (Lloyd S. Nelson, director of statistical methods for the Nashua corporation), but successful management must nevertheless take account of them." ^[22] Deming realized that many important things that must be managed couldn't be measured. Both points are important. One, not everything of importance to management can be measured. And two, you must still manage those important things. Spend $20,000 training 10 people in a special skill. What's the benefit? "You'll never know," answered Deming. "You'll never be able to measure it. Why did you do it? Because you believed it would pay off. Theory." Dr. Deming is often incorrectly quoted as saying, "You can't manage what you can't measure." In fact, he stated that one of the seven deadly diseases of management is running a company on visible figures alone.

"By what method?" ^[26] When information is obtained, or data is measured, the method, or process used to gather information, affects the results. Dr. Deming warned that basing judgments on customer complaints alone ignored the general population of other opinions, which should be judged together, such as in a statistical sample of the whole (Sampling (statistics)). Changing the method changes the results. Aim and method are essential. An aim without a method is useless. A method without an aim is dangerous. It leads to action without direction and without constancy of purpose. Deming used an illustration of washing a table to teach a lesson about the relationship between purpose and method. If you tell someone to wash a table, but not the reason for washing it, they cannot do the job properly (will the table be used for chopping food or potting plants?). That does not mean just giving the explanation without an operational definition. The information about why the table needs to be washed, and what is to be done with it, makes it possible to do the job intelligently.

How to Plan Your Projects

2010-03-24T16:09:00.001+05:30

It doesn't matter which industry you're in or project you're involved with, these 5 points should be taken every time to properly plan your project:

1: Set the Direction

Before you start out, set the direction for the project. Do this by clearly identifying the project vision, goals and deliverables. State the overall timeframes for delivery and clarify the amount of resource available. Determine what is "in scope" and "out of scope". Identify the benefits and costs in delivering the project and any milestones and constraints. Only once this is agreed with your Project Sponsor will you know what it is that you have to achieve.

2: Task Selection

You're now ready to start planning. Identify the groups of tasks that need to be completed to build your project deliverables. Then for each group of tasks, breakdown those tasks into sub-tasks to create what is known as a "Work Breakdown Structure" (WBS). Your WBS is essentially a hierarchical list of tasks, in order. Assign start and end dates to each task, as well as task durations. Always add a little extra time (e.g. 10%) to your durations, providing you with contingency. Next add Milestones to your plan. These are tasks that represent major achievements along the way.

3: Inter-linking

The next step is to add links (or dependencies) between project tasks. While there are a variety of link types, most Project Managers add "finish-to-start" links so that one task cannot start until another one finishes. To make your project achievable, only add links between tasks if there is a critical dependency between them. Remember, when one task slips, all tasks linked to it may slip as well. So use links wisely.

4: Resource Assignment

Now comes the fun part, assigning resources. A "resource" may be a person, equipment, location or materials. Against each task in your plan, assign one or more resources required to complete it. As you assign resources, watch your resource utilization. In other words, make sure you don't over-assign a specific resource to multiple tasks, so that it's impossible for that resource to complete everything assigned to it. So to make this easy for you, plan the resource utilization as you assign resources to projects.

5: Baseline, Actuals and Reporting

With a fully completed project plan, you're now ready to save it as a "baseline", so that you can later compare your progress against it. Then start recording your actual progress against the plan. Every day, record the amount of time you've spent against each task. Also record the new planned start and finish dates, and monitor the overall project completion date. Report on progress as you go. By regularly updating the project plan with your progress, you can control the delivery of your project and meet those critical goals set.

And there you have it. If you'd like smart software to help you plan and manage your projects online, use many online programs that is available, including EV graphs.

Project Managers view

2010-03-23T08:47:00.001+05:30

Here is something with Knowing.net on various technologies.

--
Regards
Vijayashankar

What does a Project Manager do?

2010-03-23T07:33:00.001+05:30

Better manage resources
Achieve results in the most efficient manner
Classify potential and real risk
Overall to Initiate, plan, execute, control, close & manage
To ensure that goals of projects are accomplished within prescribed time frame and funding parameters.
Project managers look to save time and money and improve quality.
Effectively manage complex projects in the best interest of their clients.

--
Regards
Vijayashankar

Product Manager

2010-03-18T15:22:00.002+05:30

Great Product Manager Questions

The Laudi Group and Red Canary organized and shared a great set of questions for product managers and answers from a panel of product management leaders. Steve Johnson, another leader in our space shared his answers to the same questions, and in this article, I share mine.

The Product Manager Questions

Hat tip to Steve Johnson at Pragmatic Marketing, for extending the discussion and providing his answers to the questions. And thanks to the folks at Red Canary and the product managers who originally shared their answers.
I really enjoyed reading their answers – thanks to all of you!
Here are the questions that were put forth and answered:

Tell us about the best product you've ever encountered. Why do you like it?
How do you know a great product manager when you meet one?
What's your favorite interview question?
When is the best time for a start-up to hire a product manager?
What has been the defining moment in your career?
Mistakes. What was your biggest?

I've personally enjoyed and grown from the great writing that many product managers have shared with us over the last few years. I'd love it if they would share their answers. So, either share your answers, or pester your favorite writers to share theirs.
Without further ado, here are my answers to the same questions.

Why Do You Like the Best Product You've Ever Encountered?

I love when products solve obvious (in hindsight) problems with elegant designs. The products where, once they exist, you say "well, duh" or slap your head and ask "why didn't I think of that?" These innovative products tend to be disruptive, redefining markets. Some of the products are rather mundane – like the ketchup bottle where the lid doubles as the base (reducing waste and preventing countless red-water-stained buns). Other products are more technology-dependent – like Tesla's radio, xerographic photocopying, solid-fuel rockets.
I think my favorite for elegant design might be Velcro – if you don't know how it works, or just want to know how it was invented, check out the wikipedia article. The time that parents save tying tiny shoes is value enough, but it is far from the only (or first) use of Velcro. An accurate clock that could be used on board a ship was a biggie too, although I never personally encountered one, at least when it mattered. Accurate time-telling on a ship was the key to dramatically improved navigation back in the days of sailing by the stars.

How Do You Know a Great Product Manager?

Great product managers are polymaths, with several areas of deep expertise and skill. They are Renaissance women and men, with many areas of interest. They are great communicators.
Most importantly, they are sooth-sayers. By the last, I mean that they not only understand the big picture and context of their markets and their business, but they know what is likely to change their business, and where their markets are sensitive to or ripe for disruption. One definition of sooth-sayer is "one who tells the truth." You can't do that without data, and the ability to understand what the data is telling you.
Add to this a dash of humility and a full dose of open-mindedness, and you have a great product manager.
Of course there's all of the esoteric skills that the role requires. When they aren't present yet, I feel like I've met a great product manager to be.
I know it when our conversation rambles all over, goes "depth charge deep" in areas, and then bounces back to the broad view, all with an eye for the relevance and insights that matter for the topic at hand.

What's Your Favorite Interview Question?

"Why?"
I almost don't care what the context of that question is – reviewing a candidate's previous experience, asking them to provide a "fresh view" on my current situation, or convincing them to dance through a hypothetical situation. What I want to know is why they think there is value, or a problem , or an opportunity, or … whatever. A collection of well-dispersed, and sometimes-immediately-sequential "Why?" questions can tell me more about how someone thinks, and more importantly, how they are likely to solve problems, create solutions, and dominate markets than any other question I've found.

When is the Best Time for a Start-Up to Hire a Product Manager?

Not counting the founder?
Three to six months before the first product peaks. All successful start-ups have one good product – solving a single valuable problem, for a single market. Most (my opinion / observation) start-ups don't have a second good product or market. A passionate and insightful founder can spend a long time understanding a market, a problem, and a solution. That knowledge and passion can yield a successful product. When is that founder, who is busy running the company, going to find a new problem to solve, a new market to dominate, or a new solution to replace his original idea?
Alternately, I guess the founder can hire someone else to run the company, and anoint herself "president of the product." That still counts as hiring a product manager.

What Has Been the Defining Moment in [My] Career?

Switching from electro-mechanical design engineering to software development. The shift in innovation time scales, the different approach to problem solving, and the markedly different economics of product creation had a profound effect on me. The evolution from "creating solutions to (defined) problems" to "identifying problems worth solving" was more gradual, as I evolved into a programmer-analyst and consultant and product manager.
"Going agile" half-way through my software development career was pretty eye opening too. I'll throw that in as my backup answer.

Mistakes. What Was [My] Biggest?

From someone else's perspective, it was leading a team down a six-figure software-development path that solved a problem no one really cared about. That's probably defining-moment number 3, when I started including validation of value as part of my scope of engagement as a programmer.
From my own perspective, as they say, it's the train you don't see that hits you. I'll guess that it was something I didn't do, not something I did, that would turn out to be the key plot device in my Frank Capra movie.
(copyright) as dictated and applicable

--
Regards
Vijayashankar

Do you want to jump in to the project management role?

2010-03-17T16:47:00.004+05:30

Here are some snippets for the Project leads and as well as for seniors who want to have a quick revision from project management interview perspective. Note, there is nothing like theoretical interview. Be practical!

It starts with basics of project management fundamentals like ROI, stake holders, MOU, SDLC, CAR, DAR, traceability matrix and then improve towards more sophisticated aspects. Defect density and Control Charts are few high level question areas.

Estimation is the most frequented section during project management interviews. You should be able to explain various aspects is dedicated to estimation. Ensure you understand the most used estimation methodology like COCOMO, LOC, Function points and Use case points. Most practical approach is WBS - work breakdown structure, or Delphi. Here the users / developers give the idea of development time, and you take the average of 30% + 70% of the worst and best timings estimated, as an example, that I have used.

Many project managers fall out when it comes to answer aspects on schedule management. Groovy area. Most of the times, the sales folks, would have committed to a date, even before you start. So you have to plan with loading of the project very clearly. Use many trainees as possible, which will not get affected in the GPM ( Pross Project Margin ) in a services company.You need to be thorough on schedule management covering fundamentals like EST, LFT, EFT, LST, PERT, GANT and Monte Carto. We are sure by knowing these fundamentals you can not slip. Make sure you understand Microsoft Project, even if you are managing through MS Excel!

You need to understand costing. It comes from the GPM, on the cost of project. You cannot spend more than what the project has been bid for. The costing management interview covers the most asked fundamentals like Earned value, planned value and Actual cost with some real examples. Read on risk management which covers basics like DR and BCP.

CMMI which has evolved as a very matured and standard process across IT industry is the biggest talk during project management interviews. Understand on CMMI covering maturity levels, staged and continuous representation, SCAMPI, PII and full details explanation of all CMMI KPA (Key Process Area).

Six sigma is catching up very fast in the IT industry and also one of the most frequented section during project management interviews. Understand the scope of various practical implementations in particular to the software industry. If possible, log on to net and join a Six Sigma group on Linkedin, Insidetech etc... You will get enough basics, and try to apply to various scenarios what you come across in a day to day work life. At least knowledge of six sigma is expected from any Project Manager.

Agile and XP has caught lot of attention in the recent times. Understand various topics like Agile, XP, AXEUM, FDD and LSD. Also do not forget the various development methodologies which was used in olden days, like Waterfall method, V curve method ( mostly for maintenance ) and the serial module development.

Go through standard templates and software by which you can gain an insight of project management tools.

Ensure that you read your resume thoroughly, where there are catchy words, and try to remember those, to answer well. Interviewer catch them fast, before you! So understand them well.

If you are just started applying, pass your resume to a good friend, or compare with his, by which you can get a fair idea of how to prepare a resume, if there are any mistakes and correct it before sending out in the market from a project management job perspective. At times, the consultant might suggest to add or update certain section to have the company short list you.

In short, here are the basic points you need to take care Resume Contents - Basics of Project Management - Risk Management - Schedule Management - Costing - Estimation, Metrics and Measure - CMMI - Six Sigma - Agile Development ( Methodologies ) and last but not the least, don't forget to say few things nice about your present / last company!

--
Regards
Vijayashankar

Ten Things Not To Do In An Interview

2010-03-14T09:43:00.000+05:30

1. Don't leave your cell phone on. "Don't even leave it on mute or vibrate - this is distracting to you and definitely rude to the interviewer," says Arlene Vernon, www.arlenvevernon.com, a human resources consultant.

2. Don't smell like smoke. If you smoke, make sure there's no evidence. This is especially important if you're interviewing for a position where you have direct contact with others.

3. Don't speak badly about previous employers or co-workers. Make sure you've practiced an honest answer but one that doesn't show that you're angry with the previous employer or circumstance.

4. Don't bring up personal information. The interviewer doesn't want to hear about your personal life or other information not related to how you can succeed at the job being interviewed for.

5. Don't focus on the salary and benefits. Joyce LeMay, an associate professor of business at Bethel University says, "The interviewer may be turned off and feel that you are only interested in what the company can do for you."

6. Don't fidget. Find a comfortable position in the chair you're offered and while you don't want to be stiff, you don't want to move around a lot. If you fidget with your hands, keep them empty. These nervous behaviors can hurt your image.

7. Don't ramble on. Balance talking and listening. Measure how long it takes to answer a question. Watch the interviewer's body language to see if you're going on too long.

8. Don't be late. Perform a test drive to the location a day in advance.

9. Don't tell the interviewer you have no questions. This shows a lack of interest, curiosity and depth. Have 5- 10 questions prepared, and it's OK to pull out the list if you need to.

10. Don't rush the interviewer. Never leave until the interviewer says it's over!

Saas is definitely better

2010-03-10T12:19:00.001+05:30

When I pressed send this morning on an email message, Gmail popped up a dialog box asking whether I'd meant to attach a file. "You wrote 'find attached' in your message," it gently mentioned, "but there were no files attached." Of course, as so often happens, I'd finished the message and pressed send without remembering to add the attachment, doh! I was really pleased and impressed that Gmail had added this gentle and oh-so-useful hint. It will save so many embarrassing resends, and thus go a small way to reduce the burden of overflowing inboxes in our lives.

The silent introduction of this reminder is a great demonstration of why SaaS is so much better than on-premise. The old way a feature like this used to be introduced was that it would get scheduled for release and you'd start reading about it for months before you actually saw it. The vendor would send out a press release about it, product managers would demo it at trade shows, journalists, analysts and beta testers would rave about it in reviews, and then finally it would show up on your shopping list. In large organizations it might be a five-year lag between the feature first being talked about and actually implementing it on a person's desktop (I know someone working for a large oil company head office who has just been redeployed to a hotdesk station that is still running on Windows 2000, believe it or not).

Of course, these days, it's possible for vendors to update on-premise software on an ongoing basis, through initiatives such as Windows Update (which I'm a great fan of) and Software Assurance. To be sure, too, it's not always so pleasant an experience as discovering the small Gmail enhancement I've cited. Murphy's law says that Windows Update will always have a big upgrade planned just at the moment when you most need to close your laptop and head off for an urgent appointment. And I was mighty irritated when I went to the search toolbar in Firefox yesterday to do a Google search and discovered that McAfee SiteAdvisor had silently installed itself as the default search engine and removed all other alternatives. Maybe that had been an accidental change made by my young son, who had been using the computer earlier, rather than an automated update, but it illustrated how disruptive it can be when an unbidden change upsets your work routine.

The fact remains, though, that the business model of on-premise software vendors is built around denying functionality to users until they can no longer resist paying for an upgrade. The success of this business model depends on spending large amounts on marketing so that users become aware of what they're missing. And of course it forces vendors to stuff the upgrade full of desirable new functions so that users can justify the cost and hassle of making the upgrade.

Whereas the business model of on-demand software vendors is built around supplying functionality to users of such pleasing utility that they remain content to continue paying their subscription, month after month. In my view, it's simply a far more elegant business model.

***

Contact Sharon Software Systems for your Saas needs.

How to Catch and Manage Innovative Practices

2010-02-26T20:32:00.000+05:30

Innovation happens at the boundaries of disciplines
Most innovation happens at the boundaries between disciplines or specializations. It is when people meet across the boundaries that new knowledge is generated or integrated and new innovations comes up. We know this, but we also know the relative complexity to manage innovative processes at a given boundary. The researcher Carlile has spent a lot of time in many papers to explore and investigate this complexity. We argue that by understanding this complexity we might be able to better manage these processes.
Carlile proposes that we should shed light on three different properties of knowledge at boundaries; difference, dependence and novelty (Carlile and Rebentisch 2003, Carlile 2004). Differences in knowledge refer to a difference in the amount of accumulated knowledge. And this is a dilemma. Creating a complex service (i.e. innovation), for example, often requires differences in the amount and type of knowledge. At the same time, practically, it means that different actors have different experiences, different terminologies, different incentives, etc. Furthermore, every actor has to re-learn. This might have a negative impact of the willingness of an actor to participate in an innovative process. Nevertheless, these processes need to be overcome.
The second relational property of knowledge at a boundary is dependence. To be able to manage innovative processes we need to take into account how different actors and their activities are dependent on each other. As Carlile (2004: 556) points out - “Without dependence, difference is of no consequence”. Dependence can, for example, be described in political terms, i.e. are actors willing to participate in innovative processes because of situated dependence? Furthermore, how will innovative processes change dependence between actors or processes?

The third relational property of knowledge at a boundary is how novel the circumstances are. As Carlile writes; “… the most challenging aspect of the relational nature of knowledge at a boundary is that for each actor there is novelty to share with others and novelty to assess from others.” To be able to manage innovative processes we must be aware of that when novelty arises there is often a lack of common knowledge to adequately share an assess knowledge at a boundary. An innovative thought might, for example, be regarded with suspicion and insecurity, not because the idea is not of great value, but that there is a lack of language to catch the innovation with.
Our approach and analysis may indeed be regarded as complex and abstract. However, by illuminating what happens at the boundaries between disciplines and specializations may help us to understand and develop an innovative climate in our organizations. By focusing on the three properties of boundaries we may open a window to further understanding about how the flux and flow of organizational processes can be arrested in concepts and translated into pragmatic use. What could be more instrumentally usable?
Recommended reading
Carlile, P., and E. Rebentisch (2003) Into the black box: The Knowledge transformation cycle, Management Science. Vol. 49, pp 1180-1195.
Carlile, P. (2004), Transferring, translating, and transforming: An integrative framework for managing knowledge across boundaries, Organization Science Vol. 15 No. 5, pp. 555-568.
Download
Read or download this article from Scribd.

How to become Better Qualified for career in Project Management?

2010-02-25T12:42:00.001+05:30

Project Management has evolved into a well defined discipline which requires the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. To be successful as a Project Manager, one must have very good understanding of all the Knowledge Areas*** related to Projects namely :

Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Project Human Resource Management
Project Communications Management
Project Risk Management
Project Procurement Management

Understanding the best practices in each of these knowledge areas and being well versed in the Project Management Context and Processes is essential for being a successful Project Manager.

It is highly recommended that every Project Manager should read the PMBOK^® 2008 (publication of PMI^®) which provides an excellent overview of the concepts mentioned above.

Taking the PMP^® Certification Exam is also highly recommended because PMP^® certification is the profession's most globally recognized and respected certification credential. The PMP^® designation following your name tells current and potential employers that you have a solid foundation of project management knowledge that can be readily applied in the workplace.

*** : As defined by PMI^®

Six Sigma SQC ControlCharts

2010-02-18T21:00:00.001+05:30

A control chart is a popular statistical tool for monitoring and improving quality. Originated by Walter Shewhart in 1924 for the manufacturing environment, it was later extended by W. Edward Deming to the quality improvement in all areas of an organization (a philosophy known as Total Quality Management, or TQM).

Try our control chart calculator for attributes (discrete data) and control chart calculator for variables (continuous data).

The purpose of control charts

The success of Shewhart's approach is based on the idea that no matter how well the process is designed, there exists a certain amount of nature variability in output measurements.

When the variation in process quality is due to random causes alone, the process is said to be in-control. If the process variation includes both random and special causes of variation, the process is said to be out-of-control.

The control chart is supposed to detect the presence of special causes of variation.

In its basic form, the control chart is a plot of some function of process measurements against time. The points that are plotted on the graph are compared to a pair of control limits. A point that exceeds the control limits signals an alarm.

An alarm signaled by a control chart may indicate that special causes of variation are present, and some action should be taken, ranging from taking a re-check sample to the stopping of a production line in order to trace and eliminate these causes. On the other hand, an alarm may be a false one, when in practice no change has occurred in the process. The design of control charts is a compromise between the risks of not detecting real changes and of false alarms.

Assumptions underlying Control Charts

The two important assumptions are:

The measurement-function (e.g. the mean), that is used to monitor the process parameter, is distributed according to a normal distribution. In practice, if your data seem very far from meeting this assumption, try to transform them.
Measurements are independent of each other.

Constructing a 3-sigma ("Shewhart-type") control chart

During a stable stage of the process:

Determine the process parameter that you want to monitor (such as the process mean, or spread).
Create the centerline of the plot, according to the target value of your monitored parameter.
Group the process measurements into subgroups (samples) by time period. The points to be plotted on the plot, are some function of the process measurements within each subgroup, which estimate the target value.
For example, if you are monitoring your process mean, then the points on the plot should be the sample-means, computed at regular intervals. Denote the point at time t as X_t
Create upper and lower control limits (UCL,LCL) according to the following formula:
UCL = CL + 3 s
LCL = CL - 3 s
where s is the standard deviation of X_t.
For the example above, X_t may be daily means of process measurements. If each daily sample comprises of n measurements, then the standard deviation of X_t is equal to the process standard deviation divided by the root of n

After the control limits have been set, continue to plot the points on the graph, as a function of time. When a point exceeds the control limits, it indicates that the process is out of control, and action should be taken (of course, there is a slight chance that is is a false alarm).

An Example

To give you a feel of this statistical terminology, imagine a process that produces soap bars. The production manager wants to monitor the mean weight of soap bars produced on the line. The target value of a the weight of a single soap bar is 100 gm. It is also known that an estimate of the weight standard-deviation for a single soap bar, is 5 gm.

Daily samples of 10 bars are taken, during a stable period of the process. For each sample, the weights are recorded, and their mean/average is computed. The sample means are estimates of the process mean.

The monitored parameter is the process mean.
The center line in this case will be equal to 100 gm (the target).
The points on the plot will be the sample means (where each sample consists of 10 measurements).
The control limits are given by 100 ± 3 · 5 / root(10)

Sensitizing rules for control charts

The American Standard is based on "three-sigma" control limits (corresponding to 0.27% of false alarms), while the British Standard uses "3.09 sigma" limits (corresponding to 0.2% of false alarms). In both cases it is assumed that a normal distribution underlies the relevant estimators.

It has been shown that Shewhart-type charts are efficient in detecting medium to large shifts, but are insensitive to small shifts. One attempt to increase the power of Shewhart-type charts is by adding supplementary stopping rules based on runs. The most popular stopping rules were suggested by the "Western Electric Company" ("WECO"). These rules supplement the ordinary rule: "One point exceeds the control limits". Here are the most popular Western Electric rules:

2 of 3 consecutive points fall outside warning (2-sigma) limits, but within control (3-sigma) limits.
4 of 5 consecutive points fall beyond 1-sigma limits, but within control limits.
8 consecutive points fall on one side of the centerline.

An online calculator for the Western Electric Rules is available here.

Scope Creep

2010-02-14T11:56:00.002+05:30

Typically Scope Creep affects all kinds of projects.

This can be solved in many ways.

For every project, the basic clarity should be there in the requirements. Written and well documented.

Such strong conviction, of not going overboard on required, will cut down cost over runs.

Any creep of requirements ( customers will always try to add new requirements, after signing the project dev. ) should be well documented and charged. Certain companies I have worked with have the policy of charging ( change management ) only if there is excess of effort > 10% expended, as there is always a buffer of 10% added in the initial quote.

***

I was reading an article now Managing Project Profitability and some points are well written, that can be used in any typical IT project implementation ( & management ).

--
Regards
Vijayashankar

SCAMPI LA

2010-02-11T17:25:00.001+05:30

Hi All

I am looking for an opportunity and if you know any best fit, in the field of Delivery / Project Management, do refer me.

I have closer to 2 decades of experience in the IT industry.

Thanks.

Here is my profile.

Regards
Vijayashankar

eCRM Software and beyond

2010-01-03T09:35:00.000+05:30

Sharon Software Systems has developed full fledged software solutions - eCRM to cater to many business and eDatacenter along with a classifieds framework, exclusive for B2C customers. This is being projected to be used for out venture Indiarealestventure, a realty portal venture in a box. We are also coming up with few other ventures in the Saas model, where the user ends up paying, for a monthly use, with a small commitment. There will be a dashboard concept, where even other vendors can provide combined, seamlessly working application for a given customers need. I am in the process of patenting this.

There are many questions raised by the investors on why, how and where our solutions would be used, and what the benefit is going to be.

Today cloud, distributed servers and internet, with powerful wireless networks bring the office closer to anyone on the move, and the customer would expect the business to be closer to them as well.

CRM is something that is not restricted to any country or culture. Wherever customers are there, businesses cannot afford to keep them unhappy and that is where CRM comes in as a very strong requirement.

In India, the trend is positive. When compared to about few years ago, people have more choice and every company knows it can’t take customers for granted. May be the movement is slow, but we see a steady progress towards an increased focus on the customer, rather than merely on the products and price.

Recently, everyone gets to notice concepts like loyalty program's adopted even by our new departmental grocery chains. Earlier, loyalty was taken for granted if good products and services were provided. But now, that is no longer the case, and companies are trying hard to win the customer’s heart, not just his purse/money. In the process, both the customers and CRM are getting the attention they deserve and hence the business improves and grows. Mutually rewarding for both.

Innovation can help any business grow. CRM can help businesses in many ways. To start, when somebody calls you or drops in at your office, do you know everything about him or her? That can be a good beginning, and knowing fully about a customer (or a prospect) is something that is always going to help us in suggesting products of interest to them.

Next, the services area. Many great Indian companies are known to be poor in providing support. Here again CRM concepts and tools can help.

Modern Indian businesses are definitely keen on implementing CRM concepts in their day-to-day operations. For example, a bank started providing 'Platinum', ‘Gold’, ‘Silver’ cards to its valued customers, and depending on their status the customers get faster services and better rates and best rewards. The customers were happy, and the bank spent time with the right customers, prioritising well, and proposing things that are more likely to be accepted by the target audience.

CRM success metrics differ for each industry. The most common ways of measuring CRM success are: increase in the number of leads, for a sales organisation; and the average time spent on each call, in a service organisation. Airlines and Travel industry see the immediate results. No seat can be left unsold, if you know the customer looking for it. That is why we came up with the Saastravel.in venture.

Any organization, if it uses our own CRM implementation, we can see an immediate improvement of 25 per cent increase in the number of leads that got converted to orders.The broad based experience of the founder, working in an Automotive portal business, with low volume and high margin, has given enough insight to assist with brick and mortar business.

Though each organization has its own way of measuring CRM effectiveness, in general, organizations feel there is a definite value-add from CRM in the long term. According to Harvard Business School study, ‘Companies that put customers in the center are 10 times more likely to achieve growth goals.’ And CRM is a great tool to make that happen.

First of all, many people assume that CRM means a software package. You buy it paying huge chunks of money, and then it takes care of your business. No we beg to differ. It is not like that. Unfortunately, life is not a well laid out plan. Here we have to do the work, and software is just a tool, to support us. The tools to improve business comes along all the way!

CRM is more a business concept, and it is left to our creativity how we want to use it. You don’t need fancy software to support your CRM efforts, even though one such software would definitely help doing things faster.

For example, recently, I was visiting a self service hotel, that was very crowded. I was very worried whether we would get out plate meals. Should I have to return hungry or go to the nearby hotel? At that time, the bill cashier looked at me and asked, ‘How many meals you want Sir?’ I gave my order, and knew that we would be served in due course.

All this time, he was busy working on taking so many peoples order. Once he took the interest in me, I was no longer worried about waiting, because he had given me an impression that things are moving and we would be served. Life is not just make believe, real service is needed. Later, I observed that he was doing so for almost every new customer. Interestingly, nobody did mind waiting, after all that was small trick - best practice any business can use.

Note this hotel doesn’t have any CRM software, but still he is able to apply its concepts in his daily work. That is the power of creative CRM, and there are endless possibilities of what you can do with it.

The second popular CRM myth is that all CRM implementations are costly and they take a long time. It is not only companies with deep pockets can afford to go for CRM implementations.

May be this was true a few years earlier. Now, CRM is slowly making headway for SMEs (small and medium enterprises). This is a positive trend we are seeing in the last few years, and expect this will be of interest even to big enterprises, to save their overall cost of CRM implementation.

SaaS (Software as a Service) is a big trend now. That's why Sharon Software Systems is coming up with ventures catering to this domain. We specialise in SaaS-based CRM solutions, both in our products and services. What SaaS is doing now, is to bring CRM to the masses, and the SMEs.

People who believe in CRM’s power, but can’t (or don’t want to) spend a whole lot of money immediately on that, can start by subscribing to CRM services, which are available for as low as Rs 500 or US $ 10 per month per user, with a small plan commitment. Thats all. Once the hardware is setup, the software comes almost for free, just like paying the annual maintenance contract.

These provide a good start. You can use them and see the value. Once you like it, or when ready for the next level, you can move to the more advanced services, or even a pure portal hosted solution, with intranet and cloud for internal services.

For example, many educational institutions in the US and Europe are now using CRM to track their current and potential students. They start with simple things, such as course registration, and slowly increase their CRM bandwidth. Also they can target the particular country with better seminars, to brings students on board.

This model is perfect for India, owing to the economics. SaaS provides companies with the luxury of sampling at a relatively low cost. The CRM solution can, accordingly, grow with the company.

CRM as a business is worth about Rs 50,000 crores or $50 billion in India, if you see that the service Industry has a turn over of Rs 500,000 crores annually, considering 10% IT spend. No wonder there was Service Tax introduced in 2004 to garner more revenue for the Indian government.

But this is a kind of unclear number because it includes CRM products and services in the traditional sense, and also the related IT enabled services.

Big players in CRM such as Oracle are very enthusiastic about CRM’s growth potential. Almost every major corporation is introducing its own CRM version, to get a part of the CRM pie. And the latest on the bandwagon is the biggest one, Microsoft, actively promoting the ‘Microsoft Dynamic CRM' and host of other services.

In general, the CRM market is buzzing with activity. Market leaders like Siebel and SalesForce.com are still strong, despite tough competition from new players. We in Sharon Software Systems, have the knowledge and bandwidth to match the big players service quality and products.

Industry interest reflects in the media’s coverage of customer relationship topics. Business schools are gearing-up to teach CRM basics to the next-generation professionals. Because of huge CRM implementations, and their direct effect on the business, end customers are also becoming aware of the change, and have started expecting more.

Everyone asks CRM is intruding into people’s privacy?

The other day, I was making a phone call to an Pizza store. A guy picked it and said, ‘Hello sir, you are so-an-so, you purchased a special Pizza last time, can I give the same npw?’

This, right in the beginning of conversation, had taken me aback. We all know a CRM tool can match my phone number with their records and flash all the details on the monitor, and one can just read out from the screen. But the leery feeling that somebody is watching my orders and tracks after a month makes me scary! This has to be solved. I also wondered, whether they sell my data to others, based on affluence, imagining that only certain set of customers, can be looked at to sell some other service. Which in a way is OK. But it has to come from the consent of the customers, themselves. Many online subscriptions track these habits. This has to evolve. That is where our software solution comes into play.

Such problems can occur when you go too aggressive on CRM. The challenge is to find the right balance, and work in such a way that the customer is happy with the service, as well as the way we manage the relationship.

Happy New Year

2010-01-02T11:57:00.000+05:30

Happy New Year 2010

Happy New Year

2010-01-02T11:46:00.000+05:30

Happy New Year!

Happy new year 2010

2010-01-01T21:43:00.002+05:30

Happy New Year!

PMP test and experience

2009-12-31T21:07:00.001+05:30

Found on the net, but didnt find it that useful but worthy reading.

1. Take test preparations seriously. This test demands respect; it is not a walk in the park. Counting the 4 days of classes I went through (36 hours), I spent an additional 20 hours on my own.

2. Suggest really understanding the ITTOs—they’re essential to knowing where you are in the process—a key item with PMI.

3. PMI is big on ethics and doing the right thing … know what they think is the right thing to do … it’s not always what you would do.

4. Lots of good study materials out there … find one that best fits your learning style. (Find your “poison.” For example, some find Rita’s test guide to be too “in the weeds” and rather dry … others have the exact opposite opinion. While some find the “story book” style and graphics in “PMP Head First” to more ideally suit their learning needs; others felt their approach was too “elementary.” To each their own someone once said.

5. I enrolled in a 4-day teaching course and found that the interaction with the other participants added greatly to the learning experience.

6. Don’t dawdle too long before taking the test. There is so much info (I’ve heard that PMI has a database of over 7,000 possible questions) that you can’t memorize or remember it all. Hit the study guides hard, read through the PMBOK and go take the test. There are several folks in my company who took the 4-day instructional a couple of years back and still haven’t taken the test. Definitely strike while the iron is hot …

7. Force yourself to read ALL the answers before making a selection. With a good many of the questions seeking the “best answer,” the first “right” answer you see may not always be the “best” answer. I read the answers in reverse order (i.e., D,C,B,A) … that helped me read them all.

8. Also, read and re-read the questions. Many of them are very “layered” … pay particular attention to such grammatical articles as “a” and “the” — they can greatly influence which of the answers is the “best” answer.

9. Most all of the stress I felt whilst taking the test (as compared to many sample tests I’d previously taken) was that this one counted! I took nearly the full 4 hours allotted, but never felt rushed. (I had never gone over 3 hours on the 200- question practice tests I had found on line. My 57-year old brain (and rear!) did grow tired.) My approach was to go through the test in a deliberative fashion the first time through … answering those I was dead sure about … and answering/marking for further review those questions on which I was readily unsure of my answer–or had me reading through the question more than twice. I also took a 10-minute break at the half-way mark (100 questions). As a result, I finished my first run through the exam with 30 minutes to spare, and thus was then able to turn my full concentration toward those questions on which I needed to a more thorough break down. (FYI-I had 40 such questions.) Not too surprisingly, however, I only changed my answer on 3 of the questions … leaving the remaining 37 as I had first marked.

Project Management Control Systems

2009-11-28T22:23:00.003+05:30

Project management control systems are the modern tools for managing project scope, cost and schedule. They are based on carefully defined process and document controls, metrics, performance indicators and forecasting with capability to reveal trends toward cost overrun and/or schedule slippage. Identifying those trends early makes them more amenable to successful management.

Traditionally, management systems have utilized data about planned and actual costs. Modern systems further incorporate, in their analysis of projects and tasks, the monetary value earned for actual work accomplished.

They analyze the Planned Value of work scheduled (PV),
Actual Cost of work performed (AC),
and Earned Value of work performed (EV).

Forecasting includes cumulative and incremental trends in key indicators such as the

Estimate at Completion (AC + Estimate to Complete),
Cost Variance (EV – AC),
Schedule Variance (EV – PV),
Cost Performance Index (EV/AC),
and Schedule Performance Index (EV/PV).

Earned Value Management (EVM) is a systematic approach to the integration and measurement of cost, schedule and scope accomplishments on a project or task, providing managers the ability to examine cost data in the context of detailed schedule information and critical program and technical milestones.

EVM systems are in use by IT service providers, leading project delivery contractors in commercial industry and government service. ( works in any sphere )

***

Nothing is perfect in this world of chaos.

So to bring orderliness, something has to be scratched from bottom up.

Every step of the way in any development or project completion gets monitored and reported.

It gives a sense of feeling while work gets done.

The guy who monitors - Program Manager ( multiple projects ) or Project Manager ( single project ) with tons of resources should be using various learned tools, gained experience, of the scope of the project.

Project Management Control Systems

2009-11-28T22:23:00.002+05:30

They analyze the Planned Value of work scheduled (PV),
Actual Cost of work performed (AC),
and Earned Value of work performed (EV).

Forecasting includes cumulative and incremental trends in key indicators such as the

Estimate at Completion (AC + Estimate to Complete),
Cost Variance (EV – AC),
Schedule Variance (EV – PV),
Cost Performance Index (EV/AC),
and Schedule Performance Index (EV/PV).

Startups - what they really are

2009-11-06T17:46:00.002+05:30

This is credited from here... http://www.paulgraham.com/really.html

1. Be Careful with Cofounders

This was the surprise mentioned by the most founders. There were two types of responses: that you have to be careful who you pick as a cofounder, and that you have to work hard to maintain your relationship.

What people wished they'd paid more attention to when choosing cofounders was character and commitment, not ability. This was particularly true with startups that failed. The lesson: don't pick cofounders who will flake.

Here's a typical reponse:

You haven't seen someone's true colors unless you've worked with them on a startup.

The reason character is so important is that it's tested more severely than in most other situations. One founder said explicitly that the relationship between founders was more important than ability:

I would rather cofound a startup with a friend than a stranger with higher output. Startups are so hard and emotional that the bonds and emotional and social support that come with friendship outweigh the extra output lost.

We learned this lesson a long time ago. If you look at the YC application, there are more questions about the commitment and relationship of the founders than their ability.

Founders of successful startups talked less about choosing cofounders and more about how hard they worked to maintain their relationship.

One thing that surprised me is how the relationship of startup founders goes from a friendship to a marriage. My relationship with my cofounder went from just being friends to seeing each other all the time, fretting over the finances and cleaning up shit. And the startup was our baby. I summed it up once like this: "It's like we're married, but we're not fucking."

Several people used that word "married." It's a far more intense relationship than you usually see between coworkers—partly because the stresses are so much greater, and partly because at first the founders are the whole company. So this relationship has to be built of top quality materials and carefully maintained. It's the basis of everything.

2. Startups Take Over Your Life

Just as the relationship between cofounders is more intense than it usually is between coworkers, so is the relationship between the founders and the company. Running a startup is not like having a job or being a student, because it never stops. This is so foreign to most people's experience that they don't get it till it happens. [1]

I didn't realize I would spend almost every waking moment either working or thinking about our startup. You enter a whole different way of life when it's your company vs. working for someone else's company.

It's exacerbated by the fast pace of startups, which makes it seem like time slows down:

I think the thing that's been most surprising to me is how one's perspective on time shifts. Working on our startup, I remember time seeming to stretch out, so that a month was a huge interval.

In the best case, total immersion can be exciting:

It's surprising how much you become consumed by your startup, in that you think about it day and night, but never once does it feel like "work."

Though I have to say, that quote is from someone we funded this summer. In a couple years he may not sound so chipper.

3. It's an Emotional Roller-coaster

This was another one lots of people were surprised about. The ups and downs were more extreme than they were prepared for.

In a startup, things seem great one moment and hopeless the next. And by next, I mean a couple hours later.

The emotional ups and downs were the biggest surprise for me. One day, we'd think of ourselves as the next Google and dream of buying islands; the next, we'd be pondering how to let our loved ones know of our utter failure; and on and on.

The hard part, obviously, is the lows. For a lot of founders that was the big surprise:

How hard it is to keep everyone motivated during rough days or weeks, i.e. how low the lows can be.

After a while, if you don't have significant success to cheer you up, it wears you out:

Your most basic advice to founders is "just don't die," but the energy to keep a company going in lieu of unburdening success isn't free; it is siphoned from the founders themselves.

There's a limit to how much you can take. If you get to the point where you can't keep working anymore, it's not the end of the world. Plenty of famous founders have had some failures along the way.

4. It Can Be Fun

The good news is, the highs are also very high. Several founders said what surprised them most about doing a startup was how fun it was:

I think you've left out just how fun it is to do a startup. I am more fulfilled in my work than pretty much any of my friends who did not start companies.

What they like most is the freedom:

I'm surprised by how much better it feels to be working on something that is challenging and creative, something I believe in, as opposed to the hired-gun stuff I was doing before. I knew it would feel better; what's surprising is how much better.

Frankly, though, if I've misled people here, I'm not eager to fix that. I'd rather have everyone think starting a startup is grim and hard than have founders go into it expecting it to be fun, and a few months later saying "This is supposed to be fun? Are you kidding?"

The truth is, it wouldn't be fun for most people. A lot of what we try to do in the application process is to weed out the people who wouldn't like it, both for our sake and theirs.

The best way to put it might be that starting a startup is fun the way a survivalist training course would be fun, if you're into that sort of thing. Which is to say, not at all, if you're not.

5. Persistence Is the Key

A lot of founders were surprised how important persistence was in startups. It was both a negative and a positive surprise: they were surprised both by the degree of persistence required

Everyone said how determined and resilient you must be, but going through it made me realize that the determination required was still understated.

and also by the degree to which persistence alone was able to dissolve obstacles:

If you are persistent, even problems that seem out of your control (i.e. immigration) seem to work themselves out.

Several founders mentioned specifically how much more important persistence was than intelligence.

I've been surprised again and again by just how much more important persistence is than raw intelligence.

This applies not just to intelligence but to ability in general, and that's why so many people said character was more important in choosing cofounders.

6. Think Long-Term

You need persistence because everything takes longer than you expect. A lot of people were surprised by that.

I'm continually surprised by how long everything can take. Assuming your product doesn't experience the explosive growth that very few products do, everything from development to dealmaking (especially dealmaking) seems to take 2-3x longer than I always imagine.

One reason founders are surprised is that because they work fast, they expect everyone else to. There's a shocking amount of shear stress at every point where a startup touches a more bureaucratic organization, like a big company or a VC fund. That's why fundraising and the enterprise market kill and maim so many startups. [2]

But I think the reason most founders are surprised by how long it takes is that they're overconfident. They think they're going to be an instant success, like YouTube or Facebook. You tell them only 1 out of 100 successful startups has a trajectory like that, and they all think "we're going to be that 1."

Maybe they'll listen to one of the more successful founders:

The top thing I didn't understand before going into it is that persistence is the name of the game. For the vast majority of startups that become successful, it's going to be a really long journey, at least 3 years and probably 5+.

There is a positive side to thinking longer-term. It's not just that you have to resign yourself to everything taking longer than it should. If you work patiently it's less stressful, and you can do better work:

Because we're relaxed, it's so much easier to have fun doing what we do. Gone is the awkward nervous energy fueled by the desperate need to not fail guiding our actions. We can concentrate on doing what's best for our company, product, employees and customers.

That's why things get so much better when you hit ramen profitability. You can shift into a different mode of working.

7. Lots of Little Things

We often emphasize how rarely startups win simply because they hit on some magic idea. I think founders have now gotten that into their heads. But a lot were surprised to find this also applies within startups. You have to do lots of different things:

It's much more of a grind than glamorous. A timeslice selected at random would more likely find me tracking down a weird DLL loading bug on Swedish Windows, or tracking down a bug in the financial model Excel spreadsheet the night before a board meeting, rather than having brilliant flashes of strategic insight.

Most hacker-founders would like to spend all their time programming. You won't get to, unless you fail. Which can be transformed into: If you spend all your time programming, you will fail.

The principle extends even into programming. There is rarely a single brilliant hack that ensures success:

I learnt never to bet on any one feature or deal or anything to bring you success. It is never a single thing. Everything is just incremental and you just have to keep doing lots of those things until you strike something.

Even in the rare cases where a clever hack makes your fortune, you probably won't know till later:

There is no such thing as a killer feature. Or at least you won't know what it is.

So the best strategy is to try lots of different things. The reason not to put all your eggs in one basket is not the usual one, which applies even when you know which basket is best. In a startup you don't even know that.

8. Start with Something Minimal

Lots of founders mentioned how important it was to launch with the simplest possible thing. By this point everyone knows you should release fast and iterate. It's practically a mantra at YC. But even so a lot of people seem to have been burned by not doing it:

Build the absolute smallest thing that can be considered a complete application and ship it.

Why do people take too long on the first version? Pride, mostly. They hate to release something that could be better. They worry what people will say about them. But you have to overcome this:

Doing something "simple" at first glance does not mean you aren't doing something meaningful, defensible, or valuable.

Don't worry what people will say. If your first version is so impressive that trolls don't make fun of it, you waited too long to launch. [3]

One founder said this should be your approach to all programming, not just startups, and I tend to agree.

Now, when coding, I try to think "How can I write this such that if people saw my code, they'd be amazed at how little there is and how little it does?"

Over-engineering is poison. It's not like doing extra work for extra credit. It's more like telling a lie that you then have to remember so you don't contradict it.

9. Engage Users

Product development is a conversation with the user that doesn't really start till you launch. Before you launch, you're like a police artist before he's shown the first version of his sketch to the witness.

It's so important to launch fast that it may be better to think of your initial version not as a product, but as a trick for getting users to start talking to you.

I learned to think about the initial stages of a startup as a giant experiment. All products should be considered experiments, and those that have a market show promising results extremely quickly.

Once you start talking to users, I guarantee you'll be surprised by what they tell you.

When you let customers tell you what they're after, they will often reveal amazing details about what they find valuable as well what they're willing to pay for.

The surprise is generally positive as well as negative. They won't like what you've built, but there will be other things they would like that would be trivially easy to implement. It's not till you start the conversation by launching the wrong thing that they can express (or perhaps even realize) what they're looking for.

10. Change Your Idea

To benefit from engaging with users you have to be willing to change your idea. We've always encouraged founders to see a startup idea as a hypothesis rather than a blueprint. And yet they're still surprised how well it works to change the idea.

Normally if you complain about something being hard, the general advice is to work harder. With a startup, I think you should find a problem that's easy for you to solve. Optimizing in solution-space is familiar and straightforward, but you can make enormous gains playing around in problem-space.

Whereas mere determination, without flexibility, is a greedy algorithm that may get you nothing more than a mediocre local maximum:

When someone is determined, there's still a danger that they'll follow a long, hard path that ultimately leads nowhere.

You want to push forward, but at the same time twist and turn to find the most promising path. One founder put it very succinctly:

Fast iteration is the key to success.

One reason this advice is so hard to follow is that people don't realize how hard it is to judge startup ideas, particularly their own. Experienced founders learn to keep an open mind:

Now I don't laugh at ideas anymore, because I realized how terrible I was at knowing if they were good or not.

You can never tell what will work. You just have to do whatever seems best at each point. We do this with YC itself. We still don't know if it will work, but it seems like a decent hypothesis.

11. Don't Worry about Competitors

When you think you've got a great idea, it's sort of like having a guilty conscience about something. All someone has to do is look at you funny, and you think "Oh my God, they know."

These alarms are almost always false:

Companies that seemed like competitors and threats at first glance usually never were when you really looked at it. Even if they were operating in the same area, they had a different goal.

One reason people overreact to competitors is that they overvalue ideas. If ideas really were the key, a competitor with the same idea would be a real threat. But it's usually execution that matters:

All the scares induced by seeing a new competitor pop up are forgotten weeks later. It always comes down to your own product and approach to the market.

This is generally true even if competitors get lots of attention.

Competitors riding on lots of good blogger perception aren't really the winners and can disappear from the map quickly. You need consumers after all.

Hype doesn't make satisfied users, at least not for something as complicated as technology.

12. It's Hard to Get Users

A lot of founders complained about how hard it was to get users, though.

I had no idea how much time and effort needed to go into attaining users.

This is a complicated topic. When you can't get users, it's hard to say whether the problem is lack of exposure, or whether the product's simply bad. Even good products can be blocked by switching or integration costs:

Getting people to use a new service is incredibly difficult. This is especially true for a service that other companies can use, because it requires their developers to do work. If you're small, they don't think it is urgent. [4]

The sharpest criticism of YC came from a founder who said we didn't focus enough on customer acquisition:

YC preaches "make something people want" as an engineering task, a never ending stream of feature after feature until enough people are happy and the application takes off. There's very little focus on the cost of customer acquisition.

This may be true; this may be something we need to fix, especially for applications like games. If you make something where the challenges are mostly technical, you can rely on word of mouth, like Google did. One founder was surprised by how well that worked for him:

There is an irrational fear that no one will buy your product. But if you work hard and incrementally make it better, there is no need to worry.

But with other types of startups you may win less by features and more by deals and marketing.

13. Expect the Worst with Deals

Deals fall through. That's a constant of the startup world. Startups are powerless, and good startup ideas generally seem wrong. So everyone is nervous about closing deals with you, and you have no way to make them.

This is particularly true with investors:

In retrospect, it would have been much better if we had operated under the assumption that we would never get any additional outside investment. That would have focused us on finding revenue streams early.

My advice is generally pessimistic. Assume you won't get money, and if someone does offer you any, assume you'll never get any more.

If someone offers you money, take it. You say it a lot, but I think it needs even more emphasizing. We had the opportunity to raise a lot more money than we did last year and I wish we had.

Why do founders ignore me? Mostly because they're optimistic by nature. The mistake is to be optimistic about things you can't control. By all means be optimistic about your ability to make something great. But you're asking for trouble if you're optimistic about big companies or investors.

14. Investors Are Clueless

A lot of founders mentioned how surprised they were by the cluelessness of investors:

They don't even know about the stuff they've invested in. I met some investors that had invested in a hardware device and when I asked them to demo the device they had difficulty switching it on.

Angels are a bit better than VCs, because they usually have startup experience themselves:

VC investors don't know half the time what they are talking about and are years behind in their thinking. A few were great, but 95% of the investors we dealt with were unprofessional, didn't seem to be very good at business or have any kind of creative vision. Angels were generally much better to talk to.

Why are founders surprised that VCs are clueless? I think it's because they seem so formidable.

The reason VCs seem formidable is that it's their profession to. You get to be a VC by convincing asset managers to trust you with hundreds of millions of dollars. How do you do that? You have to seem confident, and you have to seem like you understand technology. [5]

15. You May Have to Play Games

Because investors are so bad at judging you, you have to work harder than you should at selling yourself. One founder said the thing that surprised him most was

The degree to which feigning certitude impressed investors.

This is the thing that has surprised me most about YC founders' experiences. This summer we invited some of the alumni to talk to the new startups about fundraising, and pretty much 100% of their advice was about investor psychology. I thought I was cynical about VCs, but the founders were much more cynical.

A lot of what startup founders do is just posturing. It works.

VCs themselves have no idea of the extent to which the startups they like are the ones that are best at selling themselves to VCs. [6] It's exactly the same phenomenon we saw a step earlier. VCs get money by seeming confident to LPs, and founders get money by seeming confident to VCs.

16. Luck Is a Big Factor

With two such random linkages in the path between startups and money, it shouldn't be surprising that luck is a big factor in deals. And yet a lot of founders are surprised by it.

I didn't realize how much of a role luck plays and how much is outside of our control.

If you think about famous startups, it's pretty clear how big a role luck plays. Where would Microsoft be if IBM insisted on an exclusive license for DOS?

Why are founders fooled by this? Business guys probably aren't, but hackers are used to a world where skill is paramount, and you get what you deserve.

When we started our startup, I had bought the hype of the startup founder dream: that this is a game of skill. It is, in some ways. Having skill is valuable. So is being determined as all hell. But being lucky is the critical ingredient.

Actually the best model would be to say that the outcome is the product of skill, determination, and luck. No matter how much skill and determination you have, if you roll a zero for luck, the outcome is zero.

These quotes about luck are not from founders whose startups failed. Founders who fail quickly tend to blame themselves. Founders who succeed quickly don't usually realize how lucky they were. It's the ones in the middle who see how important luck is.

17. The Value of Community

A surprising number of founders said what surprised them most about starting a startup was the value of community. Some meant the micro-community of YC founders:

The immense value of the peer group of YC companies, and facing similar obstacles at similar times.

which shouldn't be that surprising, because that's why it's structured that way. Others were surprised at the value of the startup community in the larger sense:

How advantageous it is to live in Silicon Valley, where you can't help but hear all the cutting-edge tech and startup news, and run into useful people constantly.

The specific thing that surprised them most was the general spirit of benevolence:

One of the most surprising things I saw was the willingness of people to help us. Even people who had nothing to gain went out of their way to help our startup succeed.

and particularly how it extended all the way to the top:

The surprise for me was how accessible important and interesting people are. It's amazing how easily you can reach out to people and get immediate feedback.

This is one of the reasons I like being part of this world. Creating wealth is not a zero-sum game, so you don't have to stab people in the back to win.

18. You Get No Respect

There was one surprise founders mentioned that I'd forgotten about: that outside the startup world, startup founders get no respect.

In social settings, I found that I got a lot more respect when I said, "I worked on Microsoft Office" instead of "I work at a small startup you've never heard of called x."

Partly this is because the rest of the world just doesn't get startups, and partly it's yet another consequence of the fact that most good startup ideas seem bad:

If you pitch your idea to a random person, 95% of the time you'll find the person instinctively thinks the idea will be a flop and you're wasting your time (although they probably won't say this directly).

Unfortunately this extends even to dating:

It surprised me that being a startup founder does not get you more admiration from women.

I did know about that, but I'd forgotten.

19. Things Change as You Grow

The last big surprise founders mentioned is how much things changed as they grew. The biggest change was that you got to program even less:

Your job description as technical founder/CEO is completely rewritten every 6-12 months. Less coding, more managing/planning/company building, hiring, cleaning up messes, and generally getting things in place for what needs to happen a few months from now.

In particular, you now have to deal with employees, who often have different motivations:

I knew the founder equation and had been focused on it since I knew I wanted to start a startup as a 19 year old. The employee equation is quite different so it took me a while to get it down.

Fortunately, it can become a lot less stressful once you reach cruising altitude:

I'd say 75% of the stress is gone now from when we first started. Running a business is so much more enjoyable now. We're more confident. We're more patient. We fight less. We sleep more.

I wish I could say it was this way for every startup that succeeded, but 75% is probably on the high side.

The Super-Pattern

There were a few other patterns, but these were the biggest. One's first thought when looking at them all is to ask if there's a super-pattern, a pattern to the patterns.

I saw it immediately, and so did a YC founder I read the list to. These are supposed to be the surprises, the things I didn't tell people. What do they all have in common? They're all things I tell people. If I wrote a new essay with the same outline as this that wasn't summarizing the founders' responses, everyone would say I'd run out of ideas and was just repeating myself.

What is going on here?

When I look at the responses, the common theme is that starting a startup was like I said, but way more so. People just don't seem to get how different it is till they do it. Why? The key to that mystery is to ask, how different from what? Once you phrase it that way, the answer is obvious: from a job. Everyone's model of work is a job. It's completely pervasive. Even if you've never had a job, your parents probably did, along with practically every other adult you've met.

Unconsciously, everyone expects a startup to be like a job, and that explains most of the surprises. It explains why people are surprised how carefully you have to choose cofounders and how hard you have to work to maintain your relationship. You don't have to do that with coworkers. It explains why the ups and downs are surprisingly extreme. In a job there is much more damping. But it also explains why the good times are surprisingly good: most people can't imagine such freedom. As you go down the list, almost all the surprises are surprising in how much a startup differs from a job.

You probably can't overcome anything so pervasive as the model of work you grew up with. So the best solution is to be consciously aware of that. As you go into a startup, you'll be thinking "everyone says it's really extreme." Your next thought will probably be "but I can't believe it will be that bad." If you want to avoid being surprised, the next thought after that should be: "and the reason I can't believe it will be that bad is that my model of work is a job."

(hardly I could snip it... Thanks Paul )

Startups - what they really are

2009-11-06T17:46:00.001+05:30

You haven't seen someone's true colors unless you've worked with them on a startup.

I would rather cofound a startup with a friend than a stranger with higher output. Startups are so hard and emotional that the bonds and emotional and social support that come with friendship outweigh the extra output lost.

One thing that surprised me is how the relationship of startup founders goes from a friendship to a marriage. My relationship with my cofounder went from just being friends to seeing each other all the time, fretting over the finances and cleaning up shit. And the startup was our baby. I summed it up once like this: "It's like we're married, but we're not fucking."

I didn't realize I would spend almost every waking moment either working or thinking about our startup. You enter a whole different way of life when it's your company vs. working for someone else's company.

It's exacerbated by the fast pace of startups, which makes it seem like time slows down:

I think the thing that's been most surprising to me is how one's perspective on time shifts. Working on our startup, I remember time seeming to stretch out, so that a month was a huge interval.

In the best case, total immersion can be exciting:

It's surprising how much you become consumed by your startup, in that you think about it day and night, but never once does it feel like "work."

The emotional ups and downs were the biggest surprise for me. One day, we'd think of ourselves as the next Google and dream of buying islands; the next, we'd be pondering how to let our loved ones know of our utter failure; and on and on.

The hard part, obviously, is the lows. For a lot of founders that was the big surprise:

How hard it is to keep everyone motivated during rough days or weeks, i.e. how low the lows can be.

After a while, if you don't have significant success to cheer you up, it wears you out:

Your most basic advice to founders is "just don't die," but the energy to keep a company going in lieu of unburdening success isn't free; it is siphoned from the founders themselves.

I think you've left out just how fun it is to do a startup. I am more fulfilled in my work than pretty much any of my friends who did not start companies.

What they like most is the freedom:

I'm surprised by how much better it feels to be working on something that is challenging and creative, something I believe in, as opposed to the hired-gun stuff I was doing before. I knew it would feel better; what's surprising is how much better.

Everyone said how determined and resilient you must be, but going through it made me realize that the determination required was still understated.

and also by the degree to which persistence alone was able to dissolve obstacles:

If you are persistent, even problems that seem out of your control (i.e. immigration) seem to work themselves out.

Several founders mentioned specifically how much more important persistence was than intelligence.

I've been surprised again and again by just how much more important persistence is than raw intelligence.

I'm continually surprised by how long everything can take. Assuming your product doesn't experience the explosive growth that very few products do, everything from development to dealmaking (especially dealmaking) seems to take 2-3x longer than I always imagine.

The top thing I didn't understand before going into it is that persistence is the name of the game. For the vast majority of startups that become successful, it's going to be a really long journey, at least 3 years and probably 5+.

Because we're relaxed, it's so much easier to have fun doing what we do. Gone is the awkward nervous energy fueled by the desperate need to not fail guiding our actions. We can concentrate on doing what's best for our company, product, employees and customers.

It's much more of a grind than glamorous. A timeslice selected at random would more likely find me tracking down a weird DLL loading bug on Swedish Windows, or tracking down a bug in the financial model Excel spreadsheet the night before a board meeting, rather than having brilliant flashes of strategic insight.

I learnt never to bet on any one feature or deal or anything to bring you success. It is never a single thing. Everything is just incremental and you just have to keep doing lots of those things until you strike something.

Even in the rare cases where a clever hack makes your fortune, you probably won't know till later:

There is no such thing as a killer feature. Or at least you won't know what it is.

Build the absolute smallest thing that can be considered a complete application and ship it.

Why do people take too long on the first version? Pride, mostly. They hate to release something that could be better. They worry what people will say about them. But you have to overcome this:

Doing something "simple" at first glance does not mean you aren't doing something meaningful, defensible, or valuable.

Now, when coding, I try to think "How can I write this such that if people saw my code, they'd be amazed at how little there is and how little it does?"

I learned to think about the initial stages of a startup as a giant experiment. All products should be considered experiments, and those that have a market show promising results extremely quickly.

Once you start talking to users, I guarantee you'll be surprised by what they tell you.

When you let customers tell you what they're after, they will often reveal amazing details about what they find valuable as well what they're willing to pay for.

Normally if you complain about something being hard, the general advice is to work harder. With a startup, I think you should find a problem that's easy for you to solve. Optimizing in solution-space is familiar and straightforward, but you can make enormous gains playing around in problem-space.

Whereas mere determination, without flexibility, is a greedy algorithm that may get you nothing more than a mediocre local maximum:

When someone is determined, there's still a danger that they'll follow a long, hard path that ultimately leads nowhere.

You want to push forward, but at the same time twist and turn to find the most promising path. One founder put it very succinctly:

Fast iteration is the key to success.

One reason this advice is so hard to follow is that people don't realize how hard it is to judge startup ideas, particularly their own. Experienced founders learn to keep an open mind:

Now I don't laugh at ideas anymore, because I realized how terrible I was at knowing if they were good or not.

Companies that seemed like competitors and threats at first glance usually never were when you really looked at it. Even if they were operating in the same area, they had a different goal.

One reason people overreact to competitors is that they overvalue ideas. If ideas really were the key, a competitor with the same idea would be a real threat. But it's usually execution that matters:

All the scares induced by seeing a new competitor pop up are forgotten weeks later. It always comes down to your own product and approach to the market.

This is generally true even if competitors get lots of attention.

Competitors riding on lots of good blogger perception aren't really the winners and can disappear from the map quickly. You need consumers after all.

Hype doesn't make satisfied users, at least not for something as complicated as technology.

12. It's Hard to Get Users

A lot of founders complained about how hard it was to get users, though.

I had no idea how much time and effort needed to go into attaining users.

Getting people to use a new service is incredibly difficult. This is especially true for a service that other companies can use, because it requires their developers to do work. If you're small, they don't think it is urgent. [4]

The sharpest criticism of YC came from a founder who said we didn't focus enough on customer acquisition:

YC preaches "make something people want" as an engineering task, a never ending stream of feature after feature until enough people are happy and the application takes off. There's very little focus on the cost of customer acquisition.

There is an irrational fear that no one will buy your product. But if you work hard and incrementally make it better, there is no need to worry.

In retrospect, it would have been much better if we had operated under the assumption that we would never get any additional outside investment. That would have focused us on finding revenue streams early.

My advice is generally pessimistic. Assume you won't get money, and if someone does offer you any, assume you'll never get any more.

If someone offers you money, take it. You say it a lot, but I think it needs even more emphasizing. We had the opportunity to raise a lot more money than we did last year and I wish we had.

They don't even know about the stuff they've invested in. I met some investors that had invested in a hardware device and when I asked them to demo the device they had difficulty switching it on.

Angels are a bit better than VCs, because they usually have startup experience themselves:

VC investors don't know half the time what they are talking about and are years behind in their thinking. A few were great, but 95% of the investors we dealt with were unprofessional, didn't seem to be very good at business or have any kind of creative vision. Angels were generally much better to talk to.

The degree to which feigning certitude impressed investors.

A lot of what startup founders do is just posturing. It works.

I didn't realize how much of a role luck plays and how much is outside of our control.

When we started our startup, I had bought the hype of the startup founder dream: that this is a game of skill. It is, in some ways. Having skill is valuable. So is being determined as all hell. But being lucky is the critical ingredient.

The immense value of the peer group of YC companies, and facing similar obstacles at similar times.

which shouldn't be that surprising, because that's why it's structured that way. Others were surprised at the value of the startup community in the larger sense:

How advantageous it is to live in Silicon Valley, where you can't help but hear all the cutting-edge tech and startup news, and run into useful people constantly.

The specific thing that surprised them most was the general spirit of benevolence:

One of the most surprising things I saw was the willingness of people to help us. Even people who had nothing to gain went out of their way to help our startup succeed.

and particularly how it extended all the way to the top:

The surprise for me was how accessible important and interesting people are. It's amazing how easily you can reach out to people and get immediate feedback.

In social settings, I found that I got a lot more respect when I said, "I worked on Microsoft Office" instead of "I work at a small startup you've never heard of called x."

Partly this is because the rest of the world just doesn't get startups, and partly it's yet another consequence of the fact that most good startup ideas seem bad:

If you pitch your idea to a random person, 95% of the time you'll find the person instinctively thinks the idea will be a flop and you're wasting your time (although they probably won't say this directly).

Unfortunately this extends even to dating:

It surprised me that being a startup founder does not get you more admiration from women.

Your job description as technical founder/CEO is completely rewritten every 6-12 months. Less coding, more managing/planning/company building, hiring, cleaning up messes, and generally getting things in place for what needs to happen a few months from now.

In particular, you now have to deal with employees, who often have different motivations:

I knew the founder equation and had been focused on it since I knew I wanted to start a startup as a 19 year old. The employee equation is quite different so it took me a while to get it down.

Fortunately, it can become a lot less stressful once you reach cruising altitude:

I'd say 75% of the stress is gone now from when we first started. Running a business is so much more enjoyable now. We're more confident. We're more patient. We fight less. We sleep more.

Prioritization

2009-09-29T10:41:00.002+05:30

Everybody deals with it. The name of the devil is "Demand" and if its nature is unexpected then it becomes more poisonous. Prioritization is a weapon which serves as a great source of power in dealing with that.

Here is a seven-step approach for creating and maintaining a priority list and deal with the demand in a way it becomes meaningful to you. (The term "business" is used at a high-level and goes beyond the traditional definition of trade or commerce. It is used here as a context which has the most significant impact on you.)

Make an inventory list of everything you need to accomplish. Then classify it into the following three perspectives:
1. Everything Routine: It should include all the tasks that you do on a routine basis. Checking emails, submitting status reports, attending review meetings… everything routine.
2. Everything Exclusive: It should include all the specific requests from superiors, colleagues, clients, vendors or anyone who you need to be specific upon.
3. Everything Extra-mile: It should include everything that you have initiated or you are taking an active part in helping that thing done. It might include new processes and procedures that you intend to create new product lines, new hiring policy, new reward policy etc.
Categorize each inventory item list according to:
1. Business Criticality: Business criticality should be #1 driver. It would be wise to get engaged in doing the most important items related to the business. These are the items if not given attention to, would adversely impact the business.
2. Personal Importance: Next is personal importance. Once business criticality and importance are dealt with, move focus to personal important items. These are the items if not given attention to, would adversely impact you.
3. Urgency and consequences: Now deal with urgencies. In today's cut-throat competitive world, anybody might come to you with urgent requests to fulfill. You need to understand the distinction between urgency and importance and then deal with others' urgent items. These are the items if done, would impact others positively and not covered in the above two list categories.
Estimate how much time you have to accomplish the tasks. Also ask yourself few questions like:
1. Should I do it myself or delegate to others?
2. What can be delegated to others?
3. What would be the impact of the delegation?
4. What are the alternative ways of accomplishing the task?
Make a stand-by priority list and order it as per point # 2 (Business Criticality, Personal Importance and Urgency) – This list is the list you can act upon when you don't have any other priority set. The list you create in point # 2 gets precedence nonetheless.
Work out how you can fit the prioritized list into a time-box. Put priorities with high business importance first and hold-back the self-initiated priorities if you find it hard to time-box.
Finalize the priority-list and organize the work you need to do or get that done from others and act upon.
Revise the priority list as per your needs and re-enter into the priority list preparation exercise again. Sharpen the saw.

Given the way it is described, it might look like a dreadful task however almost all the successful managers pass through this exercise almost mechanically. I have observed that Prioritization provides "structure" to the information chunks and leads to clarity and clarity is #1 success driver in accomplishment of anything you intend to accomplish.

Happy Prioritization!

Prioritization

2009-09-29T10:41:00.001+05:30

Make an inventory list of everything you need to accomplish. Then classify it into the following three perspectives:
1. Everything Routine: It should include all the tasks that you do on a routine basis. Checking emails, submitting status reports, attending review meetings… everything routine.
2. Everything Exclusive: It should include all the specific requests from superiors, colleagues, clients, vendors or anyone who you need to be specific upon.
3. Everything Extra-mile: It should include everything that you have initiated or you are taking an active part in helping that thing done. It might include new processes and procedures that you intend to create new product lines, new hiring policy, new reward policy etc.
Categorize each inventory item list according to:
1. Business Criticality: Business criticality should be #1 driver. It would be wise to get engaged in doing the most important items related to the business. These are the items if not given attention to, would adversely impact the business.
2. Personal Importance: Next is personal importance. Once business criticality and importance are dealt with, move focus to personal important items. These are the items if not given attention to, would adversely impact you.
3. Urgency and consequences: Now deal with urgencies. In today's cut-throat competitive world, anybody might come to you with urgent requests to fulfill. You need to understand the distinction between urgency and importance and then deal with others' urgent items. These are the items if done, would impact others positively and not covered in the above two list categories.
Estimate how much time you have to accomplish the tasks. Also ask yourself few questions like:
1. Should I do it myself or delegate to others?
2. What can be delegated to others?
3. What would be the impact of the delegation?
4. What are the alternative ways of accomplishing the task?
Make a stand-by priority list and order it as per point # 2 (Business Criticality, Personal Importance and Urgency) – This list is the list you can act upon when you don't have any other priority set. The list you create in point # 2 gets precedence nonetheless.
Work out how you can fit the prioritized list into a time-box. Put priorities with high business importance first and hold-back the self-initiated priorities if you find it hard to time-box.
Finalize the priority-list and organize the work you need to do or get that done from others and act upon.
Revise the priority list as per your needs and re-enter into the priority list preparation exercise again. Sharpen the saw.

Happy Prioritization!

Why is a phone interview required and how do I get to the in person interview?

2009-09-02T09:54:00.002+05:30

Today this question is far more relevant than in years past. In the past phone interviews were only used if extensive travel was required for an interview. If somebody in New York applied for a job in Los Angeles he was going to have to get through a phone interview. With a few exceptions that was about the only time it was used. Now hiring authorities phone interview everybody even those just across town. This is not a good trend. Phone interviews are never as productive as meeting a candidate in person and during my career I have seen many of the highest caliber candidates be rejected because they did not interview as well by phone and the interviewer was not able to evaluate as well by phone as in person.
One of the biggest problems with a phone interview is that unlike the face to face interview the employer is looking for reasons NOT to bring in the candidate. Think about that. In an in person interview they are looking for reasons to hire. In a phone interview they are looking for reasons to not even bring a candidate in for a real interview, let alone hire him.

As a recruiter I was insulted when a company wanted to phone interview a candidate because there was only one reason for it. The employer did not trust me as an extension of their hiring team. They did not believe that I could evaluate a candidate as well as they could. They did not believe that I understood their needs as well as they did. This usually indicated a trust issue that went well beyond the phone interview. For this reason I did not accept assignments from employers who insisted on a phone interview before scheduling a candidate. If a client was not going to trust my judgment as to who they would interview I would win the trust or walk away from the assignment.

If phone interviews are so flawed why are they being used more than ever before? There are lots of reasons.
Employers do not believe resumes. Many candidates desperate to find work are "exaggerating" the facts and details of their resumes in order to appear a stronger candidate. It has been estimated that in good times 50%of resumes contained misleading content (lies) so imagine what it is in the worst of times. Employers cannot decide to interview a candidate based on the resume if they do not believe what they are reading. To these people the phone interview is a fact checking session.

Human resource departments are under intense pressure to reduce expenses. They are a non revenue generating function so in hard times they are always one of the first to feel the pressure. Interview travel cost are a big expense item so phone interviews are a tool to make sure they are spending wisely. In many cases multiple phone interviews are conducted.

***

In the past quarter century of self employed consulting, I have been placed by various headhunters into about 1/4 of my projects. Working with them, I had one interview in person and maybe a couple what I would consider to be telephone interviews.

All other phone calls with them consisted solely of them dispensing additional job related details, followed by my own evaluation of both the positives and the negatives, in terms of the overall fit. However, none of them felt like [telephone] interviews.

Therefore, do not be too harsh on your corporate prospects just because too many headhunters have created an impression that most recruiting outfits are nothing more than resume re-faxing services.

***

You make some great points, but I guess it comes down to what you use a phone interview for. I have three years exp as a recruiter and was taught that a phone interview was not to eliminate candidates. You confirm that they meet minimum requirements - Then give them a better understanding of the company, position and culture. Finally you prepare them for the in person interview coming by telling them about the hiring manager, the selection process, salary range and benefits. I was always told I am the candidates advocate and acting as such I will create win win scenarios. We get candidates that fit our needs and culture and candidates perform better in interviews. Resumes are used to screen candidates and eliminate non qualified applicants not phone screens. As for working with thrid party recruiter I think it is a question of culture, my job was to present the hiring manager with the best possible candidates period. who cares where they came from I always worked well with thrid party recruiters and I would say that 1/2 the time I encourage them to participate in the pre interview phone screen. which they did and the results where a stronger more prepared candidate.

***

One of the key reasons for phone interviews is that the team members are scattered to the four winds.

I generally agree that in person is much better, but lacking it, which I suspect will become more and more common, shouldn't be a hindrance if you have done your homework on the company and the division you are interview for.

I actually have a funny story about phone interviews. In this case the subject matter is highly technical and very few recruiters would have the knowledge to know what depth the candidates have or whether they were being led up the garden path or not. So I don't fault the recruiter for doing not much more than a quick review of the resume and letting the hiring manager handle the details.

Usually I don't expect much; however, I was interviewed for a contract a short while ago and was told they would get back to me in a week to ten days as they were interviewing a number of candidates. Okay, I thought, thanked them and put it out of my mind except to tickle file it for follow up. The interview ended at 4:30 pm and covered general knowledge with a bit about how the team worked. The team manager was not on the call. Plus they are all scattered across five offices in three time zones. Was I surprised when the next morning, sixteen hours and fifteen minutes later, I was offered the contract!

Why is a phone interview required and how do I get to the in person interview?

2009-09-02T09:54:00.001+05:30

Ethical behaviour in the Job and business

2009-08-19T15:05:00.003+05:30

Found this on Linkedin, a must read for folks with experience.

How do good people get caught in seemingly no-win ethical dilemmas?

In my early years in management I reported to someone in a large, publicly-held corporation, who directed all of us on his staff to use our expense report process to contribute $1000 each for a computer system that was going to reside in his office. He convinced all of us that this was not only OK, but was expected. He after all was a regional manager. We later learned that this was not true and he was subsequently fired for misappropriation of corporate funds. We the members of his staff were essentially told that we should look to further our careers elsewhere. I regret being part of this even if I can assign it to naivety and lack of experience.

In another large, publicly held company, I was approached by a member of the Board of Directors to consider a remote learning solution that he had created as the means for us to reach our customers more effectively. Upon evaluation, we determined the technology was not a good match for us and I politely communicated that to the board member. I was later refused a promotion told only that certain members of the board were uncomfortable with my style. I do not regret my how I handled that one.

With over 30 years of management experience today, I am quite confident that I can navigate the waters of safe ethical behavior. I wonder, however, is there a better answer for the younger and less experienced? Or must they too accumulate a regret or two before they find their way?

How about you? Did you have a solid ethical framework in your work environment that allowed you to make the right choices all the time, or do you too have something that you regret?

+++++++++++

I have been in a situation that seemed at the time to be "a no-win ethical dilemma." Now that I am out of it, the answer was clear. The easiest thing for me to do is always to tell the truth and to do what is right. If I do these two things, I can emerge from any ethical dilemma able to hold my head high.

This will sometimes mean a financial squeeze, a strained relationship or other hardship, but in my experience these were short term.

The key is to have a strong moral compass. Without this you will be blown like a ship without a rudder.

++++++++++++++

Ethics is always a personal dilema faced especially when you are starting out in any profession, whether public or private industry. As an accountant, I have learned on the job first hand, what types of ethical dilemas businesses and individuals can face. It is up to each individual to make that moral choice on how to proceed. The more exposure you have to ethical dilemas, the more confident you will become making and in standing by your decisions.

As a junior accountant, I was more apt to "go with the flow" to not ask questions, although in the back of my mind, I knew something wasn't right. I felt that I needed my job and did not want to jeopardize my career by raising concerns that I was not comfortable with. Today in senior management, I can comfortably maintain that ethical posture and confidence in sound business decisions and relay onto others in senior management the proper rules of business.

I consider myself to set a great example of ethics and confidence in my position and to uphold the accounting profession.

+++++++++++++++++

Every time I've resisted unethical behavior, I paid much less for my resistance than the unethical party did, but I always suffered, and I suffered first. C'est la vie. Courteous, well-documented refusals that cite corporate mission and values make trouble, but it's the best kind of trouble and the only kind that a responsible employee who cares about the company will make. Think of the alternative: culture flows from the top. Power corrupts. If you didn't take a risk in disagreement based on the common good and the long view, could you call yourself ethical? And if you "went along," how long would you want to stay with that company or that boss?

+++++++++++++++++

A few situations like this slap the naivity right out of us, don't they?

There will always be ethical dilemmas. I have 16 virtual advisors. Benjamin Franklin, Thomas Jefferson, Einstein.... Great people.

Except BF had a child out of wedlock, TJ had slaves, and AE married then divorced his pregnant first/second cousin.

A similar list of anyone's heros would reveal the same.

We usually don't plan on doing something wrong. Like your example, you think you are doing something good....then more and more you get sucked in. Later on you have to protect your action you thought was right but is now wrong. Best thing: Admit you thought it was right at first but then change it and get past it.

THE PROBLEM is having one set of standards for us and one for others.
Having one set of standards for us and one for others is never right.

One need go no further than LinkedIn to see people rail on one politician for what they praised the other for. Double standards. Non-objectivity. That is the problem. What you do is good because you are you, and you are a good person. What they do is bad, because they are bad people. Does not follow.

Like Martha Stewart. She should have gone to prison as she did. However, I could be her best friend. She just made a bad choice amongst 35 that day.

Here is my fail-safe ethical guideline: I can do whatever I wish to do, but it must be consistent with the greater good.

My cells must work for my organs, or they are a cancer.
My organs must work for my body, or they have failed.
I must work for my community (business, etc.), or I am dysfunctional.
My community must work for the greater good, or it is a cancer on humanity.

We do have to be careful though, for we rationalize our best interest: "Well, it is best if I pollute the waters so I can get wealthy and give to charity and create jobs."

But there are no no-win ethical dilemmas, and here is why: You can always attempt to do the greatest good, in every single situation. As long as you honestly can say you were trying to do the greatest good, with due diligence, you are never "guilty" in an ethical sense, though perhaps in a legal or practical sense you could be.

The system has the right to judge the performance of its parts, so even an appearance of unethical behavior is not good. Generally go with the perception of good by society, unless it is clearly wrong.

We are all just different parts of the same universe, thus our every action must be consistent with the greater good.

Or we can choose to be cancers upon creation. The choice is ours.

The simple answer is to ask if, from a larger perspective, your actions are consistent with the greatest good. To test objectivity you may consider asking if you would still believe it if your opposing religion or political party or economic class were doing the same.

In our every action we create the rules we wish society to have.

But what I have learned from LI and elsewhere, is that people are perfectly happy to have double standards and believe other people are dastardly evil and their heroes saints, both for the very same actions.

You are either working for the system, or against it, and the system goes on from our cells on to infinity. You are either working for the system or against it, and if the system finds you working against it it has every right to take corrective action.

Ironically the highly subjective field of ethics is actually nothing more than systems theory.

Links:

http://www.bevaluable.com

++++++++++++++++

The golden rule has always worked pretty well for me. When confronted with an ethical dilemma, I like to try and determine what the impacts are on various people (i.e., customers, vendors, fellow employees, shareholders, managers, etc.) of a course of action. If I find a course of action has an adverse impact on a particular person or class of persons, I then ask whether or not I would be okay if something like that were to happen to me. If the answer is no, then it is unethical.

+++++++++++++++

These are difficult situations and even more difficult times. My bottom line is, and has been for a long time, "is this something I can tell my wife and children."

I presented this and my other "laws" during the lunch speech at a business marketing conference in 2005 and several people asked for a copy of the speech and two people suggested it become my 2nd book - which it did - Why Epiphanies Never Occur to Couch Potatoes.

At the end of the day, each of us has our reputation to consider, and a mirror to look in.

And I want to know that my decisions are all in the category of "can I tell my wife and children.

Links:

http://www.EpiphanyBook.com

++++++++++++++++

Well, there is the doubt that there are "good" people but there are hundreds of ways to get "caught". Sometimes, there may be doubts about if the catch is a devils trap, a cultural taboo or some kind of political game.

As several others examples point out, there are the traps of lies, following the wrong examples, going along.

Through out the world, more so in poverty but even in professional circles there are the traps of desperation, "I need to do this to make business", "I need to do this for promotion", "I need this to eat next week"

Fundamentally human, are the "following gonads not brains" traps

Not exactly types, but one can also analyze many of these situations as
"slippery slopes", "tar babies" and "best of bad choices"

++++++++++++++++++

Situations like this can be difficult.

I had one experience where a manager forced employees to produce reports about our work that were misleading and, sometimes, outright lies to mask bad leadership decisions. Some on the staff balked, some just went along, others took a route of more passive resistance.

It was interesting and instructive to see the two extremes of the reactions. One staff member, with a background in assessment, saw it not as an ethical debate, but one of "giving the client what they want" (in this case, the "client" being her manager). Another questioned the practice privately, but went along with much enthusiasm. Both got a nice promotion eventually. Those that questioned what we were doing were ostracized and "blackballed" by the manager.

In the end, these things backfire. The manager wound up getting a reputation as being untrustworthy - the hype she was dishing out just didn't match the reality of what people were seeing. She found it more difficult to find quality people to work for her and, as a result, more and more problems kept piling up in the organization that she just couldn't solve.

The sad part about it is that she damaged the reputations and careers of many of her employees in her quest to get promoted.

I just don't want people in my life like that. Lies and dishonesty just keep piling up like unpaid bills. Eventually, someone wants to see results. Someone who's a fake can never really regain respect once it's lost.

+++++++++++++++++

All are expressed opinions, but still, "if your heart or wife (!) doesn't have a problem, why give a damn?".

Money is all honey, if you want to be ethical.

Ethical behaviour in the Job and business

2009-08-19T15:05:00.002+05:30

Found this on Linkedin, a must read for folks with experience.

How do good people get caught in seemingly no-win ethical dilemmas?

Startup and Microsoft

2009-08-14T10:12:00.002+05:30

Read this article on comparing startup with Microsoft...

some decent points to learn.

Successful Startups: Microsoft Wasn't Born Great

--
Regards
Vijayashankar

Startup and Microsoft

2009-08-14T10:12:00.001+05:30

Read this article on comparing startup with Microsoft...

some decent points to learn.

Successful Startups: Microsoft Wasn't Born Great

--
Regards
Vijayashankar

VCs and Startups

2009-07-30T16:02:00.002+05:30

Here are top 7 things you should remember while pitching to potential VCs:

Be ready with your Product

This by far seems to be the most important aspect that VCs see while making a decision – At what stage of development is the product or service. However good your idea may be, very few VCs will be interested in it. Unless and until you have a working product (even if it is prototype), your chances of getting funding diminish drastically.

Your opinion’s don’t matter, hard facts and figures do !

Your opinions don’t matter to VC’s unless you are credible and have been there, done that. To add to it, if VCs have slightest difference of opinion than what you have, your chances of getting funding can come down to zero. It is always safe to stick to facts and figures when making a point.

Know your competition very well

In general, most of us do this quite well, however we need to know our competition from VC’s perspective. The positives / negatives of competitors and how they affect your business. You have to be very clear about the key differentiators between you and your competition.

VCs are skeptics

You need to understand this well. VCs will always look at your idea and product like a die-hard pessimist. They will only put their money in your venture once they get satisfactory answers for every aspect of your startup.

VCs hate outrageous projections

Never, I mean never try to balloon your figures on projections. VCs see right through it. As mentioned earlier, your projections should be based on solid facts and figures (not your opinions). The moment VC feels that figures are too good to be true, they will turn negative.

Be prepared to be grilled

VCs will grill you on anything and everything. Be prepared to answer questions that you may have never even thought. Make attempt at answering if you are confident that you can take it through. If you don’t, say “no”. VC’s will forgive you for not knowing certain things, but never if they feel you are lying.

Never show your desperation

Always be calm and composed while presenting your idea. You should be enthusiastic, but over enthusiasm could come across as desperation. And if VCs smell desperation in your talk, they will think twice before putting even a dime !

VCs and Startups

2009-07-30T16:02:00.001+05:30

Here are top 7 things you should remember while pitching to potential VCs:

Be ready with your Product

Your opinion’s don’t matter, hard facts and figures do !

Know your competition very well

VCs are skeptics

VCs hate outrageous projections

Be prepared to be grilled

Never show your desperation

How to Resolve Project Conflict

2009-07-23T12:49:00.002+05:30

Here's how to face and deal with conflict within your project team...

You need to face conflict and not ignore it, as ignoring it only makes the problem worse. The earlier you face it, the easier it will be to resolve. Here are some examples of conflict you might experience on projects:

Your boss is frustrated with progress and takes it out on you openly, in front of others in your team.
Your colleague wants something from you that you can't give them, or can't do for them within the time frame required so they get angry.
Your staff think you're being unrealistic about time frames, so they handle it badly by raising their voice and being obstructive.

When conflict occurs, take these steps:

Time out: If the other person is getting heated, tell them you need to take five minutes to collect your thoughts. Then make a coffee or go for a walk. This will help you both to calm down and reflect on what has happened.
A pacifier: When you restart your conversation, start with "I know that you're under pressure because of... " This will pacify them a little and will make the atmosphere more positive.
Problem solving: Then agree that a problem exists and that you both need to work together to resolve it constructively. Discuss the various solutions to the problem and try to agree on the pros and cons of each before deciding on the best course of action.
Body language: While all this is happening, you need to focus on your body language. Use open stances. Take your hands out of your pockets and never fold your arms. Try and use slow hand movements. Use a passive voice and don't show emotion. Maintain good eye contact. Listen carefully and watch their body language as well.
A mediator: If the above steps are going poorly, then you need to get someone else involved who can help mediate informally. Tell them you'd like to add a colleague to the conversation as they will have ideas for a solution. Then invite someone who is a good problem solver, whom you trust.
Giving feedback: When the conversation becomes a little more relaxed, it's time to give the person some constructive feedback. Let them know how you would like them to deal with you next time a similar issue comes up. Only by giving positive constructive feedback, can you change their behaviour.

--
Regards
Vijayashankar

How to Resolve Project Conflict

2009-07-23T12:49:00.001+05:30

Here's how to face and deal with conflict within your project team...

Your boss is frustrated with progress and takes it out on you openly, in front of others in your team.
Your colleague wants something from you that you can't give them, or can't do for them within the time frame required so they get angry.
Your staff think you're being unrealistic about time frames, so they handle it badly by raising their voice and being obstructive.

When conflict occurs, take these steps:

Time out: If the other person is getting heated, tell them you need to take five minutes to collect your thoughts. Then make a coffee or go for a walk. This will help you both to calm down and reflect on what has happened.
A pacifier: When you restart your conversation, start with "I know that you're under pressure because of... " This will pacify them a little and will make the atmosphere more positive.
Problem solving: Then agree that a problem exists and that you both need to work together to resolve it constructively. Discuss the various solutions to the problem and try to agree on the pros and cons of each before deciding on the best course of action.
Body language: While all this is happening, you need to focus on your body language. Use open stances. Take your hands out of your pockets and never fold your arms. Try and use slow hand movements. Use a passive voice and don't show emotion. Maintain good eye contact. Listen carefully and watch their body language as well.
A mediator: If the above steps are going poorly, then you need to get someone else involved who can help mediate informally. Tell them you'd like to add a colleague to the conversation as they will have ideas for a solution. Then invite someone who is a good problem solver, whom you trust.
Giving feedback: When the conversation becomes a little more relaxed, it's time to give the person some constructive feedback. Let them know how you would like them to deal with you next time a similar issue comes up. Only by giving positive constructive feedback, can you change their behaviour.

--
Regards
Vijayashankar

Typical breakeven poInt for a Captive Offshore Software Development Group

2009-07-15T23:39:00.000+05:30

We comes across many customers with various ideas, who also have their own IT team.

Software Outsourcing is an art. You basically need to ramp up and down, based on project needs. No harm in sending work to India. At times big MNC's resort to having their own Captive Offshore Development Group.

What would be the Typical breakeven point for a Captive Offshore Software Development Group?

Will it all depends. If you have an order book and a project list that gives you sufficient comfort that you will be able to offer employees a good job with career development potential, then you can take on permanent hires rather than contractors straightaway.

On the other hand, if the nature of the software projects being worked on is such that the skill sets required vary greatly from project to project, then it may be better to develop a business around a network of consultants that you know and trust, where you pull in the right people for the right job on an ad hoc basis.

I'd imagine one that a lot of Small/Medium operators would be wrestling with....

Unfortunately, I don't believe there's a fixed formula. There are too many factors (current profitability/ costs of staffing a centre/ staff profile of offshore talent/tolerance for risk etc) to provide a definitive answer.

I would strongly reccomend them to have them plan out the two ( or three) business scenarios over the next 3 years and compare the forecasted outcomes. I think the answer would become apparent.

- Assess their real motivation for change (increased profitability/ scalability etc)

Assuming a motivator of profitability,

- Create a revenue forecast based on current & ongoing growth (with respect to the offshore sourcing)
- risk profile of sustained growth (diversification of clients, repeat business etc)

offset these with:

- TCO of each employee (full time) vs contractor rates (which I assume attract a premium)
- What other costs are required to staff a centre (e.g company/training/management overheads). There will be fixed component + incremental $ for each employee
- What value do you get from a full time employee vs a contractor in an offshore situation?
- What must you offer as a full time employee to the offshore talent? There could be some hidden premiums...

Scenario 1: All contract

Scenario 2: All full time

Scenario 3: Hybrid (reduce risk of people on bench/answer resource demand spikes

- run the numbers across the FTE scenarios you outlined and see where it lands. This ideally would put them in a more informed position to assess their situation and ideally make a call.

Generally, profitability will temporarily suffer while taking up the cost of the center overhead. This should be factored. Dont be afraid to drop a project, midway, if it is going no where. Money saved is money earn't!

Fashionably Mysterious

2009-07-14T19:07:00.002+05:30

Dear friends I found this article on http://www.personalmba.com an interesting site for learning Biz Management, by Josh Kaufman!

The Dangers of Mystique

Fashionably Mysterious

There's a big difference between liking the idea of being/doing something and liking the actual being/doing.

It's easy to like the idea of being the CEO of a Fortune 50. It's harder to like the hours, the responsibility, and the pressure that comes with the top job.

It's easy to like the idea of being a manager. It's harder to like the demands from C-level execs, surprises from your direct reports, and the necessity of defending your turf in a political environment.

It's easy to like the idea of getting an Ivy-League MBA or law degree. It's harder to like the six-figure debt and the corresponding necessity of getting a 120-hour-a-week job to make the investment "worth it."

It's easy to like the idea of being self-employed. It's harder to like the fact that 100% of your income comes from your own effort, and if you screw up, you're the one that will face the consequences.

It's easy to like the idea of raising millions of dollars of venture capital. It's harder to like the fact that you've given up control over the project you're investing your life in.

It's easy to like the idea of being an author or professional blogger. It's harder to like the solitude, uncertainty, and the long hours of "butt in chair, hands on keyboard" that consistent writing requires.

It's easy to like the idea of being a celebrity. It's harder to like the scrutiny, loss of privacy, and constant fear that people will direct their attention away from you in favor of the "next big thing."

It's easy to like the idea of being a supermodel. It's harder to like strictly controlling your diet, constant workouts, and hour-upon-hour of sitting still for the camera.

It's easy to like the idea of being a Broadway star. It's harder to like the endless auditions, evenings of waiting tables, and recognition that – even after landing a high-profile show – you'll probably be out of work again in a few months.

It's easy to like the idea of being a secret agent or special forces commando. It's harder to like people shooting at you.

Mystique is a powerful force – a little mystery makes most things appear a lot more attractive than they actually are. Fortunately, there's an easy way to counteract the rose-colored glasses of mystique: have a real human conversation with someone who's actually done what you're attracted to. Here's what to ask:

"I really respect what you're doing, but I imagine it has high points and low points. Could you share them with me? Knowing what you know now, is doing this worth it?"

It only takes a few minutes, and you'll be amazed by what you learn, both on the positive or negative side.

No job, project, or position is flawless – every course of action has benefits and drawbacks. Learning what they are in advance gives you a major advantage: it allows you to examine an option without idealizing it, then choose if it's really what you want to do with your time before you start. That kind of knowledge is priceless.

Like this post? Be sure to share it with a friend or colleague!

:-)

Fashionably Mysterious

2009-07-14T19:07:00.001+05:30

Dear friends I found this article on http://www.personalmba.com an interesting site for learning Biz Management, by Josh Kaufman!

The Dangers of Mystique

Fashionably Mysterious

There's a big difference between liking the idea of being/doing something and liking the actual being/doing.

It's easy to like the idea of being the CEO of a Fortune 50. It's harder to like the hours, the responsibility, and the pressure that comes with the top job.

It's easy to like the idea of raising millions of dollars of venture capital. It's harder to like the fact that you've given up control over the project you're investing your life in.

It's easy to like the idea of being a supermodel. It's harder to like strictly controlling your diet, constant workouts, and hour-upon-hour of sitting still for the camera.

It's easy to like the idea of being a secret agent or special forces commando. It's harder to like people shooting at you.

"I really respect what you're doing, but I imagine it has high points and low points. Could you share them with me? Knowing what you know now, is doing this worth it?"

It only takes a few minutes, and you'll be amazed by what you learn, both on the positive or negative side.

Like this post? Be sure to share it with a friend or colleague!

:-)

Some Architectural snippets on JAVA, J2EE and Web

2009-07-13T11:59:00.002+05:30

When migrating a web-based solution to a J2EE solution, you need to consider the requirements of the original solution as opposed to taking the route of replacing like with like, e.g. replacing ASP with JSP.

It may be the case that a solution using PHP and PERL technologies to handle presentation and business logic (and in some cases transaction management), could be better separated in J2EE with presentation logic being handled by JSP and Servlets and business logic by EJBs. (If transactions are involved in almost all cases, this is enough justification for using a separate application server and Enterprise JavaBeans.)

***

Use AJAX for repeated refreshes in web pages. Gmail uses this! ( note - 5 years Beta, solidly tested ).

Ajax neither reduces browser-compatibility issues nor improves security in anyway. Ajax will not work if Javascript is disabled because Ajax is basically a combination of Java Script and XML.

***

You are architecting a new web based labor claim management application. Currently the users have a Java Swing-based application running on their local PCs, and you want to implement the new web-based solution with a GUI that is similar to their desktop application. Once the users have filled in their hours then you must send the details to central labour system through a Web service.

What of the following technologies would be required for building this application?

UI can be built using JSF and the web service may be invoked through a JAX-WS client.

The Java Message Service (JMS) API is an API for accessing enterprise messaging systems. The Java Message Service makes it easy to write business applications that asynchronously send and receive critical business data and events. It defines a common enterprise messaging API that is designed to be easily and efficiently supported by a wide range of enterprise messaging products. It supports both message queueing and publish-subscribe styles of messaging.

The Java Secure Socket Extension (JSSE) enables secure Internet communications. It provides a framework and an implementation for a Java version of the SSL and TLS protocols and includes functionality for data encryption, server authentication, message integrity, and optional client authentication. Using JSSE, developers can provide for the secure passage of data between a client and a server running any application protocol, such as Hypertext Transfer Protocol (HTTP), Telnet, or FTP, over TCP/IP.

The Java Cryptography Extension (JCE) provides a framework and implementations for encryption, key generation and key agreement, and Message Authentication Code (MAC) algorithms. Support for encryption includes symmetric, asymmetric, block and stream ciphers.

***

You are currently designing your own Desktop Publishing application, as you have not found any existing application that does exactly what you want. As part of the design, you are using a Controller to which you send all GUI requests. Not all objects can process the same commands.

For example, you cannot select the spell check tool when an image has the focus. To stop any possible errors, you would like to filter out some of the messages as they are passed from these objects to the Controller object. What pattern could you use?

Firewall and Filter are not design patterns. In this scenario, what you are essentially trying to do is filter all packets that do not meet a certain set of requirements. This behavior is just like a Proxy server dropping packets from certain IP address etc.

Proxy - (GOF 207): "Provide a surrogate or placeholder for another object to control access to it."

The other patterns:

Adapter - (GOF 139):"Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces."

Observer - (GOF 293):"Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically."

Chain of Responsibility - (GOF 223):"Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it."

***

Both the Abstract Factory and Factory Method are Creational patterns.

Abstract Factory - (GOF 87): "Provide an interface for creating families of related or dependent objects without specifying their concrete classes."

Factory Method - (GOF 107): "Define an interface for creating an object, but let subclasses decide, which class to instantiate. Factory Method lets a class defer instantiation to subclasses."

***

The current application has been built using JSF & a custom persistence framework. You have been approached to expose some of the data as a EJB to another J2EE application. You may need to access multiple business objects to provide the data.

Use Session Facade.

See description of patterns.
Application Service - Application Service centralizes and aggregates behavior to provide a uniform service layer to the business tier services. An Application Service might interact with other services or Business Objects. An Application Service can invoke other Application Services and thus create a layer of services in your application.

Session Facade - Session Facade provides coarse-grained services to the clients by hiding the complexities of the business service interactions. A Session Facade might invoke several Application Service implementations or Business Objects. A Session Facade can also encapsulate a Value List Handler.

The Service to Worker pattern, like the Dispatcher View pattern, describes a common combination of other patterns from the catalog. Both of these macro patterns describe the combination of a controller and dispatcher with views and helpers. While describing this common structure, they emphasize related but different usage of patterns. Both of these patterns differ in division of labour among components(Controller, Dispatcher and View).

In Dispatcher View content retrieval is done by View and in case of Service To worker content retrieval is done by controller.

Business Delegate - Business Delegate reduces coupling between remote tiers and provides an entry point for accessing remote services in the business tier. A Business Delegate might also cache data as necessary to improve performance. A Business Delegate encapsulates a Session Facade and maintains a one-to-one relationship with that Session Facade. An Application Service uses a Business Delegate to invoke a Session Facade.

***

Polymorphism is a characteristic of being able to assign a different behavior or value in a subclass, to something that was declared in a parent class.

For example, a method can be declared in a parent class, but each subclass can have a different implementation of that method.

Inheritance is the ability of objects in Java to inherit properties and methods of other objects.

An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer."

Encapsulation (also information hiding) consists of separating the external aspects of an object which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects.

***

Every Java object implicitly extends java.lang.Object class. What is this design concept?

It describes Inheritance. All Java objects extend Object class implicitly and also inherit methods such as toString().

Polymorphism is a characteristic of being able to assign a different behavior or value in a subclass, to something that was declared in a parent class. For example, a method can be declared in a parent class, but each subclass can have a different implementation of that method. Inheritance is the ability of objects in Java to inherit properties and methods of other objects.

An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer."

Encapsulation (also information hiding) consists of separating the external aspects of an object which are accessible to other objects, from the internal implementation details of the object, which are hidden from other objects.

***

What is the difference between Maintainability and Manageability in Software Engineering?

Maintainability (Cade 8) "is the ability to correct flaws in the existing system without impacting other components of the system" and Manageability (Cade 9) "is the ability to manage the system to ensure the continued health of a system with respect to scalability, reliability, availability, performance and security."

***

It provides a convenient way to bind an XML schema to a representation in Java code. This makes it easy for you to incorporate XML data and processing functions in applications based on Java technology without having to know much about XML itself. Which of the following is the API described above?

JAXB - Java Architecture for XML Binding (JAXB) provides a convenient way to bind an XML schema to a representation in Java code. This makes it easy for you to incorporate XML data and processing functions in applications based on Java technology without having to know much about XML itself.

SAAJ - The SOAP with Attachments API for Java (SAAJ) provides a standard way to send XML documents over the Internet from the Java platform. SAAJ 1.3 EA (with support for SOAP 1.2) is shipped in Java WSDP 2.0.

JAXR - The Java API for XML Registries (JAXR) provides a uniform and standard Java API for accessing different kinds of XML Registries. An XML registry is an enabling infrastructure for building, deploying, and discovering Web services.

JAXP - The Java API for XML Processing (JAXP) enables applications to parse, transform, validate and query XML documents using an API that is independent of a particular XML processor implementation. JAXP provides a pluggability layer to enable vendors to provide their own implementations without introducing dependencies in application code.

***

You have developed an application consisting of Java EE Stateless session beans. Methods of these beans use simple Java types. You would like to convert them to web services. How can you achieve it?

You can use annotations like @WebService and @WebMethod. They are automatically deployed as web services.

. web.xml does not have any such entries.

. resource injection is a mechanism that removes the burden of creating and initializing common resources in a Java runtime environment.

. ejb-jar.xml does not have any such entries.

***

EJB 3.0 offers simplified entity programming model.

Java Entity is a POJO class but not an EJB, so it does not require any Local/Home interfaces. Entities may either use persistent fields or persistent properties.

If the mapping annotations are applied to the entity's instance variables, the entity uses persistent fields.

If the mapping annotations are applied to the entity's getter methods for JavaBeans-style properties, the entity uses persistent properties. You cannot apply mapping annotations to both fields and properties in a single entity.

Simple primary keys use the javax.persistence.Id annotation to denote the primary key property or field. Composite primary keys are denoted using the javax.persistence.EmbeddedId and javax.persistence.Id Class annotations.

In the Java Persistence API, you no longer need to provide a deployment descriptor. JPA supports complex relationships between Entities.

***

A typical JSF application contains

A set of JSP pages (although you are not limited to using JSP pages as your presentation technology)
A set of backing beans, which are JavaBeans components that define properties and functions for UI components on a page
An application configuration resource file, which defines page navigation rules and configures beans and other custom objects, such as custom components. Usually named faces-config.xml
A deployment descriptor (a web.xml file)
Possibly a set of custom objects created by the application developer. These objects might include custom components, validators, converters, or listeners.
A set of custom tags for representing custom objects on the page
validations.xml is not part of JSF.

***

Real Time Web based Application can be built using JSP for UI, stateless session beans for business services and EJB3 entities for persistence.

***

The JavaServer Pages Standard Tag Library (JSTL) encapsulates, as simple tags, core functionality common to many JSP applications.

***

You have a requirement that the PIN of the customer used for ATM transactions must be encrypted using a one-way encryption algorithm to prevent data theft.

You should use SHA encryption. http://en.wikipedia.org/wiki/SHA_hash_functions

3DES is a symmetrical encryption algorithm.

Blowfish is a symmetrical encryption algorithm.

RSA is a asymmetrical encryption algorithm.

--
Regards
Vijayashankar

Some Architectural snippets on JAVA, J2EE and Web

2009-07-13T11:59:00.001+05:30

A set of JSP pages (although you are not limited to using JSP pages as your presentation technology)
A set of backing beans, which are JavaBeans components that define properties and functions for UI components on a page
An application configuration resource file, which defines page navigation rules and configures beans and other custom objects, such as custom components. Usually named faces-config.xml
A deployment descriptor (a web.xml file)
Possibly a set of custom objects created by the application developer. These objects might include custom components, validators, converters, or listeners.
A set of custom tags for representing custom objects on the page
validations.xml is not part of JSF.

Securing Company systems over Web

2009-07-13T11:41:00.002+05:30

The company web server needs to serve pages to remote users and office machines need access to the internet.

Given the above architectural system specification you should secure it by creating a DMZ that contains the company web server.

You should put machines that provide services to Internet clients in the DMZ and the office machines and development servers behind an inner firewall.

You would then configure a proxy server in the DMZ to forward the requests from the office machines to the Internet.

***

What are the solutions available, if planning for interfacing with existing CORBA systems. You can use Java IDL to integrate with these other systems.

The following is taken from: http://java.sun.com/j2se/1.3/docs/guide/idl/index.html

Java IDL adds CORBA (Common Object Request Broker Architecture) capability to the Java platform, providing standards-based interoperability and connectivity.

Java IDL enables distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard IDL (Object Management Group Interface Definition Language) and IIOP (Internet Inter-ORB Protocol) defined by the Object Management Group. Runtime components include Java ORB for distributed computing using IIOP communication.

Java IDL should not be used when servicing requests from CORBA clients and the reference to messaging is a red herring.

How does a predominantly EJB based J2EE application that has to be accessed by CORBA clients? Which connectivity option would you recommend?

RMI-IIOP stands for Remote Method Invocation (using IIOP as the transport.) This is the protocol supported by EJB1.1

**

What if you are Streaming information of the network?

StAX provides a standard, bidirectional pull parser interface for streaming XML processing, offering a simpler programming model than SAX and more efficient memory management than DOM.

StAX enables developers to parse and modify XML streams as events, and to extend XML information models to allow application-specific additions.

Below is an excerpt from Java EE tutorial.

Streaming refers to a programming model in which XML infosets are transmitted and parsed serially at application runtime.Stream-based parsers can start generating output immediately, and infoset elements can be discarded and garbage collected immediately after they are used.Streaming models for XML processing are particularly useful when your application has strict memory limitations, as with a cell phone running J2ME, or when your application needs to simultaneously process several requests, as with an application server. Streaming pull parsing refers to a programming model in which a client application calls methods on an XML parsing library when it needs to interact with an XML infoset; that is, the client only gets (pulls) XML data when it explicitly asks for it. Streaming push parsing refers to a programming model in which an XML parser sends (pushes) XML data to the client as the parser encounters elements in an XML infoset; that is, the parser sends the data whether or not the client is ready to use it at that time.

***

Use a VPN (Virtual Private Network) to connect to company networks. Mostly applications exclusive and sharing of data, should use this. This is better than using Firewalls, over internet.

--
Regards
Vijayashankar

Securing Company systems over Web

2009-07-13T11:41:00.001+05:30

Various Methods of Web Attacks

2009-07-13T11:29:00.001+05:30

A Denial-of-Service attack (also DoS attack) is an attack on a computer system or network that causes a loss of service to users. Usually it is realized through consuming all of the bandwidth available to the victim network or by overloading the computational resources of the victim system. It can be prevented by using Service Request Queue technique - limiting the number of concurrent requests one application can get while queuing all excess requests.

A Man-in-the-Middle (MitM) attack is a technique where an attack intercepts another user's session, inspects its contents and tries to modify its data or otherwise use it for malicious purposes. Measures to prevent these attachs are to use encryption of sensitive data and prevent the data being read. Some examples are using SSL, avoiding Frames/IFrames, avoid URL rewriting (SessionId is exposed).

Cross Site Scripting (XSS) is a type of computer security exploit where information from one context, where it is not trusted, can be inserted into another context, where it actually is trusted. From the trusted context, attacks can be launched.

Cross site scripting (also known as XSS) occurs when a web application gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, instant message, or simply just reading a web board or email message.

Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website.

Some of the measures to prevent it : encode the data on the generated pages, escape user input (special characters,tags), validate user input(maximum length) using Frameworks like Struts Validator, users disable javascript, avoid using Frames/IFrames.

Phishing is an attempt to criminally and fraudulently acquire sensitive information, such as usernames, passwords and credit card details, by masquerading as a trustworthy entity in an electronic communication. Phishing is a social engineering technique to fool users.

--
Regards
Vijayashankar

Various Methods of Web Attacks

2009-07-13T11:29:00.000+05:30

How to hire the right person for Top management?

2009-07-11T20:16:00.002+05:30

Fill a room with 100 bricks in some particular order and close it (with an open window)
Then send 2 or 3 candidates in the room and close the door.
Leave them alone and come back after 6 hours and then analyze the situation.
If they are counting the bricks.
Put them in the accounts department.
If they are recounting them.
Put them in auditing.
If they have messed up the whole place with the bricks.
Put them in engineering.
If they are arranging the bricks in some strange order.
Put them in planning.
If they are throwing the bricks at each other.
Put them in operations.
If they are sleeping.
Put them in security.
If they have broken the bricks into pieces.
Put them in information technology.
If they are sitting idle.
Put them in human resources.
If they say they have tried different combination's, yet not a brick has been moved.
Put them in sales.
If they have already left for the day.
Put them in marketing.
If they are staring out of the window.
Put them on strategic planning or owner's office.

And at last........................
If they are talking to each other and not a single brick has been moved.

Congratulate them and put them in top management.

--
Regards
Vijayashankar

How to hire the right person for Top management?

2009-07-11T20:16:00.001+05:30

Be like this boy

2009-07-09T10:41:00.002+05:30

Be Positive Like This Boy

A beautiful Madam was having trouble with one of her students in 1st Grade class. Madam asked,'Boy. what is your problem?'

Boy answered, 'I'm too smart for the first-grade. My sister is in the third-grade and I'm smarter than she is! I think I should be in the 4th Grade!'

Madam had enough. She took the Boy to the principal's office. While the Boy waited in the outer office, madam explained to the principal what the situation was. The principal told Madam he would give the boy a test and if he failed to answer any of his
questions he was to go back to the first-grade and behave.She agreed.

the Boy was brought in and the conditions were explained to him and he agreed to take the test.

Principal: 'What is 3 x 3?'
Boy.: '9'.

Principal: 'What is 6 x 6?'
Boy.: '36'.

And so it went with every question the principal thought a 4th grade should know. The principal looks at Madam and tells her, 'I think Boy can go to the 4th grade.'

Madam says to the principal, 'I have some of my own questions.

Can I ask him ?' The principal and Boy both agreed.

Madam asks, 'What does a cow have four of that I have only two of'?

Boy, after a moment 'Legs.'

Madam: 'What is in your pants that you have but I do not have?'

Boy.: 'Pockets.'

Madam: What starts with a C and ends with a T, is hairy, oval,
delicious and contains thin whitish liquid?

Boy.: Coconut

Madam: What goes in hard and pink then comes out soft And sticky?

The principal's eyes open really wide and before he could stop the answer, Boy was taking charge.

Boy.: Bubblegum

Madam: What does a man do standing up, a woman does sitting down and a dog does on three legs?

The principal's eyes open really wide and before he could stop the answer..

Boy.: Shake hands

Madam: You stick your poles inside me. You tie me down to get me up. I get wet before you do.

Boy.: Tent

Madam: A finger goes in me. You fiddle with me when you're bored. The best man always has me first.

The Principal was looking restless, a bit tense and took one large Patiala Vodka peg.

Boy.: Wedding Ring

Madam: I come in many sizes. When I'm not well, I drip. When you blow me, you feel good.

Boy.: Nose

Madam: I have a stiff shaft. My tip penetrates. I come with a quiver.

Boy.: Arrow

Madam: What word starts with a 'F' and ends in 'K' that means lot of heat and excitement?

Boy.: Fire truck

Madam: What word starts with a 'F' and ends in 'K' & if u don't get it, u have to use ur hand.

Boy.: Fork

Madam: What is it that all men have one of it's longer on some men than on others, the pope doesn't use his and a man gives it to his wife after they're married?

Boy.: SURNAME.

Madam: What part of the man has no bone but has muscles, has lots of veins, like pumping, & is responsible for making love ?

Boy.: HEART.

The principal breathed a sigh of relief and said to the teacher,

'Send this Boy to
IIM AHMEDABAD (Indian Institute Of Managment)
I got the last ten questions wrong myself!'

Be like this boy

2009-07-09T10:41:00.001+05:30

Need for Travel Domain Services

2009-07-04T19:25:00.000+05:30

Happy Independence Day USA! May the 4th of July get the best of the country!

***

Here are some of the points, that highlight Need for Travel Domain Services!

Some of the organizations that would service, but not limited to... in an exclusive format to cater to travel industry...

Airlines
Attractions/Theme Parks
Bed & Breakfast Houses
Bus/Taxi/Limousine Operators
Camp Facility Operators
Car Rental Companies/Airport Specialty Car Park Companies
Computer Reservation/Travel Technology Provider
Convention & Visitor's Bureaus
Cruise Lines
Ferries
Hotels/Resorts/Casinos
National Tourism Offices
Passenger Rail Lines
Restaurants
Tour Operators
Travel Agents
Travel Media
Travel-Consumer and Market Research Organizations

Why do we need the exclusivity?

"Doing Business As", or "Trading" Name
Trademark (registered, or by use)
Domain Name used as a trading name
Service Mark (registered, pending or by use)
Product Name (by registered copyright or use)
Division Name (by use)
Subsidiary Name (wholly-owned or controlled)
Promotion or Venture Name (by use)
Partnership Name (by registration or use)
Club Name (by use)
Competition, Games or Event Name (registered, pending or by use)
Transport Vessel Name (registered)
Acronyms of an eligible name where such acronym is not less than three letters (e.g. ABC.travel)

For the above the ICANN register has come up with .travel ( specific ) to help the travel industry!

Hence we at Sharon Software Systems, would provide the portal, that is exclusive for Travel Industry in the following ways

The Exclusive Travel Portal should contain

Reservation Software
Inventory Management
Corporate Relationships
Customer Relations Management
Special Deals and Offers

Above all, there should be problem SEO, Marketing done online, for which we would provide exclusive services.

Travel Domain

2009-07-02T18:59:00.000+05:30

We are coming up with various specific software solutions that cater to travel domain.

This will be hosted on our exclusive portal SaasServices.in

Status Of our Venture Indiarealestventure.com

2009-07-01T18:20:00.000+05:30

I am here to inform about the Status Of our Venture Indiarealestventure.com

Still in stealth mode. Yet to get finances for a full fledged office.

What we have completed is

- a CRM to handle the complete back end operations including call management. You can connect to any other database. We are using MySQL, an opensource DB, which will charge very less on commercial deployment.

- Study of Microsoft Silverlight and customization of the latest Beta ver 3.0 is going on. We have got few pro bono workers!

- Other than real estate portals we are also involving ourselves with the customization of these CRM modules for Sharon Software Systems, Saas ventures hosted on various websites like saassystems.in, saasservices.in and saasplatform.in

Building a team: Discussion

2009-06-22T16:41:00.002+05:30

Building a company team is much more complex and revolves around your business plan. You need revenue projections along with employee costs to proceed. I would recommend you hire an experienced consultant to guide you or put together an advisory team/board of entrepreneurs who have started businesses and made them successful.

***
The concept plan will define your product/service and allow you to flesh out the idea. Key facets of this should at least include: a description of the website's function and a proposal of the value added to its users; a(n at least basic site map); a flowchart describing the process of building the site; and design and usability considerations.

The strategic plan will allow you to identify the business model you are expecting to employ. If done right, it should be straightforward (though sometimes difficult) to construct it in a way that connects the dots. In my opinion, every strategic plan should include: a description of your core principles as an organization (vision/mission/goals/values); an analysis of your internal resources and external market environment (not limited to your presumed customer base); strategic options and a description of your choice as well as an explanation of 'why'; a plan for implementation of the strategy - including needed resources; expectations of performance (operational/market/financial); a description of relevant metrics you can use to gauge your business' performance; and a plan for how to monitor and respond to changes in your operations and/or market.

***
Developing your team of core advisors and mentors is very important, as I'm sure you already know. It sounds like you need some advisors/mentors just for general business purposes - and at least 1 or 2 that specialize on the web side.

Just my opinion, but I'd start by scanning through your business plan to determine core areas needed to get your business going. That will help you determine what KIND of advisors you need. You are particularly looking for people with skills you don't have. As an example, I have an accounting degree, so when I was looking for core advisors, I did NOT look for an accountant, since I would fill that slot, myself. If you can interest a lawyer and someone with an accounting/finance background, that's a real plus. For web models, I'd also say a really energetic, up-to-date marketing person would be a tremendous plus. The marketing person should be very knowledgable about current and up-coming web and new media (like i-Phone, etc.), able to evaluate what is working, all the legal requirements, etc., since all of these will, ultimately, be a part of your big picture.

On the web side, someone very strong in web development from the IS side - and, if you can get two, one who is also strong on web commerce (if this will be an e-commerce site). I have discovered that some folks who are terrific at innovative web design and management aren't as strong on e-commerce, which has a lot of legal and technical areas that are vital.

Once you've figured out what kind of advisors and mentors you need - I'd say no more than 8-10 people with 6-8 people being ideal - you can start strategizing on how to get them!

Depending on where you live, an area university or your alma mater may have a program that matches graduate students in a specific area with projects. A law school may have a free law program similar to that. I live in Nashville, TN, and Vanderbilt University does both of these. It's not just for start ups - some really big companies use these services. If your alma mater has an online business connection, sometimes folks from your school might be interested and willing to help - or identify someone for you.

Another way is to become active in some organizations that people that you need are likely to belong to. I belong to the American Marketing Association for just that reason. Check FaceBook for professional listings. Some pros participate in FaceBook. Even if they aren't available for a low cost, they frequently can match you up with someone good who is - or you may find them by visiting a page frequently and observing their posts. I have met an excellent career coach through LinkedIn, for example.

Networking is a really big key, but it needs to be networking with people who have what you are looking for, not just social events and business-card-swaps. Don't be bashful about "telling your story" over and over again. Come up with a couple of short pitches (one 2 minute one and one 5 minute one) that will explain what you are trying to do. That won't bore the people who will eventually say, "Oh, yeah, I have a friend that would be interested in that" . . . or "does that" and will be willing to give you an e-mail or contact to get in touch with them. And, if they are interested themselves, they will let you know and you can go into more detail. A lot of this is really viral and on-the-spot. The big thing on networking is to have a plan. Plan 1) what you are going to; 2) who you want to talk to; 3) what you plan to say to them; and 4) what you are trying to get (contacts, etc.). You'll get better results that way.

A lot of cities have Small Business centers that provide a LOT of help with this. Check and see if there is one in your area. They are frequently free. And, many Chambers of Commerce have programs that can help, too. Some of the COC programs are free - some cost some money, but not usually very much.

***
Its a very dangerous trap "if I build it they will come". I've fallen into that trap myself in the past and paid in time and money. Validate your business model first.

Does your product address a pain point?
Is your pain point recognized?
Is the pain great enough that people are willing to pay for it? (I can't stress this point high enough)
Will the payment model support the business both in start up and as it grows?

Second prototype and model your product. You should take an iterative approach starting with detailed static mockups, framework functions, etc. and validate, validate, validate with leaders in the industries or markets you want to capture. I've found great value in paying a graphic designer to produce myriad static displays (in fine detail) so that I could "show" the functions and collect feedback early on. An additional benefit is the coding team will have a much better understanding of what the final product should look like and how it should behave. They will also insert a number of technical requirements that would be missed otherwise.

Warning... you need a graphic designer that has worked with a development team before. They need to inject realism in the static product. It would also be helpful to finalize your business requirements. What is the end product supposed to achieve. Which of course dove tails in the business modeling.

An additional point of warning. Off shoring can work very well particularly if you've managed other development projects and have a good understanding of the process, the requirements and acting as a business owner for a project. Off shoring has its negatives including language barriers, cultural misunderstandings, time zone craziness, cost barriers to face-to-face engagements and challenges in aligning business requirements to technical requirements. If you've never done this before and you want to try this approach, get someone to coach you who has experience with this.

***

Also http://www.8kmiles.com is a wonderful concept to pull in a team, virtually.

***

Do not believe in free tools, or pro bono work or free items / widgets. Build up from scratch, you might have sometime and something to show to VC's and Angels.

You can also mail me at vijayashankar dot india @ gmail for many inputs, I can share.... if you can get me some venture / angel funding for my venture http://www.indiarealestventure.com

Building a team: Discussion

2009-06-22T16:41:00.001+05:30

True entrepreneurs vs. "get rich quick" vs. cool sites with no revenue.

2009-06-19T16:46:00.003+05:30

After reading through several posts both in this group and plenty others geared towards startups/entrepreneurs/web 2.0,3.0 etc. I had some thoughts...

Having worked with a lot of startups and talked to 100X more than that, there's some very clear distinctions between the true entrepreneurial startup, and someone who just has a cool idea for a site but no business behind it.

First off, building a cool site, lets say a new Twitter application, with absolutely no revenue possibilities doesn't make you an entrepreneur. It makes you good at building sites that are "neat". Sure people might come to your site. Throw up a few Google ads, maybe make a few dollars. Really though, sustainable business? Have a growth strategy? It's easy to put on paper "our site will continue to grow at an exponential rate" and associate higher and higher ad revenues with this, but in reality, if it's that great, someone will copy it. And chances are, it's just not that great, sorry.

The get rich quick companies almost aren't worth discussion. Their blatent posts in attempts to lure anyone willing to throw money at them are laughable. It's sad to think people still get drawn into pyramid schemes and ideas of grandeur that really wouldn't take long to think about in terms of a business, and realize there's nothing there. I've often found anyone who contacts me with the more passion and enthusiasm than actual information and conceptual facts about their business, doesn't have one. It usually goes hand in hand with them talking extensively about how much money everyone involved is going to make, and that alone should be why I should or anyone should be involved. Sorry guys, I've been around the block enough times to spot you a mile away.

True entrepreneurs, these are the guys and girls that keep me going. Passion, spirit, dynamic, an actual business model, experience in the industry they are entering are just a few traits. They know how to command a team, have realistic ideas about what it takes to start a company, how long it takes to really ramp up revenues, and what expenses they'll incur.

Any thoughts? Agree, disagree, think I'm a startup snob? I'm the first one to admit I am, but when you are amongst a sea of fools, you have to have some qualifiers to find those rare few.

True entrepreneurs vs. "get rich quick" vs. cool sites with no revenue.

2009-06-19T16:46:00.002+05:30

The 7 Habits of Highly Effective Developers

2009-05-14T16:24:00.002+05:30

The 7 Habits of Highly Effective Developers

If you want to achieve your highest aspirations and overcome your greatest challenges, identify and apply the principle or natural law that governs the results you seek. How we apply a principle will vary greatly and will be determined by our unique strengths, talents, and creativity, but, ultimately, success in any endeavor is always derived from acting in harmony with principles to which the success is tied. This advice comes from Steven Covey in his best-selling book, The 7 Habits of Highly Effective People. If you haven't read this book yet, you must. It's about effecting change from the inside out for success in both your personal and professional life by aligning your values with principles through practicing seven habits. Before reading this book, I felt like a passenger on a career freight-train. like something put in motion that I was powerless to control. What I was practicing in my career, my habits, was misaligned with my values, and my values were misaligned with unmovable principles. Although I was powerless over the career train, I came to realize I had the power to choose which train I was on. So here I am at a company that allows me to follow my passion: developing software.

The 7 Habits book is broadly focused, and it made me think about habits specific to my profession. What do those software developers that I consider effective (if not brilliant) have in common? What values drive their decisions and what habits do they practice that make them successful? Here are the seven habits that I think effective developers practice:

Passionate

The most brilliant people I've worked with are passionate about what they do. They aren't driven by money and fame and, I say this with tongue in cheek, if they didn't have families to feed, would develop software without compensation. If I had two candidates for a development position, I'd rather hire a less-experienced person with passion than a more experienced person without. If you aren't passionate about software development, find what you are passionate about and follow that path.

Able to Learn, Unlearn and Re-learn

I believe that learning is an extension of passion, and effective developers operate in a continuum of improvement and innovation. They learn from their and others' mistakes and don't apply old solutions to new problems just because they worked before. Effective developers follow technology, but are careful to not let new approaches become solutions looking for a problem.

Balance Principle and Practice

Principle and practice are the Yin and Yang of software development. Effective developers don't design impractical solutions for the sake of principle and don't implement solutions without overarching values. They are willing to compromise based on time, cost, scope and quality constraints, but can also obtain compromise from others based on sound principles.

Keep It Simple Software (KISS)

Effective developers implement the simplest possible thing that will work while not painting themselves into a corner. They don't implement anything more than is needed right now, remaining mindful about what might be needed in the future. Effective developers know that the less moving parts there are, the less likely it will break and favor elegance and simplicity over convoluted cleverness.

If You Don't Know the Answer, Know Someone Who Does

Software developers aren't renown for their social prowess, but some of the most effective developers I know are excellent at networking. If you give a random 100 question test to a group of people, no one individual will score 100%, but collectively, with few exceptions, the group can answer all the questions correctly. There is so much technology, so many areas of speciality, you can only be an expert on one, maybe two subject areas. Effective developers know the limit of their knowledge, aren't afraid to admit when they don't know something and have many friends and colleagues in their network they can reach out to for help.

Focus on Value

Effective developers understand the forces driving the project, its stakeholders and their goals. Using this knowledge to guide their decision making, they focus on delivering tangible value to their customers over anything else. Effective developers prioritize work based on its value--the so called "bang for the buck," and avoid projects and features they don't believe in.

Puts the Needs of the Many Before the Needs of the One

I've seen small teams accomplish extraordinary things; it's amazing what "two guys and a laptop" can accomplish. Call it teamwork or synergy or whatever you like, when a group of people put common goals before their own, they converge like light into a laser beam. Contrast this with the arrogant, rogue and cowboy developers who go against team standards or design intents because "that's how I do it" or "that's how you should do it." The message they are really sending is "I am smarter than the team."

Conclusion

These seven habits give me something to work towards and keep me focused. I only had room for seven habits in this article, and I'm sure you can think of many more or define effective in your own way. The important thing is to take a value-driven approach to your software development career and do intentional things that move you towards your definition of success.

--
Regards
Vijayashankar

The 7 Habits of Highly Effective Developers

2009-05-14T16:24:00.001+05:30

The 7 Habits of Highly Effective Developers

Passionate

Able to Learn, Unlearn and Re-learn

Balance Principle and Practice

Keep It Simple Software (KISS)

If You Don't Know the Answer, Know Someone Who Does

Focus on Value

Puts the Needs of the Many Before the Needs of the One

Conclusion

--
Regards
Vijayashankar