Management Styles in Web Development

How operations management affects project management in a web development environment

“Fostering an atmosphere that doesn't allow for error simply makes people defensive. They don't try things that may turn out badly."
- Tom Demarco, Peopleware

One of the best teachers I know once let a martial arts student punch a wooden board when he knew it wasn’t going to break (due to incorrect technique). After the student’s failed attempt, he said to the group “I could tell it wasn’t going to break, but who am I to stand in the way of your dreams and goals?”

It’s happened a number of times now that I have arrived at a company and heard statements like “run projects how you think best. After all, we hired you for your expertise and experience.” These bold proclamations inevitably give way to operational management’s desire to change things for the better good (i.e. over-ride some of my decisions).

Perhaps this happens because project management looks like a logical pre-defined process, much like operational management. However, the whole point of a project is to create something novel and never before seen, thus introducing a large element of the unknown to the undertaking. This is one of the reasons why risk analysis is such a major part of formalized project management methodologies.

Passion or concern can often lead operational management to actions which actually stifle a project. Much like a mother, at some point they have to ‘cut the apron strings’ and allow their child to make some mistakes for themselves.

It’s like watching a child banging their toy against a wall, do you say “that’s going to break if you keep doing that” or do you take the toy and save it from certain annihilation, potentially robbing them of a valuable lesson on taking care of their property? On the other hand, some lessons can’t be learnt the hard way, for example; crossing the road without looking both ways.

The question then becomes, do you stand by and watch someone make a mistake? I would hazard that this would often be the motivation of upper management, that to them it looks like you are about to make a mistake which could cost the company money or damage client relations, so isn’t it logical to intervene before its too late?

I’m fairly sure no managing director wakes up in the morning and thinks to themselves “hmm, how can I make my project manager’s life difficult today?” I should say that I don’t intend for this article to be a denigration of past employers. Operations managers generally don’t acquire their position without being highly intelligent and capable. But I have seen the phenomena Joel Spolsky calls Command and Conquer Management. This is where the person least qualified to make a decision is doing just that.

From the companies I have worked at so far, I have seen three distinct approaches when it comes to operational management dabbling in project management. One type would commonly interject if they felt they had a better way to do things (with changes I could not veto), another would occasionally come to the rescue if things weren’t going as planned (again, with me having no veto power), and probably the most interesting one has been a boss who only occasionally intervened, but still allowed me to have final say.



Personally, I wouldn’t want to work in an environment where people didn’t say something if they felt you were about to make a serious error with your work. But that is obviously part of what team is about. People need to be able to ask questions and give suggestions. But they should also be given the option to reject a suggestion without ego coming into it.

Project management isn’t an easy discipline, hence why not everyone does it. As mentioned earlier, the reason for this is because a significant portion of a project is unique. Getting good at tackling the unique aspect of projects only comes with experience, and experience comes in two flavors: success and failure. Unfortunately, it’s hard for some people to accept the unpredictable nature of software development because mistakes can be expensive.

Another interesting ingredient being added to this dynamic is the increasing uptake of industry standard project methodologies such as Britain’s PRINCE2. Although this is definitely a good direction for the software industry, it does pose a potential hurdle.

PRINCE2 is squarely aimed at project managers, there’s no doubt about it. The problem lies in the fact that non-project managers within the team also need to understand the methodology for it to work well. I believe it’s possible for a project manager to teach the basics of PRINCE2 to subordinates such as team managers, programmers, designers, etc. (just enough for them to get by). But would this work upwards, with corporate management?