Apr 30

If you work in software development you’ve probably been in or at least heard of a situation like this before: the boss wants some new swanky bit of tech and you’re the developer assigned the job. Not a problem… you love new challenges and this one seems like it’ll be fun. But then you learn that the project is deemed “important” so the BMOC wants to keep detailed tabs on it and assigns a Project Manager (PM) to the team.

Cue the scary music.

The history of project management.

Project management is, as my mother would say, as old as the hills. Shepards, farmers, and the like have all utilized aspects of what we now call project management for thousands of years; perhaps without even knowing it. Keeping track of where to plant, when to shear, and how to get the water from the river to the fields and animals are all tasks that could be found in the milestones of a project plan for running a farm.

Of course managing corn and sheep aren’t the only industries where project management has had a considerable effect; Ray Kroc of McDonald’s created an empire out of ground beef and sesame buns because he understood that efficiency and consistency were the keys to making it big in the burger world. Just watch a crew at your local McDonald’s; the burgers may not look like they do on TV, but if you buy one in Seattle it’ll look and taste just like one in San Francisco. And if you think running a restaurant doesn’t take incredible project management skills and/or processes, just follow a restaurant owner around for a day; or even for a dinner shift.

Project Management as we know it today (example 1, example 2) was founded in the government and by big business within the last hundred years or so. Employers were plagued by ever-present question as they grew larger: how do you control the work and resources for thousands of physically disconnected people (generally by location) while maintaining product integrity and profitability? It is all about making a buck, right? Right?

The pro’s of project management.

Project management is a wonderful tool that enables medium and large-scale efforts from slipping into a morass of ill-conceived “features”, maintain a semblance of fiduciary responsibility (stay on budget), assign responisibility to appropriate departments, and forge a template for similar projects in the future. Most project management methodololgies take a linear approach to the development process, defining specific milestones that will ideally lead to the successful completion of the project. Such milestones are often general in nature, such as:

  • Analysis: Is this really what we want to do?
  • Design: How should we build what we’ve just analyzed?
  • Build: Do the things we spec’ed out in “Design”.
  • Test: Make sure “Design” and “Build” match.
  • Release: Show it off and hope for a good ROI.

With a smart team, a good PM, a detailed and accurate project plan, and enough sign-off from up on high (management), the product should come in on time, on budget, and will accomplish all of the goals and objectives of the project during the milestones given.

The con’s of project management.

Visions of reams of paperwork, long productivity-leeching meetings, and a general derth of anything remotely interesting (or, surprisingly, productive) are all heralded by the moniker of project management. Tech’s who’ve been around the block a few times will understand the importance of specs, but will more often than not feign death before willingly attend and/or comment on any of the fineries that accompany a project (read: meetings). Nothing makes a developer cranky like having to write a technical spec when they can write the actual code instead; and how can you blame them? Their job is to develop code, not essays on what the code will do (though hopefully they’ll comment their code).

Most meetings are generally over-bloated with people who don’t need or want to be there, and the hours spent talking are hours that aren’t used for doing the work that is being talked about. Jeff Bezos, of Amazon.com fame, was smart enough to implement “Two pizza teams” at Amazon, in which a team is too big if 2 pizzas couldn’t feed all members. Meetings should be run the same way.

Using the right tool for the right job.

Ask any carpenter, mechanic, or plumber and they will readily extoll the benefits of using the right tool for the right job… you wouldn’t use a jigsaw to stop a pipe from leaking, would you? The same principle applies to project management. But too often a process for project management will be thrown at a task that isn’t well suited for it and ruins the fun for everyone; and by fun I mean productivity and profitability. Like all humans, PM’s tend to take what they know best and mistakenly apply it wherever it may (or may not) fit. Do you really need a Six Sigma Black Belt or a certified PMP to get a corporate blog off the ground? Doubtful at best. Do you need one to manage the creation of a new production line for an auto manufacturer? I’d be surprised if the answer wasn’t yes.

My view on project management.

I’m sure that proponents of project management and their adherants are probably readying their typing their fingers to flame-on with this post, but please don’t take this as a knock on the fine work that they do. Project management is a great tool when used correctly and can help keep focus on what’s truly important with any project where products and/or services are being created. But it should be done when and where it’s appropriate, and it’s not necessarily appropriate for every single task that comes down the pike.

Small projects don’t need to be tracked within an inch of their life. Proof-of-concepts and models don’t need to be micromanaged. In most cases, a small team of creative and intelligent people should be able to take control of a task and come up with an outstanding product in less time and with less hassle than if it were put through the project management paces. And you did hire creative and intelligent people, right? Let them do the jobs that you hired them to do; the jobs that they want to do (and well).

Look at the history of some pretty swanky companies like Google, Yahoo, SixApart, and Flickr… all of them started with just a few outstanding people, a great idea, and a drive to succeed. Do they have PM’s now? Maybe. But that first core product that was pushed out the door that people grew to rely on… I’ll bet it didn’t.

Smart people can, if given the opportunity, manage themselves and create all sorts of wonderful things. That’s what I believe, at least.

May 05

I’ve been reading a lot of work-related books lately… in fact, just last night I finished reading “Peopleware”. It’s been on my “To Read” list for a while and has been recommended to me by many, many people. After reading it I can see why.

The authors, Tom DeMarco and Timothy Lister, help show how employees aren’t just worker-bees who are to be put into identical beige and/or grey cubicles and who are supposed to do their work an be happy that they are allowed to do be there at all. Employees are people who need to be motivated, inspired, and sometimes let go to be free and creative to help themselves and the company. I highly recommend reading Peopleware, and I am proud to say that much of what they detail and/or recommend, I do already and/or try to do to the best of my abilities.

I’m also blazing through “Designing with Web Standards” by Jeffery Zeldman and “Defensive Design for the Web” by the fine folks at 37Signals. If you know me you’ve probably heard me talk about both authors, so it’s pretty safe to say already that I also recommend both of those books as well.

Jan 11

According to a BBC article a friend sent me there are apparently health risks involved when a boss sends a threatening email to his or her workers. According to the article, “[ Experts from Buckinghamshire Chilterns University College] found that blood pressure shot up if emails were from their superiors - or written in an aggressive tone.”.

For anyone working for than, oh, about 6 months… this shouldn’t come as any great surprise. But what about snail mail, phone calls, pager messages, or even inter-office memos; not to mention the countless other methods of communication at our disposal? I think that any time a superior communicates with a worker in a threatening tone our blood-pressure rises, our anxiety increases, etc. Hell, I’m sure my BP rises if/when I even think that something has gone awry and a superior may catch wind of it and give me hell because of said incident.

That’s part of life in the workforce as a human being; you’re going to screw up every now and again and you’re going to get yelled at for doing so. How the reprimand itself is carried out should be the focal point of reducing stress and/or anxiety in the workplace. Employers, managers, and any “boss” should be aware that what they say and how they say it to an employee carries not only a lot of weight in the workers professional life, but in their personal life as well.