Before my jump back into libraries over ten years ago, I used to teach project management to system developers and business analysts - Yup! as you can guess this was very challenging! Since that time, I know I’ve long forgotten the finer points of calculating critical path, activity dependencies and creating drill-down ghant charts. The tool I received certification on took me several weeks to master and at time was known the “Cadillac” of PM tools (perhaps it still is). I don't really keep up the project management tool race anymore, and found that I'm happiest myself managing projects with a good old solid plan, a pencil and a calendar. But in looking back on all the training in PM that I did, it’s the day and half theory class that I had to teach employees before the 3 days of software instruction that has stuck with me most.
Mark, from Gwinnett County Public Library, grabbed a photo of the visual (a folded napkin) that I shared at lunch the other day (
When the triangle gets out of balance, it's the PM's responsibility to make adjustments. For example, if the scope changes and additional deliverables are added, you'll need to either adjust your resources (as in add more bodies to the tasks) or increase the the project duration (using existing resources) to keep the project on track. Each of the three constraints always has an effect on each other, and good project managers know how to juggle these constraints well in order to achieve the planned results.
PM in Libraries:
Whenever I think about this triangle as it relates to many of the “projects” (and I use this term loosely) that I’ve seen initiated in libraries, I have come to the conclusion that for the most part we really don’t do projects (Note: true projects have end dates & resources) but we do have a lot of initiatives.
Where we fail the most at is in acknowledging and planning for constraints. Our “projects” (again used loosely) don’t have defined budgets and/or dedicated resources and often we even forget to assign an end date. Instead we just heap additional responsibilities on already stretched staff members and neglect t provide them with time off the desk to get things accomplished. Our time frames are loosey-goosey and we seldm assign end dates - for the most part it’s “whenever we have the time to get around to it.” And our scope? Well it may be defined at first, but without a well written project plan, we often experience creep and redirection. The bottom line is that the end result is rarely what we set out for.
What we do really well is set priorities and determine and define initiatives. But without addressing constraints and accounting for resources, time and scope of work, all we really have is great thoughts, good will and lots of frustration - sound familiar ?
PS: Michael and GCPL Emerging Tech team - we enjoyed the visit. Hope we can do it again soon, but this time at your place.
1 comment:
I was a software engineer for many years, and the lead software engineer on a couple of projects. In embedded systems we talk about three aspects: good, cheap, fast. Pick any two. If you want quality, it's going to cost time and resources. If you want it fast and good, it's going to cost you resources. Fast and cheap will cost you in quality. And so on.
This, at least, was the common wisdom among us software developers. It was the job of managers to pretend that this wasn't axiomatic.
Post a Comment