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:

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“