As today’s professional world is adopting a knowledge-intensive culture, it is tough to find a right combination that covers the depth and the breadth of a specific area of knowledge. Conventionally, we relied on deep, explicit, documented knowledge as in the case of research and development projects. But in recent times knowledge acquisition has become broader because of mainly two reasons.

Firstly, technology has helped distributing information wide and far and power of knowledge has become evident in activities beyond research and development. People then needed to acquire knowledge from more than one domain and were restricted in the depth while expanding their breadth of knowledge. Secondly, people who followed the rapid advancements in technology made shallow impressions everywhere while spreading over larger area.

We have two sets of people now: the specialists and the generalists. Generalists existed even before the above-mentioned reasons forced many and that was because of personal traits – some people find it easier to deal with multiple subjects while others like to dig deeper in one subject. I find J Scott Armstrong’s description of specialists and generalists very striking. According to him a specialist is the one who knows more and more about less and less until eventually he knows everything about nothing! A generalist is the one who knows less and less about more and more until eventually he knows nothing about everything!

Today’s world needs both specialists and generalists, and the challenge is to find the right balance between the two. Certainly a team of generalists is not going to be of much help. A team of specialists may lack creativity or may miss out the inter-relationships between multiple parts.

There are various hypotheses and propositions on structuring a team with specialists and generalists. But I like to draw an analogy from sports in this matter. In all the team-sports, there are some people who are all-rounders or playmakers; though they are not many. A generalist holds this position in a project team. This is especially true when the environment/scope is not too small. Obviously in a very small team/project, specialists always dominate.

Howard Artrip – a manager in Toyota – knows what he does. He knows when he gets up, how long he takes to get ready and get to work. He smiles when he says “I’ve maximized my sleep time”. Toyota’s philosophy of continuous improvement is his personal statement.

Sometime back, I was talking to an engineer from a highly capable and mature company about what he thinks about quality. At the end of a very colorful description about the practices and processes, he confessed that it is difficult to follow them all. It was a burden on him, and in his opinion an overhead to the system.

It is a fashion to adapt and implement the processes and techniques that are proven in some organizations. In a frenzy to implement and report the return-on-investments, most managers fail to get the spirit – and most importantly the thinking – behind these processes. One of the common mistakes is that we try to replicate the processes without understanding the context and culture in which these were set and became successful.

Value addition is the promise of most processes and techniques. At the end of the day we search for added value in the process, in the end-product, in the pile of documentation, reports, and presenations. What I find often is that we miss out in searching for the added value in our people. It may be that we think they are just techies or skilled workers, we think they appreciate the processes themselves, we think the processes have nothing to do with people and vice versa!

People need to understand the reason behind every activity, the benefits and a bit of history to enjoy their work. It is important to infuse the spirit behind the process into people, so that value is first added to them – and they realize it. They will in turn add value to products and even back to those processes.

It is a very old saying of Aristotle – well begun is half done. We find this true in many fields, especially when it comes to accomplish a certain goal – whether it is in studies, sports or projects.

We have developed and mastered many techniques and processes to execute a project. But we deal with project initiation with a bit of laxity. In the height of dramatic events involved in realizing a project, we sometimes fail to see the fine cracks that are being developed – in terms of missing out details, under-estimating functionalities, setting aggressive timelines etc. It then becomes a fight for the team to hold the project from falling apart during its course to completion.

It is good to estimate, and it is better to re-estimate. There are many techniques which are developed to encourage multiple estimates – quick/detailed estimates, optimistic/pessimistic estimates, low-confidence/high-confidence estimates and so on. It is also important to work out estimation parameters from the final estimate that is used to win the project. One aspect which is overlooked frequently in estimation is dependency. The project dependencies normally drive the schedules and idle-times and it is crucial to understand it early on. A good work-breakdown-structure can solve this easily.

It is also good to create a visual representation of the project and its environment, something like a map. Words can be hazy; numbers can become tough to follow; visual representations are easy to comprehend and remember. It is good to note that all military operations start with a study the area to be conquered, usually represented by a map. It is good if the project map includes not only the deliverables, but also other details such as schedule, size, assignment, risk etc.

Training and team-building are some aspects that are taken lightly. It is important for the team to understand the terrain – environment, existing systems, work-flow, domain knowledge, business rules, tools, techniques, limitations of technology – before starting a project. Building a knowledge-base is a best-practice in most of the execution frameworks. The earlier and faster we build it, the easier will be the project execution.

If we take Aristotle’s words literally, it is fine to devote half the project duration just to initiate. If you are worried about a possible time-crunch, return to some past projects and see the productivity during the last few weeks.

Various books about software engineering usually compares software development to manufacturing. The comparisons often highlight the differences so as to establish a separate set of processes and methodologies for software development. While it is true to a larger extent in the current scenario, the future of software development may blur the line between manufacturing goods and manufacturing software. What makes software unique could be the replicable nature of end products.

The common conception (or misconception) on the difference between software development and manufacturing is that software development is more intellectual than manufacturing. This was true in the nascent and adolescent stages of software industry. In the current mature scenario, industry recognizes right aptitude and training as the most important qualifiers for software workforce – as it is in manufacturing.

Mature tools and processes enable software to be created and managed with less sophistication from the developers. In my opinion, this brings out the most striking similarity between software development and manufacturing. Manufactured goods are often differentiated by the company or location. There is also a certain brand value generated from the quality and process of manufacturing (take the classic example – Toyota). As the software industry is also growing into a similar mould, the tools and processes will be key differentiators in coming days. A mature software company is more likely to produce quality work-products than others, consistently.

The grey areas in the above statement cannot be overlooked. While the weightings of the words likely and consistently are important in decision making the key challenge will be in assessing the maturity of a company. Certainly software has been following manufacturing in establishing maturity levels (refer Quality Management Maturity Grid). As the awareness builds, customers will be more equipped to discern maturity and there is more to learn then.

Quality is one of the evergreen topics for discussion in business world. I attended yet another session on quality a few days back and that made me think a bit deeper – more on concept and perceptions. Our instructor described quality as conformance to requirements and fitness for use, the common definitions from Philip Crosby and Joseph Juran. Next, our instructor mentioned that the need for quality is to survive in competition and to get repeat business – with heavy overtones from sales and marketing.

Many talk about product and process qualities further complicating the matter. They point out the competing objectives in product and process qualities (e.g. beyond a point an increase in efficiency of product decreases efficiency of process). It is much easier consider quality of product alone, and create a scope based on limitations in the process – such as budget, schedule, resources or techniques. The concept cost of quality is more useful than dealing with multiple perspectives of quality. I also prefer the word maturity over quality when talking about processes.

In my opinion, the word qualification suits better to the descriptions of quality mentioned above. It’s high time we should differentiate quality and ‘quality management/control/assurance’. The latter is more associated with qualification – ensuring that the product/process is qualified according to the requirements.

The dictionary defines quality as An essential and distinguishing attribute of something or someone, A degree or grade of excellence or worth, A characteristic property that defines the apparent individual nature of something or Of superior grade. A few synonyms for quality are caliber, character and select. These phrases and words give a more accurate definition – devoid of sales and marketing pressures – making us understand that quality is more of a character of products and processes than a set of methodologies and tools. ISO defines quality as degree to which a set of inherent characteristic fulfills requirements.

In my opinion, achieving quality thus becomes part of work-culture. Methods and tools are important because it is difficult and time-consuming to permeate the concepts and organizational philosophies into individuals. However, those are just some means to and end, and the importance of quality as part of organization’s culture should not be overlooked. The success of Toyota is not their methods or lean tools, but the quality that is instilled into organization’s culture.

Thus I would say, “make quality as the character of your organization or product and qualify your services (and products) to suit customer’s requirements”.

Currently I am reading a book named Long-Range Forecasting – From Crystal Ball To Computer (LRF). The author – J Scott Armstrong – begins by introducing a simple idea which he calls systems approach as the first lesson to be learned in forecasting. The approach is an elementary technique for analysis and planning. Many such important techniques in management have been known for decades or even centuries. We keep reinventing, repackaging and reselling!!!

The systems approach helps in developing, evaluating & implementing projects (programs) with a holistic perspective. Quoting from LRF:

“The systems approach uses two basic ideas. First, one should examine objective before considering ways of solving a problem; and second, one should begin by describing the system in general terms before proceeding to the specific.”

It helps to break down a problem into four generic steps: 1. Identify objectives, 2. Develop indicators of success, 3. Generate alternative strategies, and 4. Develop and select programs.

It is often found that the projects are executed without finalizing or understanding the objectives, postponing the definition of validation mechanisms and not considering the alternative strategies and designs. I have seen this happening among managers while estimation and planning, designers while creating systems architectures, and software developers while coding the foundation modules (I was also a partaker). I have worked in a couple of projects that did not have any purpose but to exhaust the budget or justify some previous mistakes/investment.

These real experiences helped me to appreciate the basic steps illustrated by Armstrong in a very simple, but striking manner. Here’s an analogy for easy recollection.

• Rainmaker Theory Number One: “The rainmaker gets so involved with the dance that he sometimes forgets that he has to make rain.”
• Rainmaker Theory Number Two: “Yes, I know it didn’t rain – but didn’t you like the dance?” In other words, the successful rainmaker is the one who can convince his client that he really didn’t want rain – he wanted to watch the dance.
• Rainmaker Theory Number Three: “Who cares why it rains?” The science of rainmaking evolves into the science of rainmaking dances.

One of the confounding terms in the business world is value. Outside the business world the term poses difficult questions to philosophers, economists, religious thinkers in the sense it matters to them. One of the main challenges is to define whether the value of an object/service is absolute or relative. For example, neoclassical economists perceive value as relative while classical folks try to measure it as innate worth, and an objectivist acknowledges the worth, but play it down with reason.

In a world, where value seems to be driven by perceptions of individuals, it is difficult to assess the true value of anything – that too, only if a true value exists for one! And, we often come to the table negotiating our perceptions of value. We have created processes, methodologies and systems to minimize the negotiations; especially to save the carps from negotiation sharks. But these systems are not foolproof, and loopholes are easily exploited.

In most of our day-to-day transactions value of a substance/service is often understood by its objective and subjective elements. It helps if we separate objective and subjective elements and their contributions to the assessed value, with the context of subjectivity well understood. There could be some delicate inter-dependencies between these elements, which may need to be dealt with care and tact.

When the systems fail, processes become inadequate, value tilts out of balance. At that point negotiation starts and fairness of the deal depends a lot on the parties involved. A good and principled negotiation helps in establishing value in a realistic manner. It is also good to remember that there is value in building relationships as well, through healthy negotiations.

What prompts a person to learn? I have been trying to find an answer, especially in the context of work. For many, once out of educational system, learning becomes almost a matter of choice. The highest hurdle in making this choice is the refusal to accept ignorance. We have built a culture around us where ignorance is considered a shame.

Look around! Many of us are trying to convince ourselves that we know, especially in the areas of our specialty or work. Seldom we realize that those confidence-boosters become obstacles in our learning process. The first step in learning is to learn of our ignorance, and to accept it. That’s when we beat the hurdle and choose to learn.

I wonder whether Sir Isaac Newton realized it when he remarked, “I do not know what I may appear to the world, but to myself I seem to have been only like a boy playing on the sea-shore, and diverting myself in now and then finding a smoother pebble or a prettier shell than ordinary, whilst the great ocean of truth lay all undiscovered before me”!

A few years back, when the book Who Moved My Cheese? was in the list of top-sellers, everyone talked about change frequently and daringly. Change is inevitable in the universe and life, that we all must be prepared to deal with. But all changes need not bring desirable results. Success of a change depends on the current situation, our knowledge on it, and the acceptation of it’s results.

Along with change comes the restraint to change – which is good. In life, the restraint to change is often a mental block, or a fear that the change may not work, or some emotional ties. While many ask us to suppress these restraints, I would say, these can be used wisely to evaluate the situation objectively, to analyze the new or changed situation.

Another aspect of change is the courage to change. First it requires courage to accept the situation, conquer the fear and destroy the barriers. Then it requires courage to accept the change and live with it. I guess this is where all the inspirational books and speakers concentrate – threatening us to make the move, preparing us to face the unknown. Just remember only this – courage is different from daring!

Everything flows, nothing stands still. Change is inevitable. If you know your restraints well, if you have the courage to accept the change, you can always remain “Say Cheese”.

Since I joined the Orkut community, I have been noticing a lot of hits coming to this site from Orkut. I couldn’t help, but thinking and searching about Orkut.

Orkut is a social networking site designed by Orkut Büyükkökten – a turkish software engineer – as a personal project in Google. It has grown into a phenomenon with the help of netizens, dedicating their time and “relationships”. But I was particularly intrigued by one of the most important aspect of any social network. Privacy!

Reading through the fine-print, I understand the privacy of our personal information (date of birth, address, phone etc.) is safe with Google (unless we choose to publish it – then there is no question of ‘privacy’). After going through many articles, and spending some time in Orkut, my opinion is that privacy in Orkut depends on one of the basic elements of social networks – trust.

There is a new feature in Orkut – mutual friends – which is something worth looking at. It creates inexplicit communities. You can traverse through this ‘mutual friends’ to get a complete picture of the community you are interested in. I am reminded of the efforts we spent in ‘customer grouping’, ‘householding’ activities in many Customer Relations Management (CRM) projects. Again, this feature works only in our friend circles, and that’s good.

For these reasons, whenever I logon to Orkut, I imagine the O as a circle, a circle of trust, and that it comes first.