Fast Forward MBA in Project Management in just 24 hours

Why do people study MBAs?

I mean really, do you need a master in how to administer a business? I mean, if you sell hamburgers, do you really need a guy who knows Economics, Finance, labor laws, etc.

In my dictionary, selling hamburgers is pretty simple, but you still need an MBA to figure out how to beat the local competition, so MBAs will thrive.

Do you need an MBA in project management?

I hope we can both agree that project management, specially in the high tech sector, is pretty confusing, compared to flippling burgers, of course.

Read a resume or the average job posting on monster.com and you will see SOA, ESB, XML, XSLT, CSS, HTML, JSP, Java, JavaScript, J2EE, Entity Beans, Session Beans, HTTP, JNDI, Servlets, Struts, Ajax, DWR, Hibernate, Spring, Axis, the list just goes on and on.

Most people just put acronyms on their resumes, without even understanding why is that needed. The same goes to the recruiting specialists. Even people making choices are not aware of why do they need that.

It is just something mentioned by the vendor XXX. Vendors do have an agenda when recommending technologies: Separate customers from their money. And there is no better way to do that than to recommend some solution they don't have for a perceived problem. The solution presented by the vendor must be bought and must be "integrated", which means hire a developer who seems to know the technology (or so his resume said) and slap him in the face with the product until he delivers a solution. Have you ever wondered why your boss says 3 weeks and you look at him in disbelief?

A vendor recommended that. Vendors are in a position that attracts many customers. Even a 100 per day, asking for recommendations. What can they do about them but schedule a meeting and letting them know they have solution for their troubles?

Have you ever wondered why vendors buy other companies? Because they are being asked for solutions they do not have, they know how much people would pay for it, so they know exactly how much they will make if they buy them. Therefore starting a company and buying bought by BEA, IBM or Oracle is a sure way to get rich quick. But not without a brain and with a lot of effort.

So in the end there will be lots of project managers with MBA certifications trying to integrate solutions of vendors that cost a fortune. Vendors only sell what is in the market already, for example now BEA sells a lot, but at the beginning all companies start small.

And that takes me to the most important recipe on project management: Start small.

Few people, few requirements, short iteration. Do prototypes. Integrate them. Succeeded? If the answer is yes, grow a little bit. If not, shrink the prototypes until they are manageable.

See?

Manageable. That is the whole point of project management.

The results are what is important. I mean, If I say jump of a building you wouldn't jump because you can imagine the results. My point now is, what is the result of reducing the size of the experiments?

Successful experiments!

Think about this. If you reduce the size of the experiments eventually the experiments are about putting an extra comma in your code. Hardly difficult, therefore you must succeed at putting the comma.

And now you imagine your whole project is late because you are handling the irrelevant stuff. Not so. Once you get your commas right, you can take more difficult endeavors. Knowledge has an interesting property: The more you know, the easier it is to get more.

Therefore you begin to increase the size of your experiments and you begin to tackle more difficult problems every time. Until you succeed.

It is amazing because it is exponential. One day you have half of your project ready and the next day you have your whole project ready.

What is the idea behind this?

The idea is simple: industrialization. Industrialization is just division of labor. And division of labor means that a single product goes through the hands of as many people as possible, each of them doing a particular task to the item.

Fast forward to the 1980's and every worker is able to stop the production line if he finds a defect. The defect is traced back to its source in order to reduce waste. This idea was a courtesy of Toyota.

People do not have long list of to-do items, but instead have a long list of "done" items. When ever a worker has depleted his list of to-do items, he grabs an small list of "done" items from another worker (remember this is a production line) and he continues to work. This method is called Lean Production or Lean Manufacturing and is blamed for being more productive than the traditional factories.

XP, Scrum and all the agilists base their ideas on lean manufacturing. The reasoning being that if the Japanese could improve their manufacturing by applying these ideas, the same could be done to the software sector.

The main problem is that workers outside of Japan will goof off. I mean, in Japan you can't work more than your coworkers, nor can you work less, everyone has to work the same, because in their culture you can't succeed if anyone doesn't succeed. In the rest of the world it seems to be the opposite, so if someone goofs off, everyone goofs off. Therefore management has to give incentives to the ones that do their work and punish the ones that are slacking.

But how can you successfully manage people if the tasks are so small? I mean you would spend a whole day supervising 2 or 3 developers and the rest would effectively be slacking.

So instead of going over everyone everyday, compare the amount of work done every month. For example, count the number of lines checked-in, but remove the number of lines copied and pasted. Count the number of issues resolved, but reduce the number of bugs introduced by him.

At the end of the month you will have a clear picture of what is going on and how each person is doing.