Four Characteristics of a Good Requirement

The quality of your requirements can make or break your project.  Good requirements give you control over your project development and prevent rework. Less rework means your project has a much better chance at on time and on budget delivery.  All that adds up to project success and high customer satisfaction.

What makes a requirement a good requirement?  Good requirements generally meet four basic criteria:

• Good requirements meet a specific need
• Good requirements are verifiable
• Good requirements are attainable
• Good requirements are clear

Let’s look at each of these in more detail…

Meeting a specific need

A requirement is a basically a statement of something someone needs.  The something is a product or solution that performs a service or function.  The someone may be a company, a user, a customer, support, testers, or another product.

For example, a company needs a manufacturing machine that stamps out widgets, or they need a certain plastic to feed a manufacturing machine that they already have.  A bank must process debit card transactions.  Alternatively, a requirement is a statement of a characteristic of something someone needs.  Proceeding with these examples then, a machine must stamp out 60 widgets an hour.  The raw material must be formed in sheets, or it must be red in color.  A bank must process at least 1,200 debit card transactions in one hour.

Read more »

How Do You Go About Prioritizing Requirements?

Whether you are on the customer side managing requirements or on the delivery side managing the development of the solution or product, you need a simple method for realizing the benefits of prioritizing requirements.  Formal prioritization methods do actually exist, but most projects don’t really need an investment in a formal process.  Sometimes a mindmapping tool like Seavus DropMind can prove beneficial, but it depends on the project and how much definition has already gone into the requirements at this point. The benefits of prioritization have to exceed the cost of actually doing it.  Large complex projects may prove a formal process to be beneficial, but for the purposes of this article, I won’t go into that depth or make that assumption.

Most projects can enjoy the benefits of requirement prioritization by following a simple five-step process:

1. Define priority classes
2. Classify the requirements
3. Resolve the differences
4. Create priority-based development schedules
5. Maintain the priorities

I will expand on each of these….

Define Priority Classes

Keep them simple.  A numbering system of 1-2-3 works very well.  Number the essential, non-negotiable, and urgent requirements with priority 1.  Assign priority 2 to the useful, negotiable, or slightly deferrable requirements.  Save priority 3 for merely desirable, flexible, or “someday” requirements.  Educate all stakeholders – internal and external, customers and developers – on the prioritization scheme.

Read more »

Getting Stakeholders Onboard with Requirements Prioritization

Defining requirements is all about communication between customers, project managers, and developers.  Requirement priorities improve communications between these main parties.  The payoff is not obvious to everyone, however, and you will probably have to sell the concept of prioritization to your stakeholders.

Customer resistance

An external customer is probably the hardest stakeholder of all to sell on the concept of prioritization.  Customers have difficulty with the concept.  Requirement prioritization on the surface may appear to the customer to be of primary benefit to the developer, thus leaving you with a tough selling job on prioritization to the customer.  Many customers initially view a request to prioritize requirements as a backdoor way to reduce the number of requirements and they are very reluctant to do that.  A prioritization effort involving both the customer and the developer perspectives will separate essential from desirable, needs from wants, in a way not possible from only one side’s perspective.  The customer may decide to drop the low-priority “desirables” after such a review.  The customer may actually reach this conclusion on their own and that’s a good thing, though the overall project budget and timeline may need to be changed – elimination of requirements would require a change order or series of change orders.

Read more »

The IT Auditor’s Role in the Software Development Process

In further examining the IT Auditor’s role in the IT project environment, I’d like to look at how the book “Information Technology Control and Audit” discusses the IT Auditor’s role in the overall software development process.

Software Development Process

A formal systems development process provides an environment that is conducive to successful systems development. This includes: (1) an information systems strategy that guides developers in building systems that are consistent with the organization’s technical and operational goals, (2) standards that guide in the selection of hardware, software, and developing new systems, (3) policies and procedures that support the organization’s goals and objectives, and (4) project management that ensures projects are completed on time and within budget. Auditors can assist organizations by reviewing the systems development process to ensure that developed systems comply with the organization’s strategy and standards.

Software Development Phases

The systems development process can be broken down into four phases:

• Planning
• Development
• Implementation
• Maintenance

The planning phase sets the stage for the success of the development effort. If not done properly, the budget and schedule may not be sufficient, the problem may not be adequately defined, the final project may not solve the business problem, and the right people may not be involved. The planning phase of systems development includes the following activities:

• Needs analysis: a study to determine whether a new system should be developed
• Current system review: a study of the current system to identify existing processes and procedures that will continue in the new system
• Conceptual design: preparation of the proposed system flow and other information illustrating how the new system will operate
• Equipment requirements: hardware configuration needed to process and use the new systems (e.g., processing speed, storage space, and transmission media)
• Cost/bene?t analysis: detailed financial analysis of the cost to develop and operate the new system, the savings or additional expense, and the return on investment
• Project team formation: identify people from programming, user departments, and support departments to develop and implement the new system
• Project plan: an overall project plan with defined tasks and deliverables to monitor actual results and ensure successful progress

Auditing can be involved in the planning process to develop an understanding of the proposed system, make sure time is built into the schedule to adequately define controls, and verify that all the right people are involved.

There is a definite correlation between a well-managed systems development process and a successful system. The use of a proven system development methodology increases the probability that the system’s internal controls will be effective and reliable. As discussed under the traditional development approach, systems development includes the following phases:

• Analysis: Define what is required of the new system.
• Design: Define how to build the new system to satisfy the requirements.
• Construction: Build the new system using the design information.
• Testing: Verify that the completed system meets the users’ needs and functions without fault.
• Implementation: Deliver the completed system to the end users; obtain satisfactory feedback.
• Maintenance: Modify the system as needed to correct problems or meet changing needs.

Auditing can review the development process to ensure the software is designed with user requirements documented, that management approves the design, and that the application is tested before implementation. An additional focus is ensuring that the end user is able to use the system based on a combination of skills and supporting documentation.

Don’t Kill Your Customer – It’s Bad for Business

Whether you are a project manager working in a large corporation with a PMO, or a PM-inclined individual in a smaller company thrown into the PM role, or a skilled consultant recruited by any sized organization to lead critical initiatives, you’re going to run into customers who drive you absolutely crazy.

I’ve discussed in previous articles some negative things about customers. These aren’t surprises to the experienced IT veteran. Usually the customer does not have the necessary expertise or knowledge that is needed – otherwise they wouldn’t be customer and they wouldn’t be coming to us for their project. Whatever it is – there is some need and they’ve come to you specifically, or your company in general, to fill that need.

If you come from a software development background then you know the attitude I’m talking about. It’s easy to put yourself above the customer and talk down to them. You need to both avoid coming across as knowing more than they do while at the same time resisting the urge to throttle them when they can’t seem to get a grip on what it is they really need and what you’re trying to do for them.

Customer Service

While customer service may not really be in the job description of most software developers and other key members of your project delivery team, it is a key responsibility of the project manager. The PM is the face of the company to the customer and the first point of contact for issue resolution during the project engagement process…and sometimes for a period of time following deployment. How you respond to that customer may mean the difference between ongoing revenue from them in the form of add-on business and change orders and a work stoppage on a project if they feel like they’re being treated like second-class citizens.

An Example of Bad Customer Service

I had one customer where my team was performing an enterprise software application configuration and rollout. It was, of course, one of five or six projects I was running at the time and one of three or four projects that most of my team members were involved with also. I had a junior business analyst on the project and a senior business analyst – supposedly the junior was being mentored by the senior. What actually was happening, though, was all the work being performed by the junior and no oversight by the senior.

What resulted was a functional design document that was full of errors – even easy typos – and it took four or five iterations to get it cleared up. At that time, peer reviews of documents like that were performed by position peers – meaning the senior BA was supposedly reviewing the document…but that never happened. Policy changes following this fiasco meant that peer reviews were performed by the whole team (something I personally should have required anyway as the PM…lesson learned, definitely).

What the customer saw, however, was a bad document being delivered to them repeatedly and they then realized that the senior BA was too busy with other critical work to be involved in the project. They actually had to state that they felt like they were being treated as a second-class project. Wow…I ended up with a lot of damage control on my hands.

The Lesson

The lesson here is to be proactive when these situations arise and correct the problem before the customer feels that they’re not high on your priority list. They know you have other work to do, just don’t make them feel like they’re at the end of your list. Your customer came to you out of need and because they lack the skills, resources and probably time to perform what you and your team can perform for them. Understand their need, work with their weaknesses and help them to fully understand the solution. You’ll end up with a very satisfied customer and likely a long-term customer.