Improving Requirements Quality with Use Cases

People sometimes like to dive right in to requirements definition by simply starting to write them on a blank sheet of paper – or blank Word doc for those of us who have gone completely green. Starting the requirements definition process this way can be very intimidating at best and full of oversights, omissions, and conflicts at worst. Even if you define and document scope in detail as I’ve discussed in the past, it’s still a big leap from a scope document to detailed requirements. Customers often have a hard time with requirements and you certainly can’t write all the requirements for them. You can help … but be sure to bill for it.

Sample ATM system usage use case diagram

Use cases are a simple, cost-effective way to build a consensus among stakeholders and to discover missing requirements. They tend to address two large classes of requirements errors – omitted requirements and conflicting requirements. While drilling down further into requirements, the customer – usually with your help – can utilize use cases to get detailed requirements across all life-cycle phases to support the requirements definition process.

Why develop use cases?

Use cases are relatively easy to generate. The customer must access their stakeholders and subject matter experts (SMEs) to get well-thought out use cases that can be used to derive detailed and meaningful requirements for the engagement. Below are some of the reasons and pluses for generating these use cases: Read more »

Good Requirements vs. Rework

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from Hooks and Farry’s book entitled, “Customer-Centered Products.”

“Better, cheaper, faster!” “I want it yesterday!”

Everyone out there has heard one or more of these – how and when you’ve heard them depends on your industry. But they translate into the same headaches for everyone. If you are a product development manager, you must develop and deliver higher quality products in less time and for less money than you have in the past. If you are in charge of procuring products for use in your company, you must procure a quality product faster and cheaper than ever before – especially in this economy. Otherwise, you may not be able to stay in business. Read more »

Communicating Project Scope

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

The Scope Document

Once the project scope is defined, it must be documented to ensure that everyone assigned to the project will address the right tasks and work toward the same project goals. A formal scope document is essential to keeping a project on track. The order that these scope items are covered and the amount of space devoted to each in this document will depend on the type and size of the project and the number of scope items that need to be covered. On small projects, needs, goals, objectives, and missions will often be the same thing – easily described in a few statements. Distinguishing between these things is not that important, but establishing a flow from less measurable statements of need to more measurable ones truly is important. Read more »

Maintaining Project Control

This post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

Information for this article is based on a section of Eric Verzuh’s book entited “The Portable MBA in Project Management.”

The Control Process

The project control process is designed to spot problems early, while they are still small enough to correct. It is an iterative feedback loop in which the project manager uses measurement and testing to evaluate deviations from the plan as to cost, schedule, quality, and risk. These deviations may or may not result in corrective action. The key is to monitor closely enough and often enough to spot such deviations before they get out of control. There are five steps in the project control process: Read more »

Estimating Project Effort and Cost

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from “The Project Management Question and Answer Book,” by Michael Newell and Marina Grashina.

As part of your project management responsibilities, estimating the effort and cost on the project is going to be something you’ll have to do from time to time. Sometimes that will all be decided up front by sales and the customer and there won’t be much you can do about it. However, there will be times…hopefully…where you’ll get some solid input to the estimation process – especially on change orders.

In order to run the project you first need to know how long things take, how much they will cost, and what kind of resources will be required. The only way you can get this data is by doing good estimates. Without good estimates you really have no way of knowing where you are at any point in the project, and you have no way of predicting how much the project will cost or how long it is going to take to do it.

A project estimate is the determination of the effort it will take to achieve a desired result. There are two major things that we estimate in a project; one is the cost of the project or the money that will have to be spent to produce it. The second is the time that the project will take to be completed. Whenever we are doing project estimates, we will not only be estimating the cost of doing the work but also the time that it will take to complete it.

No one said project management is easy – and likewise there are many pitfalls in producing a good estimate for a project. The deliverables may not all be identified, key project supports change their minds, project team members may be optimistic or pessimistic, time may be limited, and so forth. If the project is poorly defined, there is not much of a possibility that the cost and schedule estimates are going to come out anywhere near what the actual cost and schedule time for the project will be.

Project management is about realistic expectations. Therefore, overly optimistic schedules can cause problems in estimating as well. Stakeholders or management frequently shorten schedules without adding budget to the project. Generally we can look for increases in cost when schedules are shortened. An inaccurate work breakdown structure causes work tasks to be missed. When the individual estimates for the tasks are added up to make a bottom-up estimate for the project, missed work tasks cause underestimation which can severely affect the budget. Understating risks underestimates our cost and schedule estimates as well. Risks that are not identified and identified risks that have the wrong value for their estimated probability or impact cause management reserves and contingency budgets to be misstated. Cost inflation and failure to include appropriate overheads cause erroneous estimates. It is important to recognize wage and price increases that will occur during the project and adjust estimates accordingly.

Summary

Project estimation is a skill that comes from experience. However, even the most inexperienced project manager can produce good estimates. Look to your skilled team resources and management to assist and make estimates with confidence. And don’t be afraid to adjust estimates as your project moves along and you gain more knowledge – your project budget will be healthier for it.