First taste of project management...

The readings for Unit 12 represent the first experience I've knowingly had with project management. I say "knowingly" because I held corporate jobs for over 10 years before applying to SIRLS, and during that time lived through some technology changes at work. So, obviously, I was on the user end of some project management decisions without really being aware of the underlying process. Now that I see how time-consuming and involved those projects are, I have a better appreciation for the work required to bring new projects to fruition. Looking back, I remember that most of the time employees were irritated when new technologies were rolled out. Employees were used to the existing process, didn't always feel like learning a new system, and were sometimes slow to see the benefits of the new technology. After all that work, I can just imagine the IT people thinking, "What a bunch of ungrateful bastards!"

The reading that I valued the most this week was Cervone's "How not to run a digital library project". Because this subject is new to me, I found his list of "rules" to be a good start for how to view, and approach, project management. Rule #1 struck me almost immediately. Cervone's comment that, "Even when requirements are gathered, they are ignored in the belief that the project team does, in fact, know better what the end user wants," reminded me of a couple instances at work when new systems failed to efficiently do what employees required. For example, I remember a new software program that hid a frequently used function in a location that was cumbersome to access (3 or 4 clicks instead of 2). This happened because the project team was unaware how we, the employees, used that function.

I also like the WAG example in Rule #4. I don't remember seeing this acronym before, but I appreciate it's meaning and understand the pitfalls of using a WAG for planning purposes. On the surface the difference between "effort" and "duration" appears subtle, but it's an important distinction when estimating the time, and cost, of a project.

Another favorite was Rule #8. I certainly see how "scope creep" can quickly undermine a project, leading to cost overruns, time delays, loss of focus, and confusion regarding end user needs. I imagine that the more ambitious the project (and the more people involved), the greater the risk of "scope creep". Cervone's advice to "be flexible, but firm" is well taken. Obviously, flexibility is necessary because some changes are inevitable with big projects, but stray too far, and the final product may please no one. Therefore, if major changes are required, returning to the drawing board to draft a new plan may be warranted.