I'm really impressed by a number of project management articles I've been reading lately. It's pretty amazing that so many people have the same feelings and experiences as project managers. What's really interesting to me is few sites recognize the fact that there are differences in what we do as project managers. To be honest, when I see "PMP" or any other formality in PM, I tend to look away. But maybe that's just because of what I do. I'm a project manager for the interwebs, you see. A nerd whose nerd rules don't apply to your nerd rules. Ok, well maybe they do. But let's at least agree on this: our work is different.

In a recent post, Iron Paper points out some of the differences between "regular" and web project management. I think what they've come up with is a great start--as project risks. Let's think about it:

Changing customer requirements
We know all know that requirements gathering is a difficult process within web projects. I know some guys who could talk about approaches for hours. It's a fact: the requirements for our projects need to be documented and stuck to. Otherwise, a new-fangled web thing will pop up and our clients will ask for it to be included on the home page, front and center. I'm not saying we never bend, but if it's not a requirement of the scope, it's not on the table (for the time being). Therefore, not documenting your requirements is a risk.

Evolving market conditions.
Well played. Clients like new-fangled things (see above), and there's always something in the works, somewhere. This is more of a risk to me, because we always know that the next big thing is on the horizon. That's why we follow web standards and talk to our clients about what is best for them.

Frequently tight or unrealistic deadlines.
I've been managing communications projects for a while now. I think I have had a handful of realistic deadlines. This is more of a risk that your company takes on when searching for new clients. If you're willing to work under a deadline that feels too tight, you run the risk of disappointing your clients. I honestly believe in clear and realistic  communications around deadlines and project expectations; someone is going to be unhappy if you're not up-front about what you can do within the time provided.

Need for real interaction with users and a degree of uncertainty
This is a really great point. We certainly have to deal with user expectations, but it depends on your project scope and your work flow. If your client wants to continue to test and refine their work (with or without you), it's great. If they want to design a site without your recommended research and testing, it's another story. For that reason alone, I call this a risk. It all comes back to your process and your scope.

Note: I have to say that I was impressed by the article by Iron Paper. I'm not saying that they're wrong. In fact, I'm impressed by the thought. I just happen to look at the above as risks--not necessarily differences in our practices. I have to think that project managers in verticals outside of the web are dealing with evolving project requirements and market conditions, as well as ridiculous timelines. Anyway, I would have commented on their post if a comments section was open.

So, where I am going with this?

I've been talking about the difference in what web project managers do in relation to the rest of the field for a while. A colleague in England, Sam Barnes, posted a great blog earlier this week about what makes a great PM. In it, he also recognizes the fact that we're just different.

That post got me thinking about what does make us different. I mean, we all do manage people and projects, and make sure that our work is completed on time and on budget. Beyond that, there really isn't too much, right? For me, it comes down to two crucial elements:

The process.
We can't always work agile, and we can't always work waterfall. We can work Agifall (I totally did not coin this, but love it)...or some sort of hybrid. I like to think that most web project managers who work with full UX, Creative (design and copy) and Development teams adapt each experience to their clients' needs and the project needs. We just can't prescribe a process to our teams and be by the book. It will never work. It feels as though the methodologies were not built with the risks that Iron Paper mentioned in their post. So, we go rogue and get things done on our own and create our own process.

The people.
We're not just dealing with developers here! We're not in IT and we're certainly not in construction. We're building products for a wide range of people, in a wide range of disciplines. Yes, I recognize that IT does the same thing. But there are so many considerations for web development projects: the information architecture, the visual design, and the infrastructure. It's multi-tiered, and we need to understand how each discipline works--and how they work differently, but on the same projects. We have to manage communications between the groups and be sensitive to their needs throughout each phase of the project. On the other hand, we have to handle the back and forth with our clients. This means we can't just talk tech to the client; we also have to talk IA and design. The makeup of people and disciplines is quite diverse and can make things complex.
So, in the real world, we are very much alike. But our two core project attributes make us different. In the spirit of this post, I welcome anyone to comment with additional ideas. Or, continue the chain and link back to me and Iron Paper.