You've got a great idea for the best product since the invention of the computer. You have your development system fired up and ready. You have the system design all roughed out, and the team is champing at the bits and bytes to start coding.

Even the boss has caught the excitement, and wants to know when he can get his hands on this software marvel that will naturally haul in the big bucks.

When? Um ... well ...

How do you figure it out? How do you keep the project on track? How do you make sure you deliver not only a red-hot product, but a product that's on time and on budget? With no bloodshed or tears?

While computer science curricula typically are strong on topics such as computational design, algorithms and programming in several languages, mundane things such as project management tend to get, at best, a cursory glance. And those of us who learned via the "throw them to the alligators" technique have even less grounding, just ad-hoc experiences to fall back on.

Author Johanna Rothman specializes in IT project management, and her latest book, Manage It! Your Guide to Modern Pragmatic Project Management, speaks directly to the IT pro.

Corporate management, in many cases, would not be pleased.

For example, she discusses the common misconception that project managers and their teams can juggle several projects without a performance penalty, noting that multitasking can waste 20 – 90 percent of your time and is the single biggest contributor to late projects. And she offers strategies for those times when the boss keeps bouncing you from project to project, with the result that nothing is getting done on anything.

But that’s jumping into the middle of the proceedings. The book actually starts at the very beginning, defining a project ("a novel undertaking or systematic process to create a new product or service, the delivery of which signals completion. Projects involve risk and are typically constrained by limited resources"), and what a project manager does ("a project manager is the person whose job is to articulate and communicate what 'done' means, and to guide the project team to 'done'".)

After sorting out a bit more terminology, Rothman begins her guided tour by illustrating how to ferret out the drivers and constraints of a project. And if you don't know what those two terms mean, don't worry about it. Rothman puts them, and many other project management terms, into context and explains their significance.

One thing she doesn't do is nail you down to a specific methodology (although she does say that "code and fix" as a project plan is a no-no). Each project is different, and lends itself to different development lifecycles, and she describes where several of them fit.

Then she explores the many challenges in putting together an effective project team, and offers advice on how to get its members to work together.

Scheduling a project is another big chunk of work, and Rothman talks about ways this can be accomplished. A special favorite is using a wall, a few pads of sticky notes and a fistful of pens. Tasks are written on the notes and placed on the wall. "It's easy," she said, "to write a task on a sticky, put the sticky up on the wall, and discuss with the rest of the project team – sometimes quite loudly – the sequence of tasks or who will do them or what the risks are. And if the task is in the wrong place – because the team sees another way to organize the project – it's easy to move the sticky from one place to another."

She doesn't completely dismiss electronic scheduling tools, mind you; she just points out their many shortcomings.

One chapter that's a must-read is called "Hope is Our Most Important Strategy". It presents a menagerie of types of bosses who are roadblocks to the development process, and makes suggestions on how to cope with them.

Getting to done means measuring progress – otherwise, how can you tell how close you are – and there's a whole lot of advice on useful metrics and how to present them. If there can be only one, Rothman recommends the Velocity Chart, a line graph whose x-axis shows dates, and whose y-axis shows feature counts. There are three lines on this graph: total features, features completed, and remaining features. It's simple, and you can see where you are at a glance.

Rothman move through the entire development cycle, discussing managing interruptions, running meetings, handling testing and, yes, knowing when it's time to leave because you're being set up to fail.

This is not a manual that will get you project management certification. But it is a sensible, down-to-earth look at managing programming projects from someone who has managed a whole lot of them. It's sprinkled with real-world examples of problems and their solutions, from Rothman and many other project managers, and it's written in an easy-to-read, approachable voice (if you want more formal dissertations, Rothman includes a five page list of reference material).

It's staying on my bookshelf.

The book is available either as hard copy or in a PDF e-book from here. There's also a downloadable set of project templates on the site.