Archive of Project Management Articles

You expect analysis to happen before design, and both to happen before implementation and testing. But how much should these activities be staggered? When a project is being run with monthly releases, it might seem logical to have each group working on a different release. For example, the test team working on the current release (3), the developers on the next release (4), and architects and analysts working on releases 5 and 6 respectively.

If your team is this staggered, you have a problem. It takes four months for a requirement to be released from the time the analyst has documented it.

When you plan a release, agile user stories, or classic use cases are the best sized pieces to use in the planning - from the perspective of your customers. Each user story can be further decomposed into a set of specifications, and those into development tasks. Development tasks are the right sized unit to manage your work breakdown structure - communicating the release schedule internally with your development team.

But sometimes, it happens anyway.

The Cranky PM started a great thread of conversation asking how product managers deal with the job of telling customers (and sales folks) that a feature is not going to be available in the promised release.

Jonathan Babcock has written a couple interesting articles on preparing for a review meeting. He touches on a couple generic “good ideas” and explores one critical idea in more detail. We focus on that detail - helping participants be prepared to participate - in this article. His articles, and this topic in general are useful to anyone who runs meetings that require participation from attendees - business analysts, product managers, and project managers, for example.

To define the boundaries for our agile project, we need to define the scope. To provide a guiding framework for the rest of the work, we need to document the vision. We could create heavy-weight scope documents and vision documents. And we could run them through reviews and get approvals and wordsmith them to death.

But we won’t. Agile processes are about documenting enough, not documenting for the sake of documenting. This is a small project with an even smaller team (one person right now - but that will grow as people start helping out). An informal documentation style will be sufficient. The key element is to have something referenceable and mutable. If we can’t change the scope or the vision based on market feedback, we aren’t being agile.

These two project management artifacts seem logical to combine into a single article

Leading Answers, an agile project management blog, has a great article that details some agile techniques for release planning exercises. Their article includes explanations and great diagrams.

One of the goals of agile software development is to deliver value quickly and iteratively. One of the most effective ways to begin the software development process is with use cases. To deliver with agility, you start with the most valuable use case, bang it out, and then move on to the next most valuable use case. How do you know which use case is the most valuable if you haven’t defined all the use cases first?

Writing Complete requirements is one of the twelve elements of writing good requirements. Sometimes, you don’t have the opportunity to finish the job, and are forced to write incomplete requirements. How would you go about doing that?

You write use cases to define the scope of your project. Use cases describe what people are using your product to accomplish. Use cases provide a framework for defining the details of the product. You can estimate your project effort with use cases. But you have to write the use cases at the right level of detail.

Johanna warns us that there is “no such thing as percent complete” when it comes to tracking status on a project. Your managers and customers want to know percent complete - and there is a way to report it. Project planning and scheduling involves walking this fine line.