Traditional project management in an agile world

Being a project manager can be a tough gig, so here are a few pieces of advice

Having worn the software platform implementation “hat” for over a decade now—in some situations it was more of a “helmet”—I’ve worked with my fair share of IT project managers. This may come as a groundbreaking revelation, so prepare yourself: from my experience, some have been good and—gasp!—some have been bad. While you’re collecting your jaw off of the floor, allow me to elaborate.

Being a project manager (PM) can be a tough gig; when everything is going fine, you may, at times, be viewed with disdain: a mere “meeting scheduler” who collects status updates from the key stakeholders and SMEs, reporting them upwards. When everything isn’t going fine, they are in the cross-hairs of everyone: the key stakeholders, the SMEs and the higher-ups they report to. In a sense, a project manager is like being an offensive linemen in football or a goalkeeper in soccer—when they’re exceling, most people don’t notice how much they’re truly doing behind the scenes. But when they make a mistake, everyone notices and bears down on them. Along with the fact they have to manage the project’s schedule/scope/budget with all of the differing personalities involved with the project itself, it adds up to quite the plate-spinning affair.

When it comes to implementing platform software, I mulled over the common good and bad qualities I’ve encountered with project managers on platform implementations. Also, I polled several of my Onspring professional services colleagues to get their take.

Good PM Qualities

I’ll start with the good qualities since I’m generally viewed as such an overwhelmingly positive person by people who know me (read that as: “I’m not”).

Has a basic understanding of technology. This is a big one. It’s important that PMs have a fundamental understanding of a) What the technology does and b) Some of the jargon associated with not only the technology itself, but the software development life cycle (SDLC) in general. This is essential when it comes to facilitating conversations between the project team and knowing which resources to pull in at various phases of the implementation. It also means we don’t have to constantly “translate” what we’re doing into layman’s terms, which can easily be misconstrued. That is especially impactful to me since, as mentioned earlier, the PM is typically the “conduit” to upper management.
Follows up on deadlines. This is PM 101, so it doesn’t require much of a detailed explanation. This also includes holding the right people accountable when deadlines are threatened.
Knows who to involve, and when. This is especially prevalent when highly technical resources are needed on either the vendors’ or the customers’ side.
Project Status – Know more than just “Green/Yellow/Red”. If the project status is yellow or red, we always do our best to explain why in detail. In the case of technical roadblocks, a good PM can communicate, at least at a basic level, what’s going wrong beyond the status report provided by the vendor other than simply, “This isn’t working.”

Poor PM Attributes

And now for the bad qualities. Fair warning, you’ll notice I’m quite passionate when it comes to #1.

Extremely detailed project plans. First off, I want everyone to know when I typed the bolded text to the left, I typed it very angrily, which is to say I hit the keys much harder than normal—it might’ve alarmed the people sitting close to me (yes, I’m one of those “spirited typer” people). This line item is also the reason for the blog’s title. For example, Onspring is a highly–configurable tool that prides itself first and foremost on performance, both from an end user’s and administrator/configurer’s perspectives. Because we can configure very quickly, it lends itself to very agile development. Sure, it’s important to have design documentation (requirements, process flows, etc.) ready to go prior to configuring, but as the old adage goes, “The best-laid plans of mice and men often go awry.” As a quick sub-note, yes, I’m aware that typing that out makes me sound very old. Anyway, what seems like a good idea on paper may not be a good idea once you’ve seen it in the tool, so a business process’s flow can quickly zig when you thought it was going to zag. If we were to document every field, dashboard, report and notification in a project plan, we’d spend more time updating than we would doing actual configuration—I say that from ample experience. Now, I’m not at all saying project plans are a waste of time, they can be quite useful. However, for a highly-agile, highly-configurable tool, they must be more “higher-level” in nature.
Does not have a basic understanding of technology. I hate to continue beating a deceased equine here, but see #1 on the “good” list.
Unrealistic Deadlines. This can be a real problem and unworkable targets come in a variety of forms:
- Scheduling key project phases/activities over vacations/holidays.
- Asking the project team to “throw more people at it.” From my experience, this can sometimes accelerate delivery, but it can also do the opposite.
- Adhering to a deadline until the bitter end, even when all evidence indicates that it will not be met.

While this may be fairly biased from a vendor’s perspective, I’m a firm believer that part of the project manager’s job, regardless of the project, is to convince other stakeholders as quickly as possible that their role on the project is practical and adds value. And as a consultant, part of our job isn’t so dissimilar.

I want to finish with a note about Onspring’s Professional Services. We like to work with all kinds of project managers, and no matter what kind of PM you are, we can help you do your best work