The early bird gets the worm! Common wisdom suggests to get things done as early as possible. Everyday I see people - tuned to this wisdom - rushing on the road, into the elevators, around the vending machines, fretting and fidgeting about the seconds lost. I used to have a manager who was obsessed about every minute in the schedule which ultimately caused huge reworks and led to exhaustion of the team in all sense.

As late as possible is not a new strategy. It is well-known, documented, implemented and practised. However, many of us do not see it as an option because we are not taught to delay work. We all know procrastination is the thief of time!

There are times when delaying is the best course of action. It could be during a negotiation, dealing with uncertainties, or even when booking a flight ticket! This may seem adventurous, but with careful judgement of circumstances, acting as late as possible will be eventually beneficial.

So, next time before you step into a crowded elevator, before booking that off-season flight ticket, before ramping up the team when you think requirements are not clear, consider the strategy - As Late As Possible.

During a recent discussion on risk management, I suddenly realized that we tend to see risks too negatively. We were trying to enumerate risks and it was easy for everyone to come up with negative risks (threats) and not so in exploring positive risks. May be we do not want to call it risks; we prefer the word opportunities - it sounds a lot more positive.

But, isn’t there an inherent threat in every opportunity? Isn’t there an opportunity in every threat? There is, and this is not something new! A little search in the internet gave me some food for thought. Risk management is not just avoid - transfer - mitigate - accept strategies to deal with threats, its also exploit - share - explore - ignore to work on opportunities.

What struck me most is that there are two sides to every risk - positive and negative. In other words, every risk is an opportunity and a threat, however small each may be. Clinching that opportunity wisely is the road to glory!

The two basic questions in any project/task are - are we doing it in time, using the estimated/allocated effort? Most of the important metrics are then derived out of these parameters - time & talent, as I like to call it. Time & talent are curiously unique while being the very basic parameters of any project.

The most intriguing aspect of time is that we cannot save time. We may be able to - in the most simplistic sense - if our project does not have any dependencies on anything in the world, which is not real. The other option to save time is to underestimate - estimate very stringent timelines, which is not a good practice. If we attempt to do a project under normal circumstances, pushing for an early completion of a task creates wastage of time down the line. The best way to save time is by spending it wisely, by creating and sustaining a flow, a rhythm in work.

Talent fulfils the allocated effort in a way that completes the task. In practice, talent is not generic, it is very specific - everyone cannot do every job. That brings out the uniqueness of this parameter - unlike other inanimate parameters. Everything remains the same, the best way to get the most out of a talent pool is to give. Give information get better interpretation/implementation, give training get better productivity. It does not stop there - recognition, empowerment, compensation etc. - there are many variables in this equation. The challenge is to balance the equation - across variables, across the team.

Many a times we try to meet the challenges in managing time and talent using unintelligent, inanimate processes and tools. But managing is both art and science. A little art, a little creativity in these areas will make the manager, the team and the project distinct.

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.

I knew a boy who had the abilities to excel, but did not have the motivation. His teachers advised him and expected him to come first. He did. I know a man on whom his managers put their trust. They expected him to work wonders. And he did.

Often, performance follows sincere expectations.

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.