One of my biggest pet peeves over the years has been that managers in most organizations do not spend their time on the right things. Managers swing between  micro-management and too little engagement. This is true for most mid-level managers in companies but is especially true for project managers.

This happens because the role of the manager is not as well-defined as it should be. When someone is made a manager, they are just told that they now have additional responsibilities. Sometimes this additional responsibility comes with additional authority, but it almost never comes with a “playbook”. Even in organizations where there is a playbook for each role, most management work is part of the “company culture” and most managers play it by the ear.

So what do managers usually spend their time on ?

Collecting data

For some unfathomable reason, it is believed by senior leadership that just because you manage a team, you should be the one collecting data about the team in a hundred different spreadsheets. There is a spreadsheet for number of hours each team-mate worked, there is one for the number of years of experience for each team-mate, there is even one to keep track of vacations ! This does not include the weekly spreadsheets for who forgot to charge their timesheets, whose code has the most number of defects, who worked on DB2 in the past 5 years…etc. And this is just team-mate related data. Project Managers are also expected to keep track of defect density, defect status (put that in a spreadsheet, will you ?), number of lines of code, number of test cases, number of requirements…and so on

Why this is wrong: Collecting data is a task that could be automated…very easily. All it requires is a good organizational database. Once you key in all the data, everything should just flow from there. Each team-mate can periodically update their data in the database and the required reports should be generated at the press of a button.

Preparing Reports

This is probably a sister of “collecting data” above. This could be weekly status reports, steering committee decks, financial reports and so on. Depending on the size of the project/team, there could easily be two/three reports that need to be created every week.

Why this is wrong: Before I say why this is wrong, I will admit that there is some value in the manager participating in the report creation process. It allows the manager to stay in touch with some of the details that could otherwise be missed. The biggest value would be in the manager being able to control the messages being sent out to the recipients of the report. Having said that, there are far better ways to control the message. Most report creation steps could be delegated to team-mates and they could take turns so no one person has to do it every time.

Running meetings

I can understand that the manager needs to chair meetings with clients/senior leadership. What I cannot understand is why the manager needs to chair every team-meeting – including the internal status meetings or an internal meeting to discuss a technical issue in the project.

Why this is wrong: The manager running the show in every meeting is not only a humongous waste of the manager’s time, it also takes away opportunities for other team-mates to contribute. A team meeting requires that every team-mate participate to some extent. When the manager runs the meeting, there is a tendency for the manager to talk more and listen less. This is a waste of everybody’s time.

Technical Details

Most managers in the IT industry can never resist the temptation of getting deeply involved in technical discussions. They will spend hours with their developers trying to understand the problem…and then they will come up with a solution.

Why this is wrong: Any team that is working with a considerable technological complexity needs to have a dedicated tech lead or an architect. It is usually the job of that person to work on technical challenges. That said, the biggest problem here is not even the fact that the wrong person is doing the job — the biggest problem here is that some managers tend to come up with a solution and get attached to that. From there on, it becomes an ego trip.

Governance steps

In large organizations, there is nothing like bureaucracy to kill productivity and drain energy from people. There are a thousand steps, reviews, approvals etc from the time a project begins to the time it is completed. Every step involves creation of detailed documentation which then needs to be approved by 20 different people. As it happens, managers tend to spend the most time on these steps.

Why this is wrong: While over-governance itself is wrong, what is worse is that most managers are unable to delegate some of this work. Governance is probably the only place in a project where the work could be delegated upwards as well. Most managers never take this opportunity.

So, what is the best use of a manager’s time ?

Big picture

Each project and each team has a special purpose … at least that is what is hoped for in a well-aligned organization. It is the manager’s duty to understand what that purpose is and communicate it to his team …   at every possible opportunity. The manager needs to make sure that nothing the team does takes it away from its intended purpose. When the team’s purpose or the project’s purpose in the organization is not clear, it is the manager’s duty to ask why not.

Building relationships

It is the duty of the manager to build relationships with clients and senior leadership, set expectations, keep them in the loop etc. Strong relationships allows the manager to deliver bad news easily. It also allows the manager to negotiate for more money, more resources…anything the team might need to get the job done. Without strong relationships, projects could be hell.

Coaching team-mates

Managers always say during the annual review period that they never had time to talk to their team. Talking to the team is not just about the work the team is doing. Talking to people about their goals and aspirations, allowing them to vent their frustrations periodically, giving pointers on their careers — all this keeps people engaged and focused on their work.

Risk Management

Managers should always be on the lookout for things that might go wrong. While some of this could be delegated, it is imperative that the manager use their judgement in terms of which risk has a bigger probability of occurring and the best way to mitigate it.

Decision making

This is one responsibility managers stay away from and not necessarily because of the lack of time. Most people are scared of taking decisions that might go wrong. Most people hate to put their neck on the line….that is why most people are not cut out to be managers.

Conclusion

Mid-level managers are the muscle of any organization. While they have minimal inputs on what an organization should do (strategy), they are critical to getting it done (tactics). Also, today’s mid-level managers are tomorrow’s senior execs.

Unfortunately, most organizations treat their mid-level managers (and project managers) as glorified clerks. Those managers who fight that culture stand out….so should you.

Imagine this scenario: You are managing a multimillion dollar project for your unit which has just run into a minor crisis. You do not yet know what the impact of the crisis is. You walk into the restroom and you come face-to-face with your unit’s senior-most executive. He nods at you and asks you how your project is doing. What do you tell him: do you tell him every detail about the latest crisis or do you just tell him you are doing fine ?

What if you start telling him about the latest crisis: does he start to get panicky ? Is there a possibility that he will over-react ?

What if you tell him you are doing just fine and then he walks back to his desk only to see a detailed email from your project sponsor with concerns about the latest crisis ? How does that make you look in front of your executive ? Does he start worrying that you are out of touch with your own project ? Worse, does he think you are hiding something from him ?

Communication is as much about the receiver as about the information itself

People tend to think that status reporting on a project means just stating facts on a word document. If that was the case, the whole knowledge area of project communication management would boil down to a status report template and that would be it.

One size does not fit all..

Who your audience is defines how and what you communicate. This is common knowledge. That does not necessarily mean everyone pays heed to it. Most project managers have one status report for all occasions and for all stakeholders. I have even known project managers justify this by calling it the “single source of truth for the project”…whatever that means.

Even for different layers of management, what you communicate depends on what the person is actually looking for. Just because you are reporting status to a senior executive does not always mean that you only give them a 30,000 feet perspective of the project at all times. I have known senior executives who like to understand the technical details of every project in their division…it gives them a sense of being on top of things (or maybe they don’t trust their PMs enough).

So, what does your executive need to know

Back to the original question: what do you tell your executive in the above example ?

As a PM, you need to take the following steps every time there is a significant event in your project:

1. Make sure you understand every detail about the event: how will this impact the schedule, cost, scope ? What more do you need to know about this event so you can better evaluate its impact ? What are the next steps ? Who owns the next steps ? Who needs to give you more information about the event ?
2. Once you understand the details around the event, make sure you have a detailed plan for what needs to happen next. If you do not have enough information right away to decide the impact of the event on the project, at least make sure you know how to get to a point where you can evaluate the impact.
3. Once you understand the next steps, evaluate what support you would need from your boss (or his boss) to minimize the impact ? If you feel the event is going to significantly impact the project, make sure you know some ball-park figures (e.g how much delay, how much more money etc)
4. Next, make sure you are able to write down on a piece of paper exactly what you need from each of your stakeholders. This should include anything you might need your aforementioned executive to help you with.
5. Finally, it is important for you to anticipate what questions might come up. Who does your executive communicate with and what are they likely to ask him about your project ? What meetings does he go to ? What is your executive likely to ask your boss about the project ? What meetings does your boss go to and what does he get asked in those meetings ? Once you know the above, make sure you view every event with that lens.

Remember, updating people about the status of your project is more than just telling them where you are … it is all about giving them enough information for them to be able to answer questions and/or take necessary action (preventive/corrective). If you are not giving them that information, all the status reports in the world won’t mean a thing.

Conclusion…

Re-visiting the scenario at the top of this post: what you tell your executive is: “We are on schedule so far. However, something did come up in the last 30 minutes and we are evaluating the impact. I will send you a detailed update shortly”. Tell him in two lines what help you might need from him and wait for questions.

Reference: Please read this piece for more on communicating with your stakeholders….

In 2002, David Rumsfield inspired a months-long comedy show by giving his now-famous comment about “unknown unknowns”.

Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know…

Secretary Rumsfield was actually referring to the fact that lack of evidence of the Weapons of Mass Destruction (WMD) in Iraq did not necessarily mean that there indeed were no WMD in Iraq….in a very convoluted way.

In the context of risk management, unknown unknowns have come to mean unknown risks/opportunities. Sample this LinkedIn group discussion.

It has become acceptable for project managers to bucket all risks into two categories:

Known unknowns:

…..meaning we know what could possibly go wrong but we are not exactly sure if it actually will go wrong or when it will. These are the sum total of all risks that the project team can come up with. These “unknowns” are documented, monitored and mitigation plans are prepared for them. In short, the project team is prepared for these “unknowns” e.g if you are building a website and your server crashes in the middle of development. Most project managers could easily anticipate this and be prepared for if and when it happens.

Unknown unknowns:

…..meaning we do not know what else can go wrong. Obviously, these “unknowns” are never identified or documented and there can be no mitigation plans. The only mitigation plan here is a prayer. e.g if you are building a website for selling concert tickets and the government passes a law banning all concerts in the country. Almost no project manager could have seen that coming.

So what is known and what is unknown ?

The next logical question is: where is the line between known unknowns and unknown unknowns? Every project team starts with a finite amount of knowledge about the social, political and economic conditions surrounding the project. The team prepares a list of risks based on this knowledge. As the project progresses, the team has an opportunity to learn even more about its environment. This brings up an even greater awareness of what could go wrong. Given an infinite amount of time, the team would know everything about its environment and could anticipate every possible thing that could go wrong. However, no project goes on forever…in fact that is against the definition of a project.

So, is it fair to say that unknowns unknowns are a real thing ?

Could you sue a project manager if the project fails ?

Project managers are not licensed professionals like doctors, lawyers, chartered accountants etc. Though there are several organizations that offer project management training, certifications and standards, you do not need a government license to practice project management.

What this means is that you cannot hold a project manager legally accountable for a failed project. If a bridge collapses, you cannot technically sue the project manager for that construction. You might be able to sue the company that was paid to build the bridge, but not its project manager.

Contrast this with a doctor. If a patient were to die because the doctor made a mistake in the surgery, the doctor could be sued. That is a remarkable difference.

But what does that have to do with unknown unknowns ?

If you were a doctor and you prescribed a medicine to a kid without knowing that the kid was allergic to the medicine, what would happen ? The kid would have serious allergic reactions and all hell would break lose…you might even lose your license to practice if something really bad happened to the kid. Could you, as the doctor, argue that the allergic reaction was an unknown unknown and hence you are not liable ? You might, but I am not sure how well that defense would work.

The point of the above example is that how much effort is expended by the team in identifying the unknowns depends on how much of their neck is on the line. On a $100K project, you would probably spend a couple of hours identifying risks. As a result, the unknown unknowns bucket would be bigger than the known unknowns bucket.

In contrast, on a $100 million project, you would probably have a dedicated risk management team working on identifying risks round the clock. As a result, the unknown unknowns bucket would be much smaller than the known unknowns bucket.

Obviously there is a sweet-spot in every project where spending any more time and effort on risk management will only have marginal benefits.

In conclusion…

However, my personal contention is that project teams spend far less effort on risk management than they should. Every risk that they neglected to identify is conveniently bucketed under “unknown unknowns”. Imagine if project managers could be sued for a failed project — would there be a greater incentive to spend more time and effort on risk management then there is today ?

This is not to advocate that project managers should have to be licensed….there are pros and cons to that. This is simply to say that though there is such a thing as an “unknown unknown”, the unknown part of that is only relative and not absolute.

Among people who report to me, a common complaint I have heard is: “I know you keep talking about demonstrating leadership, but you never appointed me a leader for any team…how do I demonstrate leadership without a designation”.

To be fair, I have spoken the same lament to my bosses in the past. In fact, I used to do that at every opportunity. All that stopped when my boss once told me: “Leadership is not a designation, it is a role. Leadership comes from what you do and not what your designation is.” That was his way of telling me to stop with the excuses already !

Does leadership come from authority ?

But if you look at it more closely, it does make sense. In most hierarchical cultures, leadership is identified with your designation. Indian society, for example, naturally identifies leadership with authority and sets the expectation that knowledge and instructions flow from the boss to the subordinate and rarely the other way round. When you grow up in such a culture, you tend to assume that you are not a leader until you have people reporting into you. In most cultures (organizations even) your worth is measured by how many people report into you.

But leadership is really much different from authority or influence. Most of the top organizations realize this. Leadership is your ability to take a path few would choose. Leadership is your ability to feel comfortable with being accountable for something. Leadership is willingness to put your neck on the line.

Did you say “neck on the line” ?

When someone writes on their resume that they have “leadership skills” (or “proven leadership skills”) more often than not it means that they have mastered the art of telling others what to do. Very rarely does it mean that they have taken risks and set the trend for others to follow. Very rarely does it mean that they have put their neck on the line. Very rarely does it mean that they feel comfortable being accountable for something.

The bottom line…

What my boss was trying to tell me was this: if you want to try a new solution to a recurring problem, if you want to take the path not prescribed by the company, you don’t need to be made the team-lead. All you need is the conviction that you are onto something…you need to take the first step yourself and learn your way through. It is always better to ask forgiveness than to ask for permission. When you try something new and fail, good bosses will never take it out on you. And the bad bosses ? Well you shouldn’t be working for the bad bosses anyway, should you !

The second side of the feedback coin is delivering it to people who report to you or work for you. For most managers, this is only slightly better than having to fire someone. This is especially true if the feedback that you are about to deliver is not very positive.

It behooves the manager to prepare for this very well. It is important for managers to realize that this is a professional conversation they are about to have. You will need to avoid personal over-tones while continuing to show empathy. It is also important to realize that this is just a performance review…not the end of the world.

What Preparation do I need to do ?

Setting goals:

I am hoping that you have taken the time at the start of the year to set expectations with the employee. Most performance appraisal systems ignore this. Setting expectations does not mean entering some random “goals” into the tool. It means that you have a way of sharing S.M.A.R.T goals and setting expectations in terms of how the employee is expected to behave, what their work-timings are, how they are supposed to communicate in the organization, what the company culture is, what their role in the team is etc. Some of these “soft” expectations are subjective and a lot depends on how firmly you lay them down. If you just go in and mumble to the employee about what you expect from them, they may not register with the employee. Clarity is critical when sharing expectations and setting goals. Documenting them goes a long way in accomplishing that clarity.

Review the employee’s work

Go through the employee’s deliverables, their email communications, their key achievements, any mistakes they made etc. Approach other managers/clients for their feedback if they have been working with the employee. Take their feedback without judgement but ask them to explain their feedback in as much detail as possible.  Prepare a list of positives and items you think they could have done better in. Review this list till you can talk about each item with conviction. (Conviction is very important in the actual conversation…). If you disagree with the feedback from others, document why you do not agree. Keep in mind that in some cases it is not prudent to share with the employee the source of the feedback, especially if it is negative.

Make a list of your talking points and get comfortable with it

You need to be able to talk about each item with conviction. You need to have very good explanation for each item.

Setting up the conversation

It is most preferable to have a face-to-face conversation. It allows you to use your non-verbal queues to drive home your talking points. It also allows you to better perceive the employee’s response. The second most preferable option is the phone conversation. While limiting the body language queues, it still allows for you to use your voice effectively. With so many conversations now happening over the phone, most people (especially in the technology profession) have picked up a lot of the phone conversation skills.

The least preferable option is email, instant messaging etc. This is a horrible way to do the performance review and has the possibility of going very bad very quickly. Avoid that at all costs.

The actual conversation

Ice-breakers

This is more than just a formality, it is required to make the employee feel comfortable. It is also polite to ask them how they are doing, how their year was etc.

Should I ask the employee what they are expecting before I even start ?

My personal opinion is No. However, it has worked for some managers. Done well, it gives the manager a segue into their talking points. If not done well, it could become very difficult for you to manage the employee’s just-stated  expectations, especially if the gap there is too big. So, be careful with that.

Start with positives

State what the employee has done well, tell them how it helped the project, the team or the organization. State how you feel the employee has grown professionally in the year. Thank them for their contributions, congratulate them on their achievements. Smile….if possible.

Explain what you think the employee could improve upon

State areas where the employee fell short of expectations. Use numbers if you have access to them (make sure the numbers you quote are accurate, avoid bringing up disputable numbers…you run the risk of spending the next 1 hour disputing just one number). Use specific examples to explain what went wrong.

Attack the behavior, not the person

Be very careful not to imply that the mistakes were a result of the employee being “dumb”, “arrogant”, “careless” etc. This is the part where you need to stay off personal adjectives as much as possible. Explain to the employee why a certain behavior is not accepted in the team. Make very clear that the behavior is the problem and not the employee.

Ask the employee if they agree

When providing feedback on harmful behaviors, ask if the employee agrees that they are depicting these behaviors. Most people fail to see harmful behaviors in themselves and would appreciate someone bringing it to their notice. It is also important that the employees have an input in this part of the conversation since it is something that they may have just realized or are still unsure about. Again, use examples as much as possible.

 Do not pass the buck

When some of your comments come under scrutiny from the employee, there is a very great temptation to bail out and pass the buck higher up by saying something like: “I understand, but it is not in my hands” or “this is what your client told me and I cannot do anything about it”. The worst thing for a manager to say in a feedback session is : “I am just the messenger”. I have known some managers who have said that to me ! Saying such things might bail you out from the conversation, but it will impact your credibility no end. More importantly, it dilutes even the most well-intentioned feedback that you might have shared. If you get into a tough spot, tell the employee that they do not always have to agree with everything you said in the feedback. That is the healthy way to “bail-out”.

Other generic tips

Maintain eye-contact

If you are fortunate enough to be doing this face-to-face, maintain eye-contact at all times. I have known managers who look away when delivering bad news — they will look at the floor, look at the ceiling…anything to avoid eye-contact. This implies lack of conviction and will immensely impact your credibility. Also, a similar tendency is to mumble when delivering bad news. Believe me, it is very painful to sit through such a conversation.

It is not a monologue, ask questions

Always give an opportunity for the employee to ask questions, vent their frustration even. Just make sure to jump in when the employee gets too far out of track or out of line. The conversation goes much better when both you and the employee get out at the end of it feeling they were able to say what they felt. It helps to keep the relationship moving forward.

Don’t judge

Never get judgmental, avoid adjectives. For example, never tell the employee they were “careless”. Tell them that a particular scenario was caused because all the necessary precautions were not taken and tell them how they could have prevented the scenario. Again, it helps to separate the person from the behavior.

Closing the conversation

Ask the employee what support they need from you

Let them know your job is to help them be successful. Let them know your success depends on their success. …and mean it.

Ask the employee for their feedback

Find out if they have any feedback to share about you, about the organization, about the team etc. Never judge the feedback but ask questions on the feedback so you can work on it if appropriate.

Finish on a happy note

If possible, end the discussion with a thanks and a smile. Make sure they know what the next steps are in the appraisal process.

Bottom-line

The conversation is only a tiny part of the performance appraisal process. However, it is the most “human” part of the process. Most managers are not well-prepared for this human part of the process. With managers under pressure to drive their teams harder every year, the appraisal conversations have tended to turn into “judgement days”. They do not have to…

This will continue to remain one of the most challenging skill for any manager to master.

Year-end performance appraisals are hard on everyone — the person giving the feedback and the one receiving it. There are horror stories on both sides … of sweaty palms, of the feeling of disgust and loathing, of self-pity, of the “why me !” and of the “not again !”.

So what can the person receiving the feedback do to lessen the pain ?

First Things First – It is just an appraisal

First, everyone needs to understand that appraisals are just a perception your manager has on your performance. No appraisal, however thorough/objective, is an exact reflection of what you did. There is always a human perception factor built into each appraisal discussion. As with any perception in our human interactions, you can only control how others feel about you and your work to a certain extent. How your manager perceives you and your work depends (atleast to some extent) on his/her viewpoint, on their conditioning, on their style of functioning etc. That part, you cannot control. You can only hope to find a manager who thinks exactly like you do…and that is almost impossible.

So, the most important thing for anyone receiving feedback is to realize that they need to take pride in their own work, on what they have accomplished, on how they have grown. No matter what the feedback, there is almost always something that you have accomplished that you can be proud of…you need to find that thing and treasure it.

The other thing you need to do is to understand that this is just one person giving you feedback about one year on one aspect of your life. There are several others — your friends, family — who appreciate you far more and for far longer than any boss ever can. There is more to life than work and there is more to self-worth than an appraisal.

Good…now what should we do ?

Now that we have those things out of the way, now that you have learned to take the appraisal in your stride, what can you do to positively influence the feedback itself ?

Here are a few things:

1. Find an advocate for yourself who can influence the decision-makers. It could be your manager, it could be your senior colleague or a “godfather” at a senior management level. You need the advocate to say good things about you, to defend you when others are gunning for you and to put their weight behind you. Your advocate needs to be two things:
   • They need to have influence in the organization. There is no point in someone speaking up for you if it doesn’t make any difference (though that is very sweet)
   • They need to have a stake in your success. When the going gets tough, most people will sell their proteges to save their own assets. Unless someone has a stake in your success, their support for you can be very fickle.
2. Record your accomplishments at every opportunity. Use a brag sheet. Save emails as evidence. Talk to your boss and tell them every good thing you have done. Bask in the glory when you have the chance.
3. Align with your boss. There is no use if you work 100 hours/week if you are working at cross-purposes with your boss or your organization. Most organizations reward people who are aligned to the organization goals. Make sure you spend time with your boss to understand their goals and their expectations from you. Never assume anything.
4. Make your boss look good. This is probably the oldest trick in the book. Every time you do something that makes your boss look good in front of their boss/client, they will like you a little better. But be careful to ensure your boss doesn’t forget that you were the reason for them looking good
5. Stay fresh in the mind of your boss. Out of sight, out of mind…never let that happen to you. People who only interact with their boss once/twice a year usually get worse feedback than those who stay engaged with their boss more often. Just be careful to make sure your boss does not notice you everyday for the wrong reasons.
6. Do not let your boss be the only one who knows about your capabilities. It is better to have 2 advocates of your capabilities than just one. You never know who will move out of the company just before the appraisals. Make sure you are noticed by your boss and their colleagues. Make sure your boss’s boss knows about your abilities.
7. Always be professional and courteous to everyone — bosses, subordinates, clients, the janitor…Every good deed will help you.

But remember, this is still just an appraisal…

In the end, do understand that every career has ups and downs. Very few people get straight A’s all their life. There will be times when you think you have done all the above things and still get a negative feedback. That is life…there are no guarantees. The best thing to do is to take it in your stride, pick yourself up and move on.

Never make a big decision right after an appraisal discussion. Never get emotional, stay professional and courteous even if you do not agree with the feedback. It is tough to do that, but that is the price you pay for a long career.

What’s next ?

So, what about the other side ? How do managers prepare for sharing feedback ? How do managers sidestep the pitfalls and the heavy emotional toll of having to give a negative feedback ?

That is another blog post by itself….

1. Figure out all the work items/deliverables that your project is expected to generate (artifacts, manuals, final working code etc)
2. Figure out the estimates for building each of those work-items
3. Figure out the sequence/network for all the deliverables i.e which work-items have dependencies on others, which need to be built first, which need resources that are time-sensitive etc
4. Lay out all the activities required to build each work-item.
5. Lay out all the activities that need to happen to link the work-items together
6. Lay out all the activities in a sequence including dependencies, resource-sensitivities etc
7. Figure out the critical path for the project
8. Write down each assumption you made in steps 1-7 above
9. Get your team together in a room (if your team is more than 50, this may not work. Invite instead the team-leads)
10. Walk the team through each of the work-items and activities.
11. Ensure that each work-item has an owner — even if that owner happens to be you
12. Delegate as much as possible — the PM on small projects is more of a “doer” role. On large projects, a PM is more of a “leader” role and in medium projects, the PM can be all sorts of combinations of the two. You decide
13. Make sure you get your team to agree to the schedule and ownership. There will always be disagreement, but the team needs to have a plan to work around those disagreements before you leave the room — for very large projects, this could take more than one meeting…and that is OK
14. Update the list of assumptions you made in step 8. Start identifying risks.
15. Set the thing in motion
16. Monitor, ask questions, collect data, report status, revise estimates, schedule, assumptions, risks

This is the gist of the planning part…this is more or less what the PMBOK will tell you. Yes, this is not an exhaustive list and yes, every project needs a slightly different approach. But you cannot be too far off this list on any project.

Congratulations, you are a PM !

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.

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.

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.