Saas Cloud

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

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:

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

Scrum Methodology

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

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

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?

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

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

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

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?

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?

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

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:

1. Appreciation of a system: understanding the overall processes involving suppliers, producers, and customers (or recipients) of goods and services (explained below);
2. Knowledge of variation: the range and causes of variation in quality, and use of statistical sampling in measurements;
3. Theory of knowledge: the concepts explaining knowledge and the limits of what can be known (see also: epistemology);
4. 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]

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and stay in business, and to provide jobs.
2. 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.
3. Cease dependence on inspection to achieve quality. Eliminate the need for massive inspection by building quality into the product in the first place.
4. 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.
5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
6. Institute training on the job.
7. 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.
8. Drive out fear, so that everyone may work effectively for the company. (See Ch. 3 of "Out of the Crisis")
9. 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.
10. 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.
11. a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
    b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
12. 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").
13. Institute a vigorous program of education and self-improvement.
14. 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

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

"A Lesser Category of Obstacles" includes

1. Neglecting long-range planning
2. Relying on technology to solve problems
3. Seeking examples to follow rather than developing solutions
4. Excuses, such as "Our problems are different"
5. Obsolescence in school that management skill can be taught in classes^[24]
6. Reliance on quality control department rather than management, supervisors, managers of purchasing, and production workers
7. 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
8. 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

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

Here is something with Knowing.net on various technologies.




--
Regards
Vijayashankar

What does a Project Manager do?

• 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

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:

1. Tell us about the best product you've ever encountered.  Why do you like it?
2. How do you know a great product manager when you meet one?
3. What's your favorite interview question?
4. When is the best time for a start-up to hire a product manager?
5. What has been the defining moment in your career?
6. 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?

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

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

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

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?

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

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:

1. 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.
2. Measurements are independent of each other.

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

During a stable stage of the process:

1. Determine the process parameter that you want to monitor (such as the process mean, or spread).
2. Create the centerline of the plot, according to the target value of your monitored parameter.
3. 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
4. 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.

1. The monitored parameter is the process mean.
2. The center line in this case will be equal to 100 gm (the target).
3. The points on the plot will be the sample means (where each sample consists of 10 measurements).
4. 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

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