Better Software Conference + Agile Development Practices Conference

As we strive to deliver better projects to our customers, I am more and more intrigued by Agile development processes.  Luckily, I’ve been granted a media pass to both the upcoming Better Software Conference and the Agile Development Practices Conference here in Las Vegas.  For the first time ever, these two agile-focused conferences are co-located and one admission (or media pass) gets you into both conferences and their associated expos.

These conferences will be held in Las Vegas at Caesar’s Palace June 6-11.

Key reasons to attend the Better Software Conference and the Agile Development Practices Conference are to:

• Discover the latest in software development, agile software development, technologies, trends, and practices.
• Network with hundreds of your peers to problem solve, collaborate, and gain fresh ideas.
• Enjoy opportunities to meet with the speakers throughout the week.
• Benefit from real-world experiences of leading software development organizations.
• Attend the EXPO for the latest tools and services to help you build and deliver better software.
• Engage with summit participants in thoughtful discussions about leadership at the Agile Leadership Summit.

Since I’ve never worked for a company who utilizes agile development processes on the product development activities or on their projects, I’m hoping to gain useful insight and understanding on these practices and share them with our readers.  As a project manager, I also plan to take away what I learn and use these concepts to both better manage my projects and to work with the development staff and my clients to provide them with better built solutions in the end.

The full conference including all sessions from both conferences runs from June 6 through June 11.  Certification training will be offered and both conferences include many key note addresses, useful classes and numerous working sessions and panels.

Read more »

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.