Top-heavy organizations lead to more discontent

I was stating on my twitter handle today that the biggest problem with the Indian governments over the years has been that they have been too top-heavy. Bottom-line: too many decisions are made by the top leadership and the middle to low-level managers are left with the cleaning up acts.

Specific to the current Congress-lead government, decision-making authority has been divorced from any accountability. Which is why we have a 40-year old “youth leader” (a.k.a “the Prince”) running around making irresponsible and nonsensical statements. However, this is not a political blog.

The reason why the governments have been top-heavy (and this has been true for non-Congress governments also) is that very few of the political parties have any meaningful form of internal democracy. Most of the top party leadership positions are shared by kith and kin of people who are already at the top — again, true for most parties and not just the Congress.

A closer look reveals that Indian society is itself top-heavy…Indian families are top-heavy. So, it is more or less a cultural thing. I do not have a solution written down for this, yet.

What happens in top-heavy organizations is that there are two groups of people — those with authority who sit at the top and direct and those who form the “worker-ants”. Further, the two groups are not formed based on merit, rather on who you happen to know or who gave birth to you. True, there are exceptions to this rule, but great organizations cannot be built on exceptions. This eventually leads to frustration among those in the second group…especially when those in the second group are more capable than those in the first. When you are a smart person with great ideas but are repeatedly being shot down by a boss who is not as smart and there is no way for you to work around that boss, you will get frustrated.

Indian organizations – families, societies, communities, governments, political parties — all of them, need to get out of this mode. Top heavy doesn’t work. It tends to concentrate power and authority in a small group and that is what is called “lack of empowerment”.

If the person on the street feels “lack of empowerment” at every step, democracy has failed.

For companies, the lesson from this is that if you do not make each of your employees feel empowered, you will not see great ideas and initiatives come through. No matter how smart your CEO is, he/she is not going to come up with all the brilliant ideas on their own.

 

 

What is wrong with large organizations ?

Scott Berkun has a new book out (The Year Without Pants: WordPress.com and the Future of Work) in which he talks about his experiments working for WordPress.com.

One of the ideas he explores in the book is how small, smart, focused organizations are changing the way work is done in the “new world”. He describes the cynicism of “experts” who are quick to point out that while such-and-such is a great idea, it would hardly be scalable. Somehow that is supposed to mean that the idea is not practical.

Scott asks :

What good is something that scales well if it sucks? Why is size the ultimate goal or even a goal at all ?

As an employee at a large company, when you propose an idea, the first question that is asked is: can this work at the organization level ? Sure, this is a great idea for this specific group, but will it work across all departments ?

Now, most ideas do not work everywhere. Not all departments are the same, not all groups have the same problems/goals. Ideas come with context to the specific problem/goal that the specific group is trying to address. So, why are new ideas passed through this lens when they are proposed ? Why are ideas expected to work on a large scale as well as a small scale ?

I believe that this is where large organizations (and that includes most governments) fail to innovate. Large companies that do innovate are mostly those that work on small scales. ..those that have hundreds of small, focused groups instead of being one huge monolith.

Software development, especially is meant to work on micro scales. You build small programs that address specific problems and then try to integrate the smaller pieces into one big piece. Object oriented programming took us in that direction decades ago. That is how organizations should work as well. They should be made up of small groups (of 5-10 people) that address specific problems and do that well. It is, then, the task of the senior leadership to integrate these small groups.

We are quickly moving into an age when organizations need to build themselves around small groups (or even around individuals). There was a time when individuals molded themselves (and their style of working) around the organizations that they belonged to. That time is long gone.

How estimates work … or do not work (Part 1)

Some of the biggest project failures (mostly on IT projects) come from our continued inability as a species to predict the future.

That statement does not sound right. Surely, that is over-generalization. So, let us start over.

Estimates of any task assume that once the work begins, there are no further decisions to be made. That it is just a matter of putting your head down and completing the task without distractions and without having to make messy decisions.

It does not work that way. Even the simplest of tasks has a million decision points. Your first beverage of the day: tea/coffee ? Do you make your coffee at home or get it at Starbucks (remember that quote from You’ve Got Mail ?) ?

We get over these decision points by creating routines in our life. Which means that you anticipate the decision points in advance and make them ahead of time. So, you don’t spend time making the decision every day, every minute of your life.

Unfortunately, routines do not work on most projects. If they did, we would not call them projects…we would call them “operations”. That means that most projects have a million decision points as well.

Decision-making is a personal thing – meaning that each individual has his/her own way of making a decision. It takes all sorts of people to make a project team. You cannot fill your team with project managers with excellent decision-making skills … you will need to leave room in your project for the nerd who cannot decide between a drop-down/list-box. There is no estimation model that can account for the time/effort involved in the decision making by all types of individuals.

All the above is not to say that projects over-shoot budgets and schedules simply because of indecisive people on the project teams. What it means, though, is that Project Managers would do well to anticipate those decision points in advance…well, atleast as many as they can.

The problem with Maslow’s model…and everything else !

This video trigerred off a thought process on Maslow’s heirarchy of needs.

Maslow’s model is one of the most elegant models I have come across in HR management. Unfortunately, it takes a lot of experience with actual people to grasp the point that this is just a model that only partly describes the utterly chaotic way people behave in a “live” organization.

Organizations are like living breathing animals made of tiny micro-organisms that are each fighting for their own survival. (It has been subtly argued that the human body itself is a microcosm made of billions of “living” genes that are each fighting to survive into the next generation…but that is a topic for a seperate post). To claim to have a model that can accurately predict how an organization will work (or not work) is a stretch …unfortunately that is exactly what most organizational behaviour theories do.

To get off my soap-box, I will have to admit that Maslow’s model does provide some direction on how people might be expected to behave under specific circumstances. This is the assumption (and prayer) on which most organizations design their reward/punishment set ups.

Maslow states that individuals have hierarchical needs that follow an order. For example, the first thing any individual needs is air to breathe, food to eat and water to drink. Only once these needs are met do individuals look for other needs. There is also a “diminishing returns” flavor here in the sense that once a person’s non-esteem needs are met (meaning he has enough money) simply adding more money will not increase the motivation. And so forth…you get the general idea.

However, this is obviously over simplified. How much money is enough ? When does a person’s self-actualization need kick in ? Do all individuals have this need ? Arent there individuals whose sole mission in life is to make money ? Aren’t there individuals whose mission in life depends on making a whole lot of money ? This is where the model loses its smooth curves and acquires rough edges.

The bottom line is not to trash this model specifically. The point is that too much of HR management in companies is based purely on these models. A more popular crib is against the “bell curve” where organizations rate their employees on the bell curve without considering the fact that each employee is different (moreover treating employees like just another statistic is a little “yuck”!)…it is a pathetic and lazy practice and should be discontinued.

Too many managers get ahead in life just by mouthing these theories and models. The true leader is the one who understands his own ecosystem and is also brave enough to admit that he does not understand well enough to generalize…I am waiting for that kind of leader !

The new breed of Project Managers

Project management is about ownership more than anything else. This is something that I have heard oft-repeated in PM circles. Yet, I find that more and more project managers these days are trying to run around ownership.

As project management drifts away from old-fashioned leadership and becomes a specific niche skill, ownership seems to have taken a back-seat as the prime requirement for this role. Many project managers today play roles that demand co-ordination more than actual leadership. With more and more ambitious projects being undertaken every day, individual project managers are being gradually replaced (or atleast supported) by PMOs, PMAs etc. There is a new, younger, more efficient Project Management Administrator sitting where a PM should have been and doing (at least a part of) what a PM should be doing. The average experience of the members of the PMO is also coming down.
What this new breed of “assistant managers” — for lack of a better designation — is doing is focussing on co-ordination and the PM tool-set. This breed is more rigorous in areas such as financial accounting, scheduling, risk management etc and less bothered about old-fashioned concepts such as leadership, ownership, and people management. More and more companies are looking to fill their actual PM roles with this breed.

So, why is this a bad trend ? I have always felt that a PM needed to have a rigorous grounding in such arcane and painful fields as accounting and scheduling. But lets face it: which individual has the time to do this when he has hundreds of people to answer every day and even more people problems to solve ? It would need a super human to juggle the administrative and people parts of a project (and we are not even referring to those large billion-dollar projects that more and more governments have launched in what we will call the recession years). Sadly, we do not have an abundance of such super humans. So, in a way, the creation of the new breed I mentioned above complements the “leader of the project” PM.
What is concerning, however, is that many of this new breed are not being groomed to become actual leaders when their turn comes. How will this transition happen ? The attitude of most in this new breed is: “I will do my job and tell others how to do theirs. If they can’t do their jobs, it is the PM’s headache, not mine”. While that is an oversimplification, I believe that speaks of the general trend.

So, is there a way to stop this trend ? Is there a way to manage this transition from an administrator to a leader ?
I believe that it is upto the individual to figure out how to make the transition. Like in all other fields, all project managers cannot be leaders. Some part of a leader is always a natural gift while the rest comes from graft. It is for the individual to decide whether the graft is worth the gift they carry with them.
But, I also think delegation is a tool that the PM should use to see if his committee of PMOs and PMAs has it in them.

Old Link…

Linking to my PMP Certification lessons learnt piece on PMHub.net

Sridharvanka:Passed 1st try 10th Dec – scored “Proficient” in all the 6 areas

Using milestones to track projects

For years now, I have been attending project status meetings where people go round the room asking each other variations on one question: “What percent complete is your work ?”

“Percent complete” has negative connotations in Scrum as also in the PMBOK. Managers who use percent complete are viewed as ignorant at worst and old school at best. Why is that ?

One argument given against using percent complete as a measure of project progress is that it is arbitrary. It almost never comes from hard numbers and is usually given by someone who has been put on the spot during the dreaded team meeting.

Irrespective of how many project management books deride the usage of percent complete, I see a natural tendency among managers to go for it in every team meeting. This is probably because it spares the manager (and his PMO) the trouble of digging up numbers.

One interesting compromise I have seen in this aspect is the usage of milestones. The idea is simple: instead of depending out-and-out on a developer’s idea of percent complete, the managers suggest that we have milestones for 25%, 50% etc complete and mark these “finish” based on a detailed review.

Here’s an example:

A tester has been asked to prepare a Test Case Document (TCD). He provides an estimate of 100 hours for completing this document. The project manager creates an activity called Create Test Case Document (CTCD) against which the tester logs his hours worked. In addition, the manager creates milestones (milestone activities in some project management tools) which stand for 25%, 50% etc completion of the TCD. Based on the weekly status reviews, the tester and the manager together decide if they should mark the document 25% complete or 50% complete etc. The project status report then draws directly from these milestones to specify (mostly to senior management) how much of the TCD is complete.

This technique has the curious effect of making it appear as if the status was based on hard numbers instead of just a subjective discussion between the tester and the project manager. Given that, I believe that this brings in some objectivity to the project. More importantly, it forces the project manager to take a closer look into the activities because he is responsible for marking a milestone complete or otherwise.

As means of variation, the number of milestones against each activity could be increased or decreased depending on the granularity and accuracy desired in the status reports.

Let me know if this makes sense or if you have used similar techniques in your projects.