Are managers spending their time wisely ?

What are managers focusing on ?

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.

Read the rest of this entry »

Advertisements

The elevator pitch equivalent of project communication

What does the executive need to know about your project

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 ?

Read the rest of this entry »

Is there really such a thing as an “unknown unknown”

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? Read the rest of this entry »

Basics of project estimations and scheduling

The way I was taught software estimations was that you do the following in sequence:

  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 !

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 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.