An Integrated List of Predictors for Project Managers

Given below is a list of Predictors for people who are seriously interested in pursuing Project Management as a career option. I read this in the book “Leadership Skills for Project Managers” by Jeffrey K. Pinto and Jeffrey W. Trailer (eds.). It is a slightly long list, but be assured that it is worth the time.
The first set, "Problem Solving" is a logical result of three predictors, ranging from problem analysis to decision-making. The predictor, "Problem Analysis," deals with a person's ability to handle information; it is the most closely related to her mental and intellectual potential. The predictor, "Judgment and Practical Sense," based largely on the candidate's experience, refers to the actual content of the solutions or decisions proposed. Finally, "Decisiveness" represents the tendency to make decisions or apply solutions, regardless of their quality.
The second set, "Administration" brings together what are usually known as management skills ("Planning and Organization" and "Control"), political aspects ("Strategy and Organizational Know-How"), and technical aspects ("Specialized Knowledge") of management.
The third set contains the main predictors relating to "Supervision and Project Team Management" The first four predictors are concerned with the manager's behavior toward individual team members, and the other two, with management of the team as a whole.
The fourth set is composed of basic general skills in "Interpersonal Relations"
The last set, "Other Personal Qualities" lumps together various other personal characteristics.

Problem Solving
1.Problem Analysis

• Mental and conceptual abilities
• Ability to deal quickly with large quantities of information
• Identify significant problems
• Look beyond symptoms to find the cause
• Gather and analyze data that are essential to make a diagnosis
• Develop all possible solutions and their consequences

2.Judgment and Practical Sense

• Choose wisely among possible solutions
• Make decisions and apply solutions that take into account the constraints of the project and its environment
• Always bear in mind the overall perspective of the project and not just one of its facets; concentrate on the problem as a whole
• Decisiveness
• Propensity to make decisions
• Committed to decisions, even in difficult or delicate situations where the consequences could be personally unpleasant
• Set up a concrete strategy for implementing the decision (action planning, delegating responsibilities, fixing objectives, follow-up mechanisms and assessing results)

Administration
3.Planning and Organization

• Identify objectives and priorities
• Establish work timetables
• Organize resources to achieve the objectives
• Define tasks and work methods

4.Control

• Maintain everyday activities in line with objectives and project deadlines
• Ensure follow-up and make corrections if necessary
• Follow budgets and exercise financial control

5.Strategy and Organizational Know-How

• Take steps to be well informed
• Build formal and informal collaboration networks
• Know who to talk to outside the team or service when necessary
• Know the organization and its operation
• Ability to work in harmony with the organization's political reality
• Ability to implicate others to reach objectives

6.Specialized Knowledge

• Know the information, principles, theories, and techniques that are useful for the various tasks to be done
• This knowledge can be related to management (planning and control tools, accounting, finance, contracts, decision-making tools, behavioral sciences, and so on), the technology to be used, the product or service offered, the market, production, or marketing

Supervision and Project Team Management

7.Delegation of Responsibilities

• Believe fundamentally in others
• Structure clearly the tasks to be carried out, while leaving enough latitude for initiative on the part of team members
• Delegate responsibility to the appropriate level
• Share part of the responsibility with team members
• Allocate authority and resources to team members to enable them to make significant decisions in their fields of responsibility and competence
• Ability to work with subordinates who are clearly identified as experts in their fields without being either too direct or too deferential

8.Team Structuring

• Structure tasks to be carried out and communicate them clearly (see no. 4, Planning and Organization)
• Ability to use power unilaterally
• Use reinforcement to stimulate team members
• Establish control mechanisms that favor task accomplishment according to objectives and correct them if necessary (see no. 5, Control)

9.Consideration toward Team Members

• Behave kindly toward team members
• Identify their needs and ensure their satisfaction
• Fair

10.Development of Team Members

• Frequently assess the performance of each team member and give him feedback
• Identify training needs of team members on the basis of their present and future tasks
  Set up training strategies and ensure they are carried out
• Demonstrate the importance of training by devoting financial and human resources and personal time to it

11.Teamwork, Flexibility, and Cooperation

• Ability to work as part of a group
• Recognize the circumstances that require teamwork or a team decision
• Maintain a climate that encourages the participation and implication of each team member
  Receptive toward other people's points of view
• Prepared to change own opinion and compromise

12.Resolving Conflicts

• Ability to coordinate specialists from different fields
• Recognize a conflicting situation and resolve it efficiently (see A, Problem Solving)
• Know conflict psychology
• Interpersonal Relations

13.Oral Communication

• Communicate efficiently in exchanges with others
• Make efficient verbal presentations
• Concretize communications in respect to the project

14.Interpersonal Influence, Persuasion, and Negotiation

• Aware of the feelings, needs, and expectations of others
• Conscious of the effect of one's behavior on others
• Ability to influence others toward realizing objectives
• Bring interlocutor around to own point of view while maintaining a good relationship

15.Ascendancy

• Liking for command
• Need to dominate others and not be dominated
• Concerned by one's influence on others

Other Personal Qualities
16.Need to Achieve and be Proactive

• Need to excel, to achieve something unique
• Constant desire to do better, to be the best
• Directed toward action and results
• Dynamism, relentlessness, energy
• Optimism, belief in ability to influence events around oneself

17.Self Confidence, Maturity, and Emotional Stability

• Confidence in self and abilities
• Ready to live with personal consequences of difficult decisions (see No. 3, Decisiveness)
• Emotionally stable and strong
• Able to control emotions
• Short- and long-term resistance to stress

18.Loyalty, Honesty, and Integrity

• Endorse the organization's politics and values
• Place the organization's interests before own
• Respect superiors
• Respect engagements
• Professional and personal integrity

19.Tolerance toward Ambiguity and Openness to Change

• Accept uncertainty and unforeseen circumstances that are inevitable during a project
• Desire to work among more supple organizational structures such as matrical structure or its variants
• Propensity to change plans, approaches, strategies, policies, or practices according to the demands of the situation

20.Interest in the Job

• Intrinsic motivation for the work itself and its different activities
• Hopes and career plan that correspond to the opportunities offered
• Interest in the working conditions (place, timetable, salary, and so on)
  

Quality and Grade

I and a few other colleagues were discussing software quality over lunch. One colleague was talking about an application which has features like displaying the equivalent database field in the browser tab, when the cursor is set on a screen field and mentioned that applications are not usually made to that quality. I told him that he is mixing up quality and grade and that is why he has made this statement. If you want to know the difference between these two terms that should not be interchangeably used, please read on. Take a best selling car like Maruti 800. It doesn’t have lot of features and it doesn’t make lots of promises other than high fuel efficiency and low maintenance cost. It doesn’t have a power window or a tachometer. It has only 800 cc of power and the pick-up is not so great when the AC is on. In older Marutis, you had to switch off the AC to get that extra bit of juice, when you overtake. Compare this to a Mercedes Benz. Feature wise, a Mercedes Benz any day will out do a Maruti 800. So why is everyone calling Maruti 800 a very successful* car? To understand this in detail, we have to define Quality and Grade first.

Let us look at PMBOK’s definition.
Quality is the degree to which a set of inherent characteristics fulfill requirements. Stated and Implied needs are the inputs to developing project requirements. A critical element of quality management in the project context is to turn stakeholder needs, wants and expectations into requirements through stakeholder analysis performed during project Scope Management.
Grade is a category assigned to products of services having the same functional use, but different technical characteristics.

Quality and Grade are not the same. Low quality is always a problem; low grade may not be. For example, a software product can be of high quality (no obvious defects, readable manual) and low grade (a limited number of features), or of low quality (many defects, poorly organized user documentation) and high grade (numerous features).

The variants that come in a car are a good example of grade. A Maruti Swift (petrol) comes in three grades. Lxi, Vxi and Zxi. In case of software, Windows Vista comes in 5 different grades, Ultimate, Home Premium, Home basic, Business and Enterprise. Typically higher grade products have more features and cost more to manufacture than lower grades. While it has been easy to get the definition of quality, getting quality requirements right, for a project is not that easy. Let us see why.

Conforming to quality and maintaining the level of Quality is a tricky business. Quality is also in the eye of the buyer or customer—not only the seller. So every application/product tends to have 2 kinds of “Quality Gaps” – the producer (seller) gap and the consumer (buyer) gap.

Producer gap occurs when there is a difference between specification (documented requirements) and what is actually delivered.
Consumer gap occurs because what the customer wanted and what the producer actually delivered are not the same. While whatever mentioned above is universally true, for software, it becomes a little bit more complicated.

• In case of software, the following things tend to happen
• There is a tension between customer quality requirements (efficiency, reliability, etc.) and developer quality requirements (maintainability, reusability, etc.)
• Some quality requirements are difficult to specify in an unambiguous way
• Software specifications are usually incomplete and often inconsistent.

This is the reason why quality management is an integral part of Project Management and an important area of work for a project manager.

The project manager has to arrive at the right level of quality and grade required for a project and ensure that the project output conforms to the same. It is relatively easier to establish grade and conform to it, but managing quality is altogether a different story. In managing quality, the project manager has to manage the consumer gap and producer gap. Consumer gap is the more difficult one to manage since this means knowing what is there in the customer’s mind. Once this gap is covered to a greater extent, working on the producer gap is easier as the target is more tangible.

A Manager has to close the gaps by

• Manage the customer interaction better and set the right expectation to close the consumer gap*.
• Putting in place the right processes that ensure consistency in the delivery to close Producer’s gap

Coming back to the point where we started, why is Maruti 800 a great car? That is because though it has fewer features, it delivers on what it promises to do. So the next time, some one says that a software is of lower quality because it has fewer features, I hope we now know what to say :-)

*Here I am making an implicit assumption that success can't be achieved without quality.
*Closing the consumer gap doesn’t always mean providing to the needs of the customer. It should also be looked upon as setting the right expectation – which in turn leads to a gap that is easier to manage.

The Humble Programmer - The ACM Turing Lecture

The Humble Programmer -- ACM Turing Lecture 1972 - Edsger Dijkstra.

Note:This lecture was given before many of us were even born.

Few points about this lecture given by Dijkstra in 1972.

• This lecture can be considered a classic since many of the points mentioned are still relevant today, 35 years later.
• This lecture started the enquiry into how much computer programming depends on the programmer’s mental abilities.
• Dijkstra has stressed the message that the essential taste of programming is mastering the enormous complexity of computer science.
• Dijkstra argues that programming is the only activity in which humans have to master nine orders of magnitude of difference between the lowest level of detail and the highest. This point is also mentioned in the book “The Mythical Man Month” where brooks talks about the difference between writing a program and creating a software system.
• Dijkstra asks whether it is possible for a programmer to write a system that is bug free.
• Dijkstra says that the only mental tool by means of which a very finite piece of reasoning can cover myriad cases is called “abstraction”; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer.
• This is probably the first paper to discuss the limitations of testing.
• This paper would be interesting reading solely for its historical value as it also conveys a good sense of what it was like to be a programmer in the early days of computer science.
  

I have given a few quotes from the lecture.

“It is generally recognized that the design of any large sophisticated system is going to be very difficult job, and whenever one meets people responsible for such undertakings, one finds them very much concerned about the reliability issue, and rightly so.”

"Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate to show their absence".

“Those who identify the difficulty of the programming task with the struggle against the inadequacies of our current tools, because they might conclude that, once our tools will be much more adequate, programming will no longer be a problem. Programming will remain very difficult, because once we have freed ourselves from the circumstantial cumbersomeness, we will find ourselves free to tackle the problems that are now well beyond our programming capacity. “

In defense of 'Process'...

Most of us don’t like the word ‘Process’. We think that processes come in the way of doing our job (yes, it is true). We think that we can do a better job without processes. But fortunately, we are very far from being right. At an elementary level, processes can be looked upon as the equivalent of traffic rules that we follow, when we drive. Without the rules in place, there will be chaos and traffic jams and we will never get to the destination in time. To extend the traffic analogy further, even when the rules are there, sometimes we find traffic jams or slow moving traffic. This can be taken as an example of a badly defined process and a situation which is in desperate need of process improvement.

The bad name Processes have got is mainly due to the way they (Processes) have been defined, implemented and used. I believe that processes when defined properly help people do the routine chores in a more efficient manner. Over a period of time, Processes also help improve the general minimum standard in an organization. When the minimum standard improves, the process becomes a type of intellectual capital called structural capital .

The purpose of this short article is to define the term ‘Process’, elaborate on the term, introduce a few concepts and help fuel a debate (if possible) on the concepts discussed.A Process can simply be defined as ‘A set of activities that help to deliver a predictable result’. The sequence of the activities need not always be linear. Attributes like Purpose, Structure and Rationale characterize a Process. The definitions are as given below.

• Purpose: What is to be achieved and why, aka ‘the Goal’ of the Process
• Structure: How the goal will be achieved
• Rationale: The reasoning behind the Structure

Process Definition and Implementation:

• Processes need to be understood and defined. This means that a person or a group defining the process has to think through and understand the Purpose, Structure and Rationale of the Process.
• Smart Processes are those Processes that actually help a person do an activity better than how he or she would do in the absence of the Process.
• People who define and implement Processes should also remember that Processes are valued only when they are simple to use, i.e. the structure is easy to understand.
• Implementing a process can be defined as the way to achieve the Goal of the Process. ·
• A good understanding of the Goal will help realize a structure that will deliver maximum benefit out of the implementation.
• Generally we use Information Technology to implement a Process.

Process Improvement and Re-definition:

• While using a Process, the Rationale behind the process has to be understood by the end user, to derive the maximum benefit.
• This may or may not be applicable for one time usages; this definitely applies for the Processes that we use daily. For e.g. at work, we use Processes that tell us, how to manage projects or how to do code-review or how to track customer payments.
• If we understand the Rationale, we will also realize that there is nothing like a good Process for ever and that every Process has got an ‘Expiry date’.
• Also, the environment in which a Process is used changes and evolves over a period of time. When this happens or people start feeling that a process has become an over head, it is time to re-look at the Process.
• This brings us to the idea of Process Improvement and Re-definition. Using the attributes of a process defined at the start of the article, we can say that Process Improvement happens when the Structure and Rationale change, while the Goal remains a constant. A Process Re-definition happens when the Goal itself has changed and we have to start allover again.

Resistance to Change:

• When people try to bring in a new way of working, they are always met with Resistance to Change. ·
• Statements like ‘We have always done it in the present way and we don’t need a new way to do’ or ‘it doesn’t work like that’ are all symptoms of Resistance to Change. This also happens when people are not aware of the bigger picture and for them, the change may look un-necessary.
• Educating people about the necessity for change does work, but difficult times need a ‘this is how it has to happen’ attitude to bring in new processes into practice.