Manage the project, not MS Project.

July 2008

One of the things we observe too often in our engagements is quality being adversely impacted by seemingly reasonable project management decisions. We are not talking about the obvious quality-killers of tasks with impossible time frames or inadequate resources (dollars or people) for the amount of effort required. Rather, there are decisions that a PM makes during the project that sound good at the time but have serious impact on the testing and delivery phases. Let’s look at three examples:

Switch to iterative. Sometime during design and coding, the PM decides to deliver code to the test team in several iterations rather than as a single release. Makes sense to the developers, but it adds a major burden to the testing. Now for each iteration, not only must the new functionality be tested, but functionality delivered in previous iterations must be thoroughly regressed.  Before switching the delivery strategy, the PM needs to understand and account for the impact on regression testing.

Assumptions. Every project estimate and plan comes with assumptions.  Assumptions are to be managed, not assumed. We see too many cases where test schedules are based on important assumptions about specifications, test environments, or test data. The PM fails to ensure these assumptions hold true, then is surprised when the test effort is delayed because the need has not been fulfilled. In our proposals, we are relabeling assumptions as dependencies to ensure they get the attention they deserve.

The Project vs. MS Project. Just because MS Project says a task is done does not make it so. Is the work truly complete?  Has the user of the task’s deliverables accepted them, without being under pressure to “meet the date?”  The reality is that there is no free lunch; you always get caught by taking shortcuts, and it usually is when testing commences that the pain begins.  Shortcuts in requirements definition become excessive defects. Shortcuts in test coverage translate into long nights during implementation, when the bugs surface.

Any time the project tasks are restructured in mid-project for the purpose of shaving time or effort, be very careful what the impact is on the testing effort.  You may be adding to the testing burden or extending the rework costs by lowering the likely quality of the delivered application. Nobody wins in that case.

Got feedback?
We’d love to hear from you. Send us a note if you would like further information on a specific topic or if you have any questions.

Past Issues
The Mythical 4-Month Project

AGILE, INCREMENTAL, WATERFALL: Is there a quality difference?

Automating Test Execution: What You Need to Know.

Check out our videos
Webinar: Why are IT projects so hard (and what can I do about it)?

TMX Product Family Video

TMX 3-Minute Overview