The life of a project

A picture on Twitter caught my eye earlier tonight. “The life of a project” captures a person’s mental state through the life of the project. It was particularly meaningful to me because it basically describes what I’ve gone through this past week at work. I’ve been working on a very high stakes proof of concept for a customer with a lot to lose, and it’s been pretty taxing. You can ask my family; I haven’t been much fun to be around the past few days. Fortunately, we’re on the upward slope now: lessons have been learned for phase 2 and the prototype cluster is basically working at this point.

It occurs to me that many projects I’ve been involved with or aware of follow this general pattern. I stopped to think about why that is. For this project, the business requirements weren’t incomplete, although that is often an issue for projects. The technical requirements were missing, though. As it turns out, a few extra DLLs (yes, this is a Windows execution environment) were needed. The software used for this project is pretty awful, and so the error messages weren’t particularly helpful. It took the better part of a day just to leap that particular hurdle.

Another contributing factor was not knowing where we were starting from. (As the old saying goes, “I don’t know where we are, but we’re making good time!”) I thought we were basically cloning a similar project we had done for another customer, and started my work based on that assumption. As it turns out, the environment we were starting from was not nearly as robust and automated as I had been led to believe. The result was two days of effort getting to where I thought we would be after a couple of hours. This wasn’t entirely bad. It gave me an opportunity to work with parts of our product stack that I haven’t worked with much, and it pointed out a lot of areas where future such projects could be done much better. But it was also a great way to add to the already high levels of stress.

Even in a small company, nobody is familiar with everything. Time spent re-explaining what I was trying to do when I had someone new helping me didn’t move the project forward. Likewise, having to hop from person to person in order to get the right expertise was a barrier to progress. I was fortunate that all of my coworkers were extremely willing to help, and I certainly can’t blame them for not knowing everything. Nonetheless, it was frustrating at times.

Certainly the long downward slide that characterizes most of the life of a project can be mitigated. Starting with a more complete understanding of requirements, knowing what you’re starting from, and having the right expertise available can reduce the surprises, frustration, and sadness of a project. Still, I think it’s human nature to experience this to some degree. We always start out confident in our abilities and blissfully ignorant of the traps that are waiting for us.

Eight reasons to become a project manager?

I happened upon an article over the weekend titled “8 reasons to consider moving into project management“. The site happens to be a SaaS vendor for project management tools, so it makes sense that they’d encourage people to enter the profession. Even so, the case for some of these seems pretty slim. I’m hardly a leading expert on project management, but I have some experience and education in the field, so I do have some opinions on the matter. Since I’m in a particularly saucy mood, I thought I’d reply to their reasons.

Learn New Skills

This applies to any new job. Sure, project managers have to converse in a variety of technical domains as well as to business leaders, but that doesn’t mean you’re learning much more than a new vocabulary. Frankly, if you’re not learning new skills in your current job, what are you even doing?

Make Contacts

Get yelled at by people all over the org chart! Protip for aspiring project managers: make contacts and then move into project management. Nothing helps you get tasks accomplished like having friends all over the organization.

Get Some Variety

You never know what will blow up in your face today! Maybe your star analyst will win the lottery. Maybe the CEO will change the project requirements 75% of the way through. Maybe your developers forgot to tell you about this problem they had that’s about to set your schedule back three months.

Open Up Your Career Horizons

Okay, this one’s harder to snark. It’s really hard to know what’s available until you know what’s available. This ties into the “make contacts” argument, though, so I’ll deduct half a point for that.

See an End Product

“…seeing your ideas become reality.” More like seeing someone else’s ideas become a reality. If the organizational culture is such that everyone feels a sense of ownership in whatever widget goes out the door, this point is irrelevant. If the organizational culture is not this way, it should be.

Lead a Team

Leading a team is awesome, unless it isn’t. People who are not well-suited for leadership roles (or who otherwise are, but have no desire to be in such a role), are less happy when in leadership positions, and the team probably suffers for that as well.

Work Flexibly

Get home at a different time every night! I’ll give credit to the author for pointing out that you will probably work more hours. But you can sometimes spend time driving, so yay? Plenty of organizations are warming to the idea of allowing employees of many positions to work flexible hours.

Become More Confident

Only a minority of projects come in under budget, on time, and fully-featured. The success rate can be as low as 11% (Tichy and Bascom, 2008). If failure builds your confidence, swing away. Otherwise, you’d better be really good at finding the moral victories.

Project management is not for everyone. It can be a very demanding field, especially in organizations where the project manager is not given the resources to lead the project appropriately. I’m all for people pursuing whatever career they want, but this article paints a far-too-rosy picture. All of the points listed are potential benefits, but they only work out that way if you’re interested in project management to begin with. Otherwise, there are much less stressful ways to get what you want.

Managing your time when you’re not very good at it

A friend considering a return to school recently asked me how I manage my time while being (in no particular order) a graduate student, a full-time employee, a husband, a father, a contributor to various projects, etc. As you may have surmised from the frequency with which I update this blog, the answer is “poorly”. But since I’ve been meaning to write about this subject for a while, I decided now is as good a time as any to commit my answer to more words.

I really do maintain that I’m not good at time management, although I’ve done well enough to survive into my third year of graduate school. Maybe the smartest thing I did was to slowly ramp up: I had a semester of school finished before my daughter was born, which was very helpful in allowing me to adjust to both separately. I’ve also borrowed heavily from some of Tom Limoncelli’s sage advice, although I’m not nearly as good about following it as I’d like to be.

To manage the high-level view of things, I have turned to TaskJuggler, a free software project management tool. I use this to manage application development, paper submission, and miscellaneous projects at work. For school, I mostly use it to track the classes I’m taking and progress (such that it is) on my thesis. For larger projects (e.g. research papers) within a course, I’ll include those as sub-tasks, decomposed as necessary.

For smaller tasks, and the miscellaneous to-do items of life, I use a text-based to-do list manager called TuDu. True to Limoncelli’s “The Cycle” methodology, I try to have every task scheduled for a day, even if that day slips. Tasks with no scheduled day often languish forever. The other advantage to scheduling tasks, especially things like homework and other school-related tasks, is that I can make sure I don’t try to do too much in one night. It can be easy to forget how much you have to do until it is too late to do some of it earlier.

Perhaps the most important thing I’ve learned about managing my time is that sometimes, things will hit the floor. That’s okay, so long as it’s well-planned. Sometimes you have to decide where effort is best spent. As an example, at the end of last semester, I was facing the last week of classes with two research papers, a group project, and a homework assignment due. I decided to sell out the homework assignment in favor of the research paper for that class, figuring that the paper was worth more to my grade than the homework. I did get a pretty bad score in the class, but my overall grade was still an A.

It helps to set aside time to concentrate on what’s important. Between the time I get home and the time my daughter goes to bed, I spend time with her and my wife. The only time I’ll skip that is if I have something else scheduled that evening, or if I’m hopelessly underwater on my to-do list. When class is cancelled or dismisses extra early, I use that time to work on any outstanding schoolwork I may have. I’ve commited to git repositories while on the bus. And when life settles down a bit, I’m going to take a nice, long breath.

Proposed change to Fedora docs schedule

In the most ideal situations, project management can be a challenge. In a fast-moving, community-driven, highly-visible project like Fedora, it can be near-madness. Although the Docs group tries to keep to the schedule when producing guides, the unfortunate reality is that guides rarely meet the scheduled milestones. I’m a firm believer in the idea that if the schedule is never met, it’s the schedule that’s wrong, not the contributors.

With that in mind, it was proposed in this week’s Docs meeting that the branching of guides be 4 weeks prior to the final release date, instead of shortly after the Alpha release. This buys guide writers more time to incorporate the changes a new release brings. Unfortunately, it puts an extra crunch on translators since they then only have four weeks to update translations if guides are to ship in concert with the OS.

The reality is that it doesn’t change much, I expect. Since the reality is that the guides don’t come in on time, it does little harm to have the schedule reflect that fact. I hope. I posted a message to the Docs and Translation teams earlier this week requesting comment. Modified schedule proposals are available at

Book Review: The Deadline

Project management is an underrepresented genre in fiction. That it even exists is probably no small surprise to many, and probably of interest to even fewer. There is very little about project management that the average reader would find sexy or thrilling. Fortunately, Tom DeMarco makes no attempts at either (despite the occasional hint of a romantic undercurrent).

I wasn’t sure what to expect when my professor mentioned this book in class recently — perhaps a dashing project manager who sweeps through saving the day and buckling swashes at every opportunity. Instead, the reader is given Webster Tompkins, a competent and entirely normal project manager with years of experience and a looming layoff (or, in the words of Mr. Tompkins’ barely fictitious employer: “Released to Seek Opportunities Elsewhere”). While dozing in the back of an assembly, Tompkins is whisked off to the former Soviet state of Morovia. The Noble National Leader plans to turn his small country into the world leader in shrink-wrapped software, and Tompkins is just the man to lead the way.

What sets The Deadline apart as a novel is its entirely unconcealed intention to be a learning tool. The plot, exaggerated conditions and all, serves as a framework to present critical project management wisdom. Conveniently, Tompkins keeps a journal in which is writes these lessons as they occur, condensing the knowledge into bite-sized nuggets. What sets The Deadline apart as a learning tool is its readability. Although this book could readily be used in a formal project management course, it is interesting and well-written. Unlike the dialogue in project management scenarios given in textbooks (which, with apologies to Brewer and Dittman, is lousy), The Deadline reads like actual conversations had been transcribed. The end result is an informative and entertaining read that goes by far too quickly.

Perhaps the most striking thing about DeMarco’s novel is the publication date: 1997. At no time during my reading did I find myself thinking “boy, I’m sure glad that problem is solved now.” Although the nature of IT has changed in the decade and a half since The Deadline was written, the lessons are still very applicable. Especially when it comes to managing the human resources, it seems the lessons are still being relearned by each successive generation of managers (or sometimes not). Being a systems engineer and not a developer may slant my view of the current state, and it is entirely likely that software development managers have absorbed these lessons better. Until then, this book should required reading for every IT manager, project manager or otherwise.