A High-Quality Plan

[article]
Summary:

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 trim that time without compromising the product, she could make the deadline. The next day, she and her quality assurance engineer worked out the solution. By having her team invest time in reviewing each other's designs and code as they are produced, they can remove more than half of the defects before testing begins. The reviews would cost the project three days of their schedule, but the improved quality would mean that testing time could be cut in half! This put the deadline within reach.

She and her team enthusiastically embarked on this path, and through careful attention to following their plan, they were able deliver on their deadline date by working only a little overtime. And the users of the system found it to be stable and a pleasure to use. Careful planning revealed problems early, when Susan had the luxury of time to fix them, and she was rewarded with a high-quality product.

Finally, we visit the office of Francine. She is busily at work circulating her resume because her project looks a lot like Joe's in spite of the fact that she planned it so carefully! What happened, Francine?

"I tried to do the right thing! I knew a plan was important, but I ended up with quality and schedule problems anyway! I invested two days of my 6-week schedule to work out a plan that showed that we would finish exactly on time. It was a beautiful plan, but my team let me down.  They didn't finish anything on time! Why do these things happen to me?" Francine worked it all out myself and assumed that her team didn’t know anything about management, so she didn't waste their time on it. She started from the deadline date and worked backwards. They had to start testing on that date, which meant this has to be done then, which also meant that activity had to start at that point. Everything in the plan is driven by the deadline, she believed.

What told her that those tasks could be completed in the time that she allocated?  She replied, "They have to! That's all the time that is available! If the folks have to work a bit harder than they like, then they just have to do it. I don't have the luxury of asking them how much time they'd like. I have to tell them!"

Francine built a plan that wasn't based on reality in any way (except for the deadline), and she reaped a result that was the same-it was totally unreal. A poor plan resulted in poor quality.

These three stories all teach the same lesson. Along with all of the other items that are necessary to achieve high quality, we also need a high-quality plan. What does a high-quality plan look like? It has all of the detail that is needed to determine the project's health (both initially, and as the work progresses). And it is based on realistic estimates of the work to be done and the time that will be required to complete it.

Yes, you can produce high-quality work. if you plan to!

 

About the author

StickyMinds is a TechWell community.

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