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.