Defining and Managing Project Focus

Member Submitted

Most project managers want to reduce risk during a project. One way to reduce overall risk is to define and focus the project goals up front, and continually verify those goals and progress toward those goals during the project.

Most project managers want to reduce risk during a project. One way to reduce overall risk is to define and focus the project goals up front, and continually verify those goals and progress toward those goals during the project.

Bob Grady [1], claims there are three common goals for software product development: making a specific time to market, generating all the features, and providing a product of very low defects. In my experience, each project has one and only one of these goals as its top priority, and then trades off the other two goals within that context. This prioritization will determine the tradeoffs the project manager makes during the project.

The traditional definition of risk as "a potential problem that should it occur, will endanger or eliminate project success" [2] is different than the issue of changing project focus during the project. In the real world, project goals get set, and after some time, there is impetus to change them. This article addresses the issues of choosing a project focus, and recognizing when the focus needs to change.

Product Quality Model
To define and assess project completion risks, a project manager should first define the true measure of product quality. If we agree with Jerry Weinberg [4] that product quality is value to the customer, then we should be able to choose product goals that provide value to the customer. And, if we agree with Grady [1] that there are three common features of quality, then we can choose one of the three priorities below as the primary measure of product quality:

  • Minimize time to market, by decreasing the calendar schedule
  • Maximize customer satisfaction, by giving the customers the features they want
  • Minimize number of known and shipped defects

The key to defining product quality is to choose which priority is most valuable to your customers. For any given product, one of these priorities is the foremost priority; the other two are traded off within that context.

Some people are not convinced that they only have one top priority. Here is a check to verify that choice: If it is three weeks before the scheduled ship date, and the defect count is higher than the developers prefer, and the last feature is not quite implemented, what does management choose to do? If management chooses to ship anyway, then time to market is the top priority. If management chooses to ship as soon as that feature is installed, then customer satisfaction is the top priority. If management chooses to hold shipment in order to fix the defects, then low defects is the primary definition of quality. As much as your customers force you into a particular quality definition, where the product is in its lifetime also has an effect on quality definition.

Maybe you're still not convinced you only have one top. Consider this example: you have a ranking of 0-100, where 0 is low priority and 100 is high priority. You rank the ship date at 100, defects at 97, and features at 93. At first glance, the rankings are so close as to be inseparable. Then there are other questions to ask: o all defects need to be fixed, or are there critical defects to be fixed before the ship date? Do all the proposed features need to be added, or are there critical ones that need to be fixed before the ship date? Or, is the ship date contingent on those particular features? When prioritization is unclear, it's time to ask more questions–when the overall project priorities shift, the product itself shifts, and product shipment is at


About the author

Johanna Rothman's picture Johanna Rothman

Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:

  • Manage Your Job Search
  • Hiring Geeks That Fit
  • Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
  • The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
  • Behind Closed Doors: Secrets of Great Management
  • Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People

Johanna is working on a book about agile program management. She writes columns for and projectmanagementcom and blogs on her website,, as well on

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!