C H A P T E R  3

Project Management Essentials

Quality, features, schedule – pick two.

Project management? Isn't this a software development book?

Yes, but working on a larger-than-one-person development project means working on a team; and working on a team means being managed. So learning something about project management from both sides is an essential part of learning software development.

Project management is an involved and complicated set of tasks. We'll restrict ourselves to several tasks that will impact you as a developer the most. They are the following:

• Project planning
• Estimation and scheduling
• Resource management
• Project oversight
• Project reviews and presentations
• The project post-mortem

Project Planning

Project planning is forever. By that I mean that project planning continues throughout the entire duration of the project. “The Plan” is never really set in stone, because things in a typical software project are usually in constant flux. In most projects, and especially in those that are using a plan-driven process model, a project plan is an actual document that is written by the project manager, and that is approved and signed off on by the development team and by upper management. It is, in effect, a contract, albeit a rolling one, of what the team is going to do and how they are going to do it. It also says how the project will be managed, and in the extreme plan-driven cases, even states how and when the document itself will be modified.

What's in the project plan? Generally a project plan consists of the following seven parts:

• Introduction and explanation of the project
• Project organization
• Risk analysis
• Hardware, software, and human resource requirements
• Work breakdown and task estimates
• Project schedule
• Project monitoring and reporting mechanisms, collectively known as project oversight

Not all of these are necessary for all projects or project methodologies. In particular, plan-driven projects will use all of them, while agile projects may use a few on a single page.

Project plans are a great tool for setting down what you think you're doing, an outline of how it will be done, and how you plan on executing the outline. The problem with a project plan is that it's static. Once it's written and signed off on, upper management thinks the project will run exactly as stated in the plan. But the reality of the project often thwarts the plan.

Project Organization

The project organization section of the plan contains the following three things:

• How you're going to organize the team
• What process model the project will be using
• How will the project be run on a day-to-day basis

If you're working with an experienced team, all this is already known to everyone, so your project organization section can be, “We'll do what we usually do.” However, this section is a necessity for brand-new projects and inexperienced teams, because the organization section gives you something to hang your hat on when you start the actual project work.

Risk Analysis

In the risk analysis section, you need to think about the bad things.¹ What can possibly go wrong with this project? What is the worst that could happen? What will we do if it does?

Some risks to watch out for are:

______________

• Schedule slips: That task that you estimated would take three days has just taken three weeks. In a plan-driven project, this can be an issue if you don't have regular status meetings. Waiting three weeks to tell your boss that you're late is always worse than telling her that you'll be late as soon as you know it. In an agile project this is unlikely, because most agile projects have a daily status meeting (see the Scrum meeting section in Chapter 2).
• Defect rate is excessive: Your testing is finding lots of bugs. What do you do, continue to add new features or stop to fix the bugs? Again, this can be a real issue in a project where integration builds happen according to a fixed schedule, say once a week. In a project where integrations happen every day, you can keep up with defects more easily. In either case, if you are experiencing a high defect rate, the best thing to do is to stop, take a look around, and find the root cause of the defects before adding more functionality. This can be very hard to do from a project management standpoint, but you'll thank yourself in the end.
• Requirements misunderstood: What you're doing isn't what the customer wanted. This classic problem is the result of the fact that customers and developers live in two different worlds. The customer lives in the application domain where he understands from a user's perspective what he wants the product to do. The developer understands from a technical perspective how the product will work. Occasionally, these worlds intersect and that's good; but lots of times they don't and that is where you get a misunderstanding of requirements. The best way to avoid this situation is to have the customer on site as often as possible and to produce deliverable products as often as possible.
• Requirements churn: New features, altered features, deleted features … will the misery never end? Requirements churn is probably the largest single reason for missed delivery dates, high defect rates, and project failure. Churn happens when the customer (or your own marketing folks, or the development team itself) continues to change requirements while development is underway. It leads to massive amounts of rework in the code, retesting of baselines, and delay after delay. Managing requirements is the single most important job of the project manager. In a plan-driven process this is usually accomplished by a change control board (CCB) that examines each new requirement and decides whether to add it to the list of features to be implemented. There may be a member of the development team on the CCB, but that's not required, so the danger here is that the CCB will add new features without understanding all the scheduling and effort ramifications. In agile processes, the development team usually keeps control of the prioritized requirements list (called the product backlog in Scrum), and only adjusts the list at set points in the project – after iterations in XP, and after each sprint in Scrum.
• Turnover: Your most experienced developer decides to join a start-up three weeks before product delivery. The best way to reduce turnover is to (1) give your developers interesting work, (2) have them work in a pleasant environment, and (3) give them control over their own schedules. Oddly enough, money is not one of the main motivators for software developers. This doesn't mean they don't want to get paid well, but it does mean that throwing more money at them in order to get them to work harder or to keep them from leaving doesn't generally work. And if, despite your best efforts, your best developer does leave, you just have to move on. Trust me, it won't be the end of the world. The best way to mitigate the effect of turnover is to spread the knowledge of the project around all the members of the development team. Principles like common code ownership and techniques like pair programming work to invest all the team members in the product and spreads the knowledge of the code across the entire team. One of the best books on managing and keeping software developers is Peopleware by Tom DeMarco, published by Dorset House.²

Once you've got a list of the risks to your project, you need to address each one and talk about two things: avoidance and mitigation. For each risk, think about how you can avoid it. Build slack into your schedule, do constant code reviews, freeze requirements early, do frequent releases, require pair programming so you spread around the knowledge of the code, and the like. Then you need to think about what you'll do if the worst-case scenario does happen; this is mitigation. Remove features from a release, stop work on new features and do a bug hunt, negotiate new features into a future release, and so on. If a risk becomes a reality, you'll have to do something about it; it's better to have planned what you'll do beforehand.

Once you address avoidance and mitigation, you'll have a plan on how to handle your identifiable risks. This doesn't completely let you off the hook, because there are bound to be risks you miss; but the experience of addressing the risks you do think of will enable you to better handle new ones that surprise you during the project. If your project is using an iterative process model, it's a good idea to revisit your risks after every iteration and see which ones have changes, identify any new ones, and remove any that can no longer happen.

Resource Requirements

This section is a piece of cake. How many people do you need for the project? Do they all need to start at once, or can their starting dates on the project be staggered as phases are initiated? How many computers do you need? What software will you be using for development? What development environment do you need? Is everyone trained in that environment? What support software and hardware do you need? Yes, you do need a configuration management system and a stand-alone build machine – no matter what process model you're using.

Many of these resource questions are usually answered for you by the platform you're targeting and the application domain in which you are working. That's the easy part. Questions about team size, start dates, and phases of the project will likely not be able to be answered until you do a first cut at effort estimation and scheduling.

______________

Work Breakdown and Task Estimates

The first step toward a project schedule is seeing what you'll be doing and how long each step will take. This is the classic chicken-egg problem. You can't really do estimation until you have a fairly detailed work breakdown into tasks. But your manager always wants effort estimates and schedule data before you start doing the design. Resist this. Make design your top priority once you've got some idea of the requirements. If you select a small set of high priority requirements, and then design a solution for that feature set, then you can do an effort estimation of that iteration. Don't worry that the requirements might change – they will. You need a detailed breakdown of features into tasks before you can do effort estimation.

Don't ever believe anyone who tells you, “that feature will take six months to do.” That is a wild-assed guess (WAG), and bears little to no relation to reality. You just can't estimate something that big. The best you can do is say, “I once implemented a feature like that in six months.” And even that only helps a little.

You've got to get your work broken down into tasks that are no more than about a week in duration. One or two days is a better bet. Even better, never do estimation in any unit except person-hours. That way you'll be more tempted to work with small increments of hours, and you'll break your larger tasks down into smaller ones that you may actually know how to do. Once you have a believable list of tasks, you can start doing size and then effort estimation. Size always needs to come first, because you just can't figure out how long something will take until you have an idea of how big it is.

Size can be several things, depending on your work breakdown and your development model; functional modules, number of classes, number of methods, number of function points, number of object points, or that old standby, uncommented lines of code. Actually, no matter what you initially measure size in, you'll end up with estimates in terms of KLOC – thousands of uncommented lines of code.

There are several techniques for getting effort estimates – COCOMO II [Boehm00], function point analysis, and the Delphi method are just three. All, however, depend on being able to count things in your design. The estimation mantra is size first, then effort and cost estimates, then schedule.

All other things being equal, the Delphi method is a quick and relatively efficient estimation technique. Here's one way it can work: find three of your most senior developers – these are the folks who've got the most experience, and who should therefore be able to give you a good guess. Then give them the task breakdown (assuming they weren't already involved in doing the initial breakdown – the ideal situation). Then ask them to give you three numbers for each task, the shortest amount of time it should take, the longest amount of time it should take, and the “normal” amount of time it should take, all in person-hours. Once you have these numbers, add them all up, the shortest together, the longest together, and the “normal” together and take the mean. Those are your estimates for each task. The averages of the best guess by your best developers for each task. Depending on your personality – and how hard your boss is breathing down your neck – pick one of the three values for each task as the official (for now) effort estimate and proceed to create a schedule.

Finally, you should have the right people – the developers who will do the work – do all the estimates for the project. Managers should never do development estimates. Even if a manager has been a developer in the past, unless one is deeply involved in the actual development work, one should not be in the business of doing development estimates.

Project Schedule

Once you have estimates of the tasks in your first release or iteration and have people resource estimates, you can create a schedule. There are several things to take into account before you can look at that spiffy Gantt chart with the nice black diamond that marks the release date. Here's a list:

• Get your developers to tell you the dependencies between tasks. There will be some tasks that can't start before others finish. There may be tasks that can start once others are half-finished. There will be some that can all start together. You need to know because the task dependencies will push out your delivery date.
• Figure out what your duty cycle is. Out of each eight-hour day, how many hours do your developers actually do development? You need to remember that reading mail, attending meetings, doing code reviews, taking breaks, going to the bathroom, all eat up time. You can't assume that an hour-hour task will be done in a single day. Realistically, out of each eight-hour day, two to four hours are eaten up with other stuff, so your duty cycle can be as low as four hours a day. Duty cycles can vary based on corporate culture, so you need to figure out what yours is before you start to schedule.
• Take weekends, vacations, sick days, training, and slack into account when you're making the schedule. If your senior developer has a task on the critical path of your project, you probably need to know that she's taking that three-week vacation in May.
• You can't schedule a developer to work on two tasks at the same time. Most project-scheduling software will not let you do this by default, but most of them will also let you override this. Don't. You will be tempted to do this so that your schedule does not push out past whatever deadline your manager or marketing team wants, but resist the temptation. You'll only have to change the schedule when you miss the date anyway.

Finally, use project-scheduling software to make your schedule. You don't have to do this, just using a simple spreadsheet technique like the one proposed in Chapter 9 of the Apress title, Joel on Software by Joel Spolsky.³ can work for small projects. But using real project management software like Microsoft Project, Fast Track Scheduling, or Merlin provide lots of features that make keeping the schedule up to date much easier. The big thing that project management software can do that your spreadsheet can't is track dependencies. Joel doesn't understand how Microsoft Project is useful in this; in fact, he says, “I've found that with software, the dependencies are so obvious that it's just not worth the effort to formally keep track of them.”⁴ This might be true for small projects, but when your team gets to be 10 developers or larger and you're working on 100-plus tasks, knowing something about the dependencies of your project can help manage who's working on what, and when. Joel is right in that Project is overkill for many projects, and for those you can use a spreadsheet approach that just lists the features and tasks you can see right now (see Table 3-1); but project management software sure is handy to have around when you need it.

______________

Spolsky's painless schedule lists the following seven columns that should be in every schedule:

• Feature Name
• Tasks within the feature
• The Priority of the Task
• The Original Estimate (in person-hours)
• The Current Estimate (in person-hours)
• The Elapsed Time worked on the task (in person-hours)
• The Remaining Time on the task (also in person-hours)

Joel correctly emphasizes that tasks need to be fine-grained and small in terms of effort. Otherwise, as noted previously, your estimates will most likely be wildly off. He also suggests that each developer either has a separate spreadsheet, or, as shown here, you add an eighth column with the developer assigned to the task. Having all the Tasks on the same sheet makes it more crowded, but easier to see all the tasks at once. While not exactly “painless,” this method of keeping a schedule is useful for smaller projects with a fairly limited number of tasks.

I suggest adding a ninth column to measure the velocity of each task. Velocity is a term from XP⁵ and is defined as the estimated effort of a task, divided by the actual effort. In our case, we'd use the Original Estimate of the task and the Elapsed Time. If you overestimate your task, your velocity will be greater than one (your task took less time than you originally thought); if you underestimate, it will be less than one (the task took you longer than you originally thought). Ideally, your velocity should be 1.0, but that hardly ever happens.

The reason for using velocity is to give each developer and the project manager an idea of how accurate the developer's estimates are and to help do a better job of estimating next time. Ideally, as a developer gains experience, her velocity will approach 1.0 on each task. Alternatively, if a developer's velocity jumps around a lot (one task is 0.6, another is 1.8, a third is 1.2), then a crash course in estimation techniques might be appropriate. In my experience, a new developer's velocity will start out gyrating wildly, with most values well under 1.0 – the new developer is overly optimistic. But as time goes along velocities will settle into a range centered on 1.0, maybe from 0.85 to 1.15. As a developer gains a history, the project manager can then start to depend more on their estimates, and the schedules will be more accurate.

______________

Project Oversight

Project oversight is what happens once you've got a schedule. Once your project begins, the work needs to be managed. How this happens depends on the process you're using. But regardless of the process you need to manage the schedule, manage the developers, manage the process itself, and above all, manage your manager.

A manager's technique is critical to keeping a project on schedule. Fear is not a motivator. Appealing to professional pride is, though. If your boss doesn't support you, you're doomed.

Without creative, supportive management, you're doomed. If your people aren't happy, you don't have a hope. Treat your developers as humans, not resources. Supporting your team and keeping them insulated from distractions is your number one job. Remember, projects are cooperative, social events.⁶

Status Reviews and Presentations

Status reviews and presentations are an inescapable part of any project. The bigger the project, the more formal the review. Remember that reporting status doesn't fix problems, and that generally upper management doesn't like hearing about problems. Tough. When you give a project status report just tell 'em where your project is and where it's going during the period before the next status report. Don't embellish and don't make excuses; be honest about problems and where you are in the schedule. Just providing good news is usually bad for your reputation; something will go wrong at some point, so it is best to get it out of the way right away. You must communicate bad news about the project as soon as possible. That's the best way to mitigate the problem and get others involved in helping to find a solution.

When giving a presentation, be it a status review or a technical presentation, make sure you know your audience. Set your presentation to the level of the audience and keep the purpose of your presentation in front of you and them at all times. PowerPoint is ubiquitous in industry so learn to use it effectively. Keep your PowerPoint presentations short and to the point. Avoid cramming your slides with lots of bullet points. Do not make your bullet points complete sentences, mostly because you'll be tempted to read them. This is the kiss of death for two reasons: it takes too long and takes attention away from what you're actually saying.

It insults the audience. Surely they do know how to read?

Your bullet points should be talking points that you can then expand upon. This lets your audience focus on you, the speaker, rather than the slides. When you're constructing a PowerPoint presentation, use as few words as you can.

______________

Defects

Inevitably, you'll introduce defects (errors) into your program. Defects do not just appear; developers put them there. As a developer, your aim is twofold

• Introduce as few defects as possible into the code you write.
• Find as many of them as you can before releasing the code.

Despite your best efforts, though, you will release code with defects in it. It's just inevitable. For a program of any size, there are just too many possible paths through the program (called a combinatorial explosion), and too many different ways to introduce bad data for there not to be defects. Your objective is to release with as few defects as possible and to make those defects ones that don't really impact the product or its performance. To make this a reality, most development organizations have a set of defect levels they use to characterize just how bad a defect really is. One set of levels looks like the following:

1. Fatal: Either this defect causes the product to crash, or a fundamental piece of functionality doesn't work.
2. Severe: A major piece of functionality doesn't work, and there is no workaround for it that the user can perform.
3. Serious: A piece of functionality doesn't work, but there is a workaround for it that the customer can perform.
4. Annoying: A minor defect or error in the documentation that may annoy the user, but doesn't affect how the program works.
5. New Feature Request: This isn't a defect, but a request for the product to do something new.

Whenever you find a defect in a piece of code, you will file a defect report (to keep track of how many defects you're finding, what types they are, and how severe they are), and you'll characterize the defect by severity level. When the developers are fixing defects, they start at level 1 and work their way down.

In nearly all organizations, no product can release with known level 1 or level 2 defects in it. Most organizations also try their best to remove all the level 3 defects as well.

The Post-Mortem

Most development teams will do a post-mortem after every project. A post-mortem is an opportunity to reflect on the project just completed and answer a few questions. Typically, the questions will be like the following:

• What went right? Did our process work the way we anticipated? Did we meet our schedule? Did we implement all the features required by the customer?
• What went wrong? Why did we have so many defects? Why did we need to work 60-hour weeks for the last month of the project?
• What process issues came up? Did we follow our process? If not, what parts were problematic?
• What do we need to fix for next time? Given questions 1, 2, and 3, what do we need to fix in our process, work habits, or environment for the next project?
• Who is responsible for the fixes? Someone has to be responsible for the changes to our process; who is it? (Don't make it a manager; the development team should own the process.)

Conclusion

So where do we end up? We've gone through the general parts of managing projects and presented some alternative ways of doing project management. The most important parts are the developers should own the process and management should be supportive and listen to the developers – particularly where schedules and estimates are concerned – and be the buffer between the developers and the world. If you can work in an organization where those things are true, be a happy camper, because you'll be able to write great code.

References

Beck, K. Extreme Programming Explained: Embrace Change. (Boston, MA: Addison-Wesley 2000.)

Boehm, B., C. Abts, et. al. Software Cost Estimation with COCOMO II. (Englewood Cliffs, NJ: Prentice-Hall, 2000.)

Cockburn, A. “The End of Software Engineering and The Start of Economic-Cooperative Gaming.” Computer Science and Information Systems 1(1): 1 - 32. (2004)

DeMarco, T. and T. Lister. Peopleware: Productive Projects and Teams, Second Edition. (New York, NY: Dorset House Publishing Company, 1999.)

McConnell, S. Rapid Development: Taming Wild Software Schedules. (Redmond, WA: Microsoft Press, 1996.)

Spolsky, J. Joel on Software. (Berkeley, CA: Apress, 2004.)