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


1 Comment

Preventative Medicine for the Information Technology Project

By Phil Smith

It is always wise to use preventative measures to keep your IT project on track.  Assigning a great project manager, utilizating formal risk management, utilizating of a system development process with tollgates, and implementing health checks are all examples of proactively working to keep things on track.

In this article I will discuss a few simple points to consider regarding the use of health checks for your project. A health check is a valuable tool for any project manager or business consultant.  I welcome readers to respond back with additional thoughts or counterpoints.

Definition of a Health Check

While I’m open to other definitions, I need to capture at least a basic definition here to support the remainder of the article.

Health Check:  An independent, unbiased review of the condition of a project. Ideally multiple health checks will be executed at various points in the project, with each one focusing on appropriate, critical success factors for the project, and appropriate critical maturity factors for the organization.  The scope of a health check should be limited to a preset questionnaire that is designed to help the project and the project manager.  Results should be reported in the context of degrees of compliance with required and recommended process steps.  Results should also capture corrective follow-up steps, and should highlight risks and/or issues that require attention from the PM. Continue reading


4 Comments

Ailing Projects: Should PM’s Treat the Symptoms, or the Root Cause?

by Phillip Smith

In my previous article I wrote about IT projects experiencing trouble, and separated the symptoms from the root causes. Doctors sometimes treat symptoms, and sometime they treat root causes.  Other times they treat both or do nothing at all. In this case, the project is the ailing patient, and the specific medicines that a project manager chooses to administer—and when—is largely a matter of style.

Some project managers are comfortable allowing a certain amount of churn to take place before they step in, while others work in a more hands-on mode. If the project team is seasoned and is using a mature development process, the PM can afford to allow that team space and time to work through problems without having to personally drive a resolution for each problem.  There is a balance between empowering the team and being so distant that you appear to be “checked out”.  Find that balance (it will vary by project and by team) and use it to your advantage.  Teams that work independently within a process set tend to accomplish a lot –  and they tend to have great morale when they are productive and know they have a PM who will drive resolution for issues when they need that kind of help.

While I’m willing to admit that the PM has a right to bring a certain amount of style to their approach, I’m also willing to make a strong argument that various situations call for certain “medicines”.  In the last article I listed classic symptoms of a project being in trouble. One of these was “high defect rate.”  We can use that as an example of a situation that calls for specific action. Continue reading


2 Comments

Project Management or Project Meteorology? Forecasting, Monitoring and Prevention Measures to Stop “Bad Weather” Before it Happens

by Phillip Smith

Project planning is an exercise in forecasting.  The idea is to take the variables you can account for and try to anticipate any issues that might rain on (or dry up) your project’s progress toward a smooth conclusion. Forecasts are rarely perfect, which is why we have project managers still assigned to projects even after the plans are built.  We need the PM’s there to lead teams through time and change and keep the project in scope.

That’s why the real mark of a good PM is discernment on the fly. PM’s, while leading their teams, must be able to distinguish the difference between normal variation from plan and real trouble–and be able to recognize the difference between the two in time to mitigate and control.  Sometimes re-planning is required, but the goal in most instances should be to return to the original plan whenever possible.

So how do you know the difference between normal variation and real trouble in a project? A textbook answer would involve the use of metrics plans.  If defects (severity, volume), schedule variation, budget, or productivity reach beyond established thresholds, then corrective action must be taken. The metrics required to monitor the project are expensive, and we don’t all have them available to us. So many PM’s are working without formal metrics, and must diagnose real trouble before it is too late.  Fortunately, there are some general rules of thumb. Ailing projects have some common symptoms, many of which formal metrics account for and an observant PM can easily identify. Here’s what to watch for:

Classic Symptoms of an Ailing Project
Scope unstable
Missed deadlines
High defect rate
Unexpected costs, or lack of expected costs
Low team morale or other HR issues
Nervous client
Budget problems

Continue reading


1 Comment

Project Management Survival Guide Part II: Three Ways to Stay Clean While Doing the “Dirty Job” of IT Project Management

by Phillip Smith

Last week we talked about the dirty job of project management, and how the complexities involved in leading teams and implementing IT projects often make the PM’s job even messier than Mike Rowe on a sweeps week episode of Dirty Jobs.

Luckily for us, there are three tried and true guidelines for cleaning up even the messiest project—or even better, keeping it in check before things get out of hand. Here they are:

  1. Stabilize requirements and schedules
  2. Set up repeatable processes and tasks
  3. Allow team members to develop specialized skills that can be called on as needed.

1. Stabilize requirements and schedules

Stabilizing the requirements and the schedule is about managing the stakeholders.  It’s an art form that requires patience and understanding, and the good sense for compromise and protection of the project team.  If you lose too many battles here, the project may be successful, but you won’t have a team left to execute the next project.

2. Set up repeatable processes and tasks

Setting up repeatable processes and tasks is all about maturing the project team.  While every project is unique, the execution is not.  For example, there is always a design document.  Use the same template every time.  Use a reliable review process with team members who have the right knowledge.  Hold the design to a high quality standard, schedule enough time into the plan to do it right, and execute this way on every project so that all team members understand the expectation. Continue reading


3 Comments

Project Management Survival Guide Part I: Why Managing an IT Project is Different from Managing a Non-IT Project

by Phillip Smith

If you’ve ever watched an episode of Dirty Jobs then you’ve seen Mike Rowe get up close to some type of difficult and risky task. He usually reports on a sensationally dirty, greasy, goopy process that leaves him in need of a bath. While I suspect that he’ll never create an episode about IT project management, those of us in the industry know a dark secret: every day, we’re at risk of being slimed.

As IT project managers, we face risk and issues head on, often leading unproven project teams through difficult times to meet objectives set by a client with a limited timeline and budget.  We negotiate, we coach, and we deliver bad news.  We drive our teams like cattle and defend them like our firstborn.  We gather data that points to frightening conclusions, and then challenge ourselves to overcome.  We follow detailed processes and also make time for the soft stuff necessary to keep leadership, people, and clients synchronized. We’re surprised with ever-changing expectations, unforeseen expense, and impromptu meetings.  We travel, we sacrifice, and we deflect credit to the people that did the “real work”.

And when we tell our kids what we do for a living, they tilt their heads sideways and say something inspirational like “huh?”

At this point a sane person would ask, “Why do we do it?”  I’ll save that answer for a different article on a different day.  Instead, I’m going to explore some of the reasons this job is so demanding compared to other industries, and next week I’ll give you some suggestions for getting through its unique challenges. Continue reading