user interface designing workflow software relationship management database development services ms access database business process software it projects management user interface development project developer access development database example it project manager

Optimization Management: Quality, Cost and Schedule

By Thomas Eklund

When you work on something, have you noticed that you have to find balances between quality of the outcome, how much effort you put into what you do, and how much time you spend on it?

It's a simple "triangle of priorities" that applies to many tasks.

What happens when you work on something and really want to do a good job, but somebody else whose work is also related to what you do, seems to care primarily about your being able to complete the tasks as soon as possible?

What's the best way to handle such situations?

During most projects I have to find balances between prioritizing quality, cost and schedule, the latter being the length of individual milestones and the entire project. This applies to both project management and to most application development tasks.

What makes this topic significant is that among these three areas, different people seem to have different priorities and preferences, but often enough these topics are addressed only after problems or differences emerge.

So, clarifying upfront how quality, cost and schedule should be prioritized is a good idea. When the project participants opinions on the relevant topics are addressed upfront, fewer conflicting priorities will have to be handled unexpectedly, in stressful situations.

My preference is usually to optimize for quality - that is, to do as good of a job as I can. Within reason, of course. Up to the point, where I can see the additional efforts clearly adding value to the outcome.

However, optimizing for quality means, that you need to find the budget for doing so, and you may have to adjust the schedule on as needed bases.

You cannot get the best possible quality for the lowest possible price.

Quality takes time. You may have to explore more and you have to pay attention to more aspects and details.

More time means more money, and quality tends to costs more in other ways as well. For example, you have to implement more quality control measures.

Project participants should also clarify upfront, that certain types of tasks take time, but they are likely to increase the quality of the outcome.

For example, research, analysis and exploration of alternatives take time, but they are necessary. Further, the more complex is the project, the more unexpected problems need to be addressed. Just ignoring them doesn't make them go away.

In my line of work, the more complex is the business process and the more components it contains, the more time I usually have to spend on business analysis and often also on exploring different solutions. Further, despite of business analysis, building complex business processes into computer applications tends to mean that we will have to handle unexpected issues during the development and afterwards as well.

These extra efforts, in turn, help to increase application users effectiveness, efficiency and satisfaction.

This matters.

Some people may say: "Just give them what you have. Leave out the functionality parts that you haven't finished yet. It doesn't matter, people will adjust to lower quality and to not having all the needed features."

Just get it out of the door. Get it done.

I have problems with that attitude. I believe that unless the perceived and expected benefits very clearly outweigh the disadvantages (that should also be specified), it is plain wrong to ignore the importance of quality.

Of course, we have to make judgments and decisions based on the information available to us. In life we don't have control groups, like scientific experiments have. We are not as objective either, as scientists attempt to be. In most instances we cannot point out that "See, there, under the same circumstances, another group got much better results, because they paid more attention to the details that helped them to improve the quality of the outcome. For them, quality was a higher priority than schedule and cost, and they had it right!"

So, we do have to find balances between prioritizing quality, cost and schedule, but in circumstances, where we can make a good case for the additional efforts improving the outcome by more than is the cost of these additional efforts, they are worthwhile. Thus, if we can find the needed resources, we should use them.

While writing this article, I remembered that I once read the following: The bitterness of poor quality lingers long after the sweetness of low price is forgotten.


That's my take on this.

I just did an internet search on the above saying, and it turned out quite a few matches. I'm glad to see, that many other people think about this, too.