July 23, 2010 - 7 comments

What’s the difference?

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.

Published by: brettharned in Project Management

Comments

PM Hut
July 25, 2010 at 11:25 am

I think the main difference is the maturity of software project management in general, and the lack of education among customers. This lack of education results in unstable requirements, and that’s why Agile is considered by quite a few project managers as a better way to manage software projects (take a look at this article on agile myths).

About great project manager, here’s another concise article on the subject.

    brettharned
    August 3, 2010 at 7:28 am

    First-very cool that someone from PM Hut is reading my blog! You’re one of my bookmarks. Second, I agree with you on the lack of education among clients. I do feel that part of our job is to pitch in and make sure that our clients fully understand our process and product; thinking ahead and understanding your client’s point of view is key.

    I missed the second one about great project managers. Would you mind posting that one?

    Thanks!

Sam Barnes
July 26, 2010 at 8:25 am

Totally agree with everything you say (and thanks for the plug 🙂

“Agilefall”, this is a point I make in my next article due to be published next week. Everyone knows Waterfall and Agile, but again, the more digital agencies I have contact with the more often I come across the trend that they adopt this hybrid approach.

It seems to be the perfect method for dealing with the majority of web projects and I’ll no doubt annoy some people when my post goes live! (It’s a bit of a rant 😉

Stewart McCoy
August 2, 2010 at 11:43 pm

PMs are a critical element to a successful project, but they’re not given due recognition in the web design community. This article helped me gain insight into what a PM does and what is expected of a PM by other project members. Actually, this is the first article I’ve read about project managers.

Great read.

    brettharned
    August 3, 2010 at 7:21 am

    Thanks for reading and commenting, Stewart.

      Dortha
      April 29, 2011 at 10:36 pm

      I’m impressed! You’ve managed the almost ipmosslibe.

Leave a Reply