Project Management

A Few Things Every Job-Seeking Programmer Should Know About Project Management (part 1)

~ Andrew Stellman ~ 4 Comments

I’ve met a lot of programmers who really hate project management. And it’s not that surprising, because project management done poorly can be unnecessarily restrictive. But if you’re a developer looking for a job, employers are more and more likely to expect you to know something about project management. Luckily, good project management can make your life easier, and it’s worth knowing about it – not just for job interviews, but to help you get the most out of your own projects. Here are a few basic things that I think every developer ought to know about project management, and why I think you should care about them.

Tough Programmer Interview Questions: Project Management

Programmers are often surprised when a job interview shifts from technical questions to questions about project management. I just saw a great example of this in a recent Head First C# forum post:

I am a C# programmer since 2003. I recently took a job interview where I was asked several questions about project management.

  • How do you make an estimate for building a C# program?
  • How is a project with 3 programmers different from project with 15?

– PiterKhasak

This is a lot more common that developers realize. I’ve seen a lot of discussion lately about how to do effective programmer job searching, especially for relatively new developers who have three years of experience or less. Did you ever ace the tech part of an interview, only to find that you didn’t get the job? I bet that a lot of the time it comes down to questions that seem peripheral or less relevant – to the a junior developer.

Not to a lot of senior developers. That’s one of the biggest differences in attitude that I’ve seen between people who are new to development and people who have been doing it for a long time. And in a lot of cases, I think it really does come down to attitude. So my goal with this post is to outline the basics of project management, the core things that really matter.

Why should you care about project management?

There’s a flip side to project management, too. A colleague of mine once asked me, “What’s the most important part of project management?” I told him that it’s managing stakeholder expectations – making sure that the people who have control of the project or are affected by it are in the loop on all the important developments as the project rolls along. If bad things happen, they know about them in advance, and are prepared. The reason for this is that some projects fail (more than you think!), often for reasons that have nothing to do with the team. If you manage everyone’s expectations, get them on the team’s side, then the developers can come out as heroes fighting a lost cause. On the other hand, a project can be a roaring success, but if everyone expects something that’s not exactly what was delivered, the developers could be blamed for something that they had no control over. Expectations matter, communication matters, and these things can have a big impact on the project and the team.

And that’s why developers should care about project management: it affects your life, even when your job is to keep your nose buried in code all day.

A lot of developers have a very poor opinion of project management and project managers. I’ve spent a lot of my career writing books and giving training to help project managers improve their skills. Over the years, I’ve met many different types of project managers. And, unfortunately, while there are plenty of great ones out there, there are a lot of really bad ones as well. In any field, there is a wide range of skill level and aptitude. If you’re a developer who’s only ever worked with poor project managers, it’s not surprising if you ended up with a dim view of the project management as a whole.

But even if you’re a developer who doesn’t have a high opinion of the field, you should at least acknowledge that learning more about it can have an impact on your own career. I’ve personally seen employers pass on good developers who didn’t know enough about project management, even ones who had the technical skills to do the job.

I’ve also conducted a lot of developer interviews, easily several hundred of them over the last decade. And one thing that I’ve noticed is that really good developers have a healthy respect for exactly the same things that really good project managers care about: the work and the features needed to create the software, the team that crafts it, the effort required to build it, and the quality of the final product. That’s why I think that learning more about project management can help make you a better developer.

In the next part of this post, I’ll outline those things, and make a case for why they should matter to you.

Our obsessive project tracking problem

~ Andrew Stellman ~ Leave a comment

 

As a group, we developers have a project tracking problem: the problem is that we constantly, almost obsessively want to track our projects, and it’s made worse by the fact that it’s so easy to abuse otherwise great tools like JIRA and Bugzilla. Unfortunately, while tracking projects may feel useful and productive, for most teams it’s just busywork – and it can lead to a self-imposed exercise in needless bureaucracy that just wastes our time. But with a few ground rules, you can escape the project tracking trap and use a tracking tool effectively.

Who needs Big Brother?

About five years ago, a small company brought me in for a few months to help them do better project management. For about a year before I got there, they’d put a couple of their best developers on the problem, and they came up with an ingenious solution for tracking projects. The team built a database to keep track of all the projects they were working on, typically about a dozen and a half simultaneous projects running at any time. This tool gave them the ability to figure out exactly what tasks had been done, who did them, and how long they took. If you wanted to know what any specific programmer was working on eight weeks ago on Tuesday afternoon, their tool would be able to tell you that.

And it all worked perfectly.

Except that their projects were still late and full of bugs, and the users were losing their last shred of patience. This team had promised their users that things would get better with their fantastic new project tracking system. But even though the system was working exactly as advertised, the software still had serious problems, and everyone was unhappy.

I’ve been thinking a lot about that company lately because I’ve been doing a lot of work with JIRA. And while JIRA is a really good tool – one that can have a very positive effect on how you manage a project – it seems to really tempt a lot of good developers down the same project tracking trap that the small company fell into.

Programmers normally hate it when their time is tracked, which is obvious to anyone who makes the mistake of suggesting to a programming team that they should start filling out timecards that list out exactly what each person did that day. That happened at my first programming job after college: the boss, a newly minted MBA, told the programmers to fill out timecards that listed what project they were working on hour by hour, and there was nearly a rebellion. But for some reason, JIRA, Bugzilla, and other issue tracking systems cause programmers to step up and volunteer for exactly that treatment. It’s an odd phenomenon, and I think it has an interesting explanation.

Let’s get something straight, here: I really like JIRA a lot. It’s a great issue tracking tool, and a very good workflow tool when it’s used right. I’ve spent some time building JIRA plugins, and the plugin API is intuitive and easy to use. Sure, I’ve got a couple of nitpicks here and there (I’m not so happy with the user interface or the filters in version 3.x, although it’s definitely improved in JIRA 4). But for the most part, JIRA is one of the best issue management and workflow tools I’ve ever used.

When it’s used right.

But when you take a perfectly good tool and abuse it, you’re bound to get bad results. And that’s especially true when it comes to project tracking tools.

Tracking projects is not a useful goal

JIRA suffers from a problem that a lot of really good issue tracking tools suffer from. It’s really good at tracking things. And for a lot of developers, that causes a “when you’re holding a hammer, everything looks like a nail” problem. Actually, scratch that. It causes a “you’re holding a screwdriver, but for some reason you want to pound nails with it” problem. It’s odd when you step back from it, but it really seems to make sense at the time.

What happens is that some developers – and I admit that I’ve been guilty of this at least once or twice myself – see a tool that gathers information about what happened on a project, and this causes something to click for us. We  start tracking everything, from requirements to goals to user requests to every little ten-minute task that needs to be done. We become our own “big brother,” doing what amounts to voluntarily filling out the most detailed timecards possible.

The “big brother” style of project tracking is especially bad when the “pointy haired boss” type of managers pick up on it. Suddenly, the team is being nagged to start entering more and more granular estimates and updating dates in tickets. For a boss who’s nervous about delivering something, it seems like the right thing to do is to start nagging programmers about every little task that’s entered into the system, or chasing down anyone who’s got a task assigned without a due date.

Which is especially bad, because that’s not really what those tools are for. There’s a big difference between tracking a task or a bug so it doesn’t slip between the cracks and tracking every little thing that a the programmers do for posterity. I think it’s especially ironic that developers often volunteer for this themselves. I think it’s because we see a tool that can track something and it causes us to want to use it. “It tracks tasks? Then it should track all the tasks!”

Better living through project tracking

A while back the New York Times ran a story on people who use everyday tools like Foursquare and Twitter, blogs, spreadsheets, and datebooks to obsessively track data about themselves. I think this excerpt is telling, especially the bit at the very end (emphasis mine):

At the center of this personal laboratory is the mobile phone. During the years that personal-data systems were making their rapid technical progress, many people started entering small reports about their lives into a phone. Sharing became the term for the quick post to a social network: a status update to Facebook, a reading list on Goodreads, a location on Dopplr, Web tags to Delicious, songs toLast.fm, your breakfast menu on Twitter. “People got used to sharing,” says David Lammers-Meis, who leads the design work on the fitness-tracking products at Garmin. “The more they want to share, the more they want to have something to share.” Personal data are ideally suited to a social life of sharing. You might not always have something to say, but you always have a number to report.

I think that the sort of person who becomes a developer is especially susceptible to whatever it is that causes some people to obsessively track things about their lives. My personal theory is that this is caused by the same itch causes us to want to obsessively collect every last episode of MST3K (or whatever it is we happen to want to obsessively collect). And like that giant collection of, say, legos or video game cartridges or Start Wars figures memorabilia or dice, at some point we can’t actually play with most of it. That’s fine for collections (assuming you have it in a cool display case, and not strewn all around your home in piles so high that they cause a fire hazard). But for tracking data from projects, it’s worse than useless, because it takes effort to keep up, and it can demoralize the software team because they start to feel like they’re creating more tickets than new lines of code.

Luckily, if you follow a few ground rules, you can break the obsessive cycle and start using project tracking the way it should be used. Here’s what I’ve recommended to people in the past, and it seems to get good results:

  • Figure out in advance what you want to track. Most teams use an issue tracker for bugs. A lot of teams use it to figure out what work the developers are going to do. Some use it for new feature requests. I’ve seen people try to use an issue tracker for managing requirements (although personally, I really dislike that use of it). All of that could be fine, but any of it can potentially become obsessive. Before you start your project or the next iteration, sit down with the team for a few minutes and write down what you’ll be tracking. Stick it on a Wiki page, and add a sentence or two explaining how each one of those things needs to be used. I’m always amazed at how just a little bit of planning like this keeps the way we use a tool from creeping into “big brother” territory.
  • Use post-mortem reports to track your lessons learned. One reason that “big brother” style project tracking makes intuitive sense is that we want to keep track of the lessons we learned on this project in order to make the next one run better. But there’s very little you can learn from an overwhelming pile of tracking tickets. Instead, try running a project post-mortem at the end of the project. And don’t just do it for projects that ran badly. Post-mortems are really good for making sure you take a good project and turn it into great habits for the team by writing down the lessons you learned.
  • Focus on trends and simple metrics, not complete history. A good project tracking system can spit out a lot of reports. So many reports, in fact, that it’s hard to make any real sense of them. That’s why I like to try to simplify the kind of data I get out of the system. I’m a big fan of simple metrics like (% of engineering effort per project phase) that let you compare projects or iterations against each other. Also, burn-down charts or other earned value metrics can be really valuable in figuring out how your current project is going.

The bottom line is that there’s a difference between project tracking and actually managing your project. If you really want to use JIRA for project management, use a tool like Greenhopper that was built for it. (I’ve been using Greenhopper lately, and I like it a lot. But if someone has a pointer to an open source tool they really like that ties a task board or agile project management into their issue tracker, I’d love to hear about it.) The most important thing to remember is that tracking your project is a means to an end, and not a goal by itself.

The perils of a schedule

~ Andrew Stellman ~ 1 Comment

The walls are closing in

We got this e-mail a few days ago from one of our readers:

Hello,

I bought your book, “Applied Software Project Management.” It seems very good overall, but I can’t get past the fact that your book seems to imply that software requirements come after the project plan/WBS/scheduling. Am I missing something?

On page 40, the script for estimating states that the input is documentation that defines the scope of the work being performed. Does this include the SRS? If so, why is this not made more explicit in your book (since requirements plays such a big role)? If not, how can a good estimate and schedule be generator before the requirements analysis has been performed?

I don’t get a solid sense of the relative timing of the activities (especially the requirements activity). Can you comment on this?

Thanks!!

— Wayne M.

That’s an excellent question. I’ve got a straightforward answer, and I’ve got a more involved answer.

The straightforward answer is yes. If you’re using Wideband Delphi (or, really, almost any estimation practice) to come up with estimates that you’ll turn into a schedule, then you need to get a handle on exactly what you’re estimating. So yes, when we say in our book that the input to the process is the “Vision and Scope document, or other documentation that defines the scope of the work product being estimated,” the “other documentation” we’re referring to definitely includes any software requirements you have. (For any readers who haven’t read our book, you can download a PDF of the estimation chapter that this reader’s referring to.)

Let me be clear about something here. You’re absolutely right that requirements analysis leads to more accurate schedules. If you’re lucky enough to have a really detailed specification at the beginning of the project that describes, in detail, all of the software that you’re going to build, then that will give you a much more accurate schedule than if you had a three-page Vision and Scope document that simply lets you know who the users and stakeholders are, explains their needs, and gives you the broad strokes about what features the team will build to meet those needs.

But when’s the last time you actually had the luxury of a complete specification before you had to deliver a schedule? And I’m stressing the word “complete” for a reason: it’s very rare that you’re done with the requirements before you’ve started building the software. So rare, in fact, that neither Jenny nor I have ever seen it in our entire careers, and I suspect very few (if any) of our readers have, either.

A good Agile developer might point out that this is the reasoning behind one of the core Agile principles: “Welcome changing requirements, even late in development.” And, in fact, that’s exactly why we dedicated so much of the chapter on software requirements in Applied Software Project Management to change control, because it’s important to not only accept that change happens, but to recognize it as a good thing. It’s better to change course partway through the project rather than to trundle on to an end goal that you know won’t actually meet your users’ needs or make your customers happy.

So with that in mind, go back to the process you mentioned. Specifically, take a look at the end of the script, because this is where it ties directly into the question you asked:

Exit Criteria The project plan has been updated to reflect the impact of the change, and work to implement the change has begun.

There’s an important idea there in those first six words: the project plan has been updated. That means that any time your world changes, you need to go back and update the scope, the WBS, the schedule, all the actual stuff you plan to deliverable (which might be written down in a statement of work), the list of people doing the work, a risk plan (if you built one)… all the stuff you used to plan your project.

…because there’s no single one Best Wayâ„¢ to build software

And that’s why we didn’t give an explicit order to the activities. Sometimes you’ll end up planning out your project and building a schedule before you do requirements analysis; sometimes you’ll build a schedule after. Our goal was to help you do it well in either case. And by not forcing our readers into a single process or methodology, we don’t have to pretend to know all the answers… because, as far as I know, there is no single one Best Wayâ„¢ to build software.  That’s the main idea, by the way, behind our “diagnose and fix” approach to improving the way you build software. Trying to overhaul your whole software process by doing a major process improvement effort is hard; adopting specific practices that make incremental improvements to the areas that hurt the most is much easier and a lot less risky.

This may sound like we’re calling for a lot of documentation, but it doesn’t have to be like that. Obviously, if you’re working on a team with dozens or even hundreds of people (like the teams Jenny often leads), this can be a pretty big task. But if you’ve got a small team working on a project that will take a few weeks to do, then this may just amount to rearranging your task board, updating your user story cards, updating a couple of Wiki pages, and having a quick stand-up meeting to make sure everyone’s in sync. That’s why people often talk about how running a really big team is like steering an aircraft carrier, because changing course requires miles of water, while running a small team is a lot more like piloting a speedboat that can change course really quickly.

So that’s the straightforward answer. But I think it’s worth delving a little deeper and asking an important question: What’s the nature of a schedule? I know, that probably seems like an odd question, but it’s actually important to understand what schedules are and how they’re used. (Technically, it’s only important if you want your projects to run well.)

A naïve answer might be to simply defer to that old project management chestnut: “Plan the work and work the plan.” If you haven’t heard that saying, take a minute and do a Google search for it. It’s one of those sayings that people love to quote, and it pretty much summarizes how a lot of people use (abuse?) project schedules.

I don’t like that saying, and there’s a reason for that.  I mean, don’t get me wrong, here. “Working the plan” is fine if it that plan accounts for changes. That’s one thing I really like about the PMBOK® and PMP approach: a whole lot of project planning revolves around how to handle changes, and specifically about dealing with change control. Also, it’s a great idea to make sure that you include a reserve for your project, and you can use risk planning to try to get a handle on the unknown.

To be continued in “The perils of a schedule, part II“