A High-Quality Plan


What does it take to produce a high-quality product? A clear understanding of the customers' needs? Of course! Solid engineering work? Yes! Intensive testing? Naturally! Consistent practices? You bet! A committed, cohesive team? Without a doubt! Anything else?


What about good plans? Do they affect the quality of the products you produce? Absolutely! Although it may not be obvious at first glance, the quality of your plans is one of the primary drivers of the quality of the products your project produces. Let's take a look at some examples of plans contributing to the quality of projects' products-or the lack thereof.

Joe H. didn't waste his time planning. The project was pretty simple and it was unlikely that there would be any surprises.   Besides, with the deadline only 6 weeks away, he couldn't afford to waste days working out a plan. Instead, he pulled his team together, pointed out the goal, and set them to work. For the first three weeks, things were going great as his team churned out the code.

In the fourth week, a parade of team members headed to his office. They were stuck and couldn’t move ahead until Steve got the flimbatzel working properly. He had started it in week three, but it was far from done and would probably take another week of work to be complete. If his team was unproductive for more than a week, he had no chance of delivering the product on time, so Joe knew he had to take drastic action.

Joe called a meeting and in a couple of hours, he and his team reworked the system design so that many of the remaining pieces were no longer dependent on Steve's work. They also hacked the flimbatzel into two distinct parts so that Mike could work on it in parallel with Steve. Problem solved! The team got back to work! Naturally, with a design so hastily modified, there were some problems, but the team was committed to working through them. And work, they did! Everyone sighed in relief when the "last" line of code was written. They thought they would only have to test and release the product, but the testing revealed many serious defects. As problem after problem was discovered and fixed, the design became more and more convoluted. Code had to be reworked and more problems were created.

The deadline came and went, and they still couldn't get it to work right. In fact, after three weeks of testing, it still didn't work at all . When they released the system a full month late, it was hard to use, the user interface didn't make sense, and it crashed regularly. It was uniformly declared to be a disgrace. Without a plan, the flimbatzel wasn't identified as a choke point until it was too late.   In the mad scramble to work around the problem, the initially good engineering work was severely compromised. Poor planning resulted in poor quality.

Susan took a different approach. Faced with a similarly tight deadline, she recognized that her team had to make the best possible use of each and every person-hour they had available to them. She pulled her team together for a day to carefully estimate the work that needed to be done, and identify the dependencies among the parts. That evening, when she tried to weave the information together into a cohesive plan, she found that they would miss their 6-week deadline by about 2 weeks. What was she to do?

With the solid estimates she had from her team, she realized that just telling them to work faster was not an option. The largest item on here schedule was the testing. Based on her experience on prior projects, the plan was to test for half of the 8-week schedule-a full four weeks. If she could

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.