1 Comment

How to Lower Your Defect Rate Using Simple Requirements Techniques

By Chris McIntosh, Senior Software Developer

Chris McIntoshWe have all seen the various studies of software development and the causes of failures to deliver on time and cost overruns. The original Chaos report stated that a mere 16.2% of projects finished on time and budget. There have also been numerous studies surrounding the cost of defects and how it varies depending on when in the lifecycle they are discovered. The consensus, first reported on by Barry Boehm in the 80’s, is that the later in the software process a defect is discovered, the more expensive it becomes. There is some debate as to whether or not this is a hard and fast rule, but suffice to say, defects are rarely free to fix. Agile has cropped up to try and address some of these issues. It has certainly helped. A more recent report on software project failures puts it at 50% – 70% of projects are finishing on time and budget, with the projects using more agile techniques in the upper end of the spectrum. Agile practices are successful in reducing the failure rate by, in part, making the team test the development more frequently and elicit requirements more often. This is wholly dependent on your team’s ability to gather, record, and test requirements efficiently.

Here are some simple techniques that you can slowly introduce to decrease the defect rate due to poor requirements.

Continue reading


Leave a comment

Minimizing Risk in an Agile Approach

by Phillip Smith

The discussion about which project management approach to use is irrelevant if the chosen approach is not implemented correctly. The IT industry, while relatively young, does have reasonably well thought out software development processes (SDP’s) that are mature and reliable. Taking shortcuts within an SDP is never a good idea.

Whether using agile or waterfall, always make sure your plan includes stable requirements, optimized design, and rigorous testing. You should never tailor out critical deliverables, breeze conditionally through tollgates, or attempt to support truly impossible timelines.  It is better to execute in a reliable and true fashion and finish the project the right way, with quality. Stated another way, project managers should never use a difficult timeline or a low budget to justify chaos.

For example: in an agile approach, if you start with a very large scope and parse it into smaller components, and then execute all of the SDP phases for a single component prior to going in to the requirements for any other part of the scope, you will be running a great risk.  The lack of definition of follow-on components, combined with the finality of having the first component implemented, will certainly lead to integration issues and rework.

Continue reading


1 Comment

Agile Development or Traditional Waterfall Approach?

by Phillip Smith

Our clients rely on us, their IT team, to move them to a future state of better technology, better business process integration, and stronger competitive advantage. Our challenge is to get them there as quickly and inexpensively as possible.

Facing up to that challenge means that IT organizations must look for better ways to do things.  New efficiencies can be found in many areas: staffing, training, monitoring of status, cost, tools, planning, and the list goes on. But here I’ll address the “approach”—specifically, the decision of whether to use waterfall or agile in the organization of your project events.

Project managers should avoid any personal bias toward waterfall or toward agile. Every project is different, and some will fit better with waterfall while others will fit better with agile.  The decision is no different than deciding whether to use a hammer or a screwdriver: you need to know what problem you are solving, and then reach for the correct tool. Continue reading