I think in terms of five dimensions we have to manage on a software project (Figure 1, adapted from my book\u00a0Creating a Software Engineering Culture<\/em>). First, of course, there are the features (aka scope), which itemize the product\u2019s functional capabilities. But it\u2019s important to distinguish quality from scope. I can write software very fast if it doesn\u2019t have to work correctly. The other three dimensions are the time we have available before delivery (schedule), the budget for the project (cost), and the staff available to work on the project. We shouldn\u2019t lump staff and budget together and just call the combination \u201cresources\u201d as is often done. Most of the project cost is indeed staff salaries. I\u2019ve seen situations, though, where a team had adequate funding but could not hire additional staff. In this case, perhaps the project manager can use the available money in different ways, such as outsourcing some work, buying automated test tools, or bringing in consultants.<\/p>\n Figure 1. The five dimensions of a software project.<\/p><\/div>\n For each project, we need to decide which dimensions are most critical and how to balance the others so we can achieve the key project objectives. The tradeoffs among these five dimensions are not simple or linear. For example, if you add staff, the schedule might be shortened (although not necessarily) and the cost could well increase. A common, but unfortunate, tradeoff is to shorten the schedule or add features while sacrificing quality. Anyone who has been the victim of buggy software questions these kinds of tradeoff decisions, but they do take place.<\/span><\/p>\n Each of these five dimensions can take one of three roles on any given project: a\u00a0constraint<\/em>, a\u00a0driver<\/em>, or a\u00a0degree of freedom<\/em>. Constraints define restrictions within which the project manager must operate. The project manager has no flexibility around a constraint dimension. If a team of immutably fixed size is assigned to a project, staff becomes a constraint. Cost is a constraint on a project being done under a fixed-price contract (at least from the client\u2019s perspective). Quality will be a constraint for a project that develops software for a medical device. Y2K projects were schedule-constrained.<\/p>\n A driver is a key objective or success criterion for the project. For a product with a desired marketing window of opportunity, schedule is a driver. Commercial desktop applications often have features as a driver. The project manager has a little flexibility around the drivers. A specified feature set might be the primary driver of the project, but features are a constraint if the feature set is not negotiable.<\/p>\n Any project dimension that is neither a driver nor a constraint is a degree of freedom. This is a factor that the project manager can adjust within certain limits. The manager\u2019s challenge, then, is to adjust the degrees of freedom to make the project succeed in meeting its success drivers within the limits imposed by the constraints. Suppose that on some corporate information system project the drivers are features and quality and staff is a constraint, so the degrees of freedom become schedule and cost. The implication for this profile is that the features demanded by the customers will all be included, but the delivery time for the product may be later than desirable and the project might cost more than planned.<\/p>\n Here\u2019s a little safety tip: all five dimensions can\u2019t be constraints and they can\u2019t all be drivers! Something has to give to be able to meet the key objectives. If the project is over-constrained, with no degrees of freedom, then you will almost certainly fail. The first added requirement, the first team member who gets the flu, the first risk that materializes will trash the schedule because the project manager has no flexibility to respond to these changes. A student in a project management class I taught once said, \u201cOur project has a fixed budget, we can\u2019t add any people, all of the features are critical, there can\u2019t be any defects, and we have to finish on time.\u201d This project isn\u2019t likely to succeed.<\/p>\n Negotiating Priorities<\/strong><\/p>\n An important aspect of this model is not which of the five dimensions turn out to be drivers or constraints on any given project, but that the relative priorities of the dimensions be negotiated in advance by the project team, the customers, and management. This negotiation process helps to define the rules and bounds of the project. For instance, schedule is often presented as a constraint when in fact it is a driver. The way to tell the difference is to ask, \u201cOkay, you want this delivered on June 30. What happens if it\u2019s not delivered until, say, July 14?\u201d If the answer is to forget the whole thing because it won\u2019t be useful to us or we\u2019ll be socked with penalties from the government or our client then, yes, schedule truly is a constraint. But if the answer is, \u201cWell, we\u2019d sure like it by June 30, but I guess we\u2019ll live if it\u2019s not available for two more weeks,\u201d then schedule is a driver. If there is some flexibility around a dimension, then it is not a constraint. A little bit of flexibility makes it a driver, and a lot of flexibility makes it a degree of freedom.<\/p>\n Let me illustrate how this five-dimension idea works in practice. Once I heard a discussion between a senior manager and a project manager about a new project. The senior manager asked, \u201cHow long will this take?\u201d The project manager replied, \u201cTwo years.\u201d \u201cThat\u2019s too long,\u201d said the senior manager. \u201cI need it in six months.\u201d So what did the project manager say? He said, \u201cOkay.\u201d Now what changed in those few seconds? Nothing at all! The project didn\u2019t shrink by a factor of four, the team didn\u2019t get four times bigger, and the team didn\u2019t magically become four times as productive. The project manager simply said what the senior manager wanted to hear. (The project took more than two years to complete, incidentally.)<\/p>\n What are some other ways the project manager could have responded instead of simply saying okay? Let\u2019s look at the five dimensions. Maybe he could have asked what portion of the product absolutely must be available within six months. That is, can we cut back on the features intended for the initial release? The project manager could question the schedule, asking, \u201cWhat\u2019s so vital about six months?\u201d Perhaps this system is replacing a legacy system that runs on an antique computer and they\u2019re removing that computer from the building in six months. Okay, that\u2019s a good reason. Or maybe there\u2019s nothing magic about six months, but we understand there\u2019s a strong desire to get the system operational quickly. In that case the target date of six months is a driver, not a constraint.<\/p>\n You can continue this analysis down the list of the five attributes. Can I get more people or more money? Does the software have to work? Some organizations deliver\u00a0something<\/em>\u00a0on the scheduled release date, but it is severely crippled in functionality and full of bugs. Nonetheless, they declare victory and claim they shipped on schedule, even if what they shipped wasn\u2019t useful. It\u2019s just a little game they play.<\/p>\n Contemplating these five dimensions is a better way to understand your project priorities instead of just assuming that every aspect of the project is both critical and non-negotiable. In part two of this series, I\u2019ll describe two ways to represent the information about a project\u2019s constraints, drivers and degrees of freedom and show you some examples.<\/p>\n Also read The Five Dimensions of a Software Project, Part 2<\/a><\/p>\n Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars.\u00a0 Karl Wiegers is an independent consultant and not an employee of Jama. \u00a0He can be reached at\u00a0http:\/\/www.processimpact.com<\/a>.\u00a0 Enjoy these free\u00a0requirements management resources<\/a>.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Perhaps you\u2019ve seen a sign at a car repair shop that asked, \u201cWhat do you want: good, fast, or cheap? Pick two.\u201d While humorous, the sign is also wise: it acknowledges the reality of tradeoffs. You generally cannot optimize every desired outcome of a given situation. People often apply this so-called \u201ciron triangle\u201d or \u201ctriple […]<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[855],"tags":[51,104,38,106],"industry":[],"class_list":["post-3338","post","type-post","status-publish","format-standard","hentry","category-software-development","tag-business-requirements","tag-five-dimensions","tag-karl-wiegers","tag-priorities"],"acf":[],"yoast_head":"\n![\"\"](\"https:\/\/static.jamasoftware.com\/www\/imports\/2013\/07\/a54f1.png\")