Classification of Software Projects based on Goal and Solution Clarity, Slides of Software Engineering

A two-dimensional grid for classifying software projects based on the clarity of their goal and solution. Four quadrants, each with distinct project characteristics and risk levels. Projects in quadrant 1 have clearly specified goals and solutions, while quadrant 2 projects have clearly specified goals but not completely known solutions. Quadrant 3 projects have neither clearly specified goals nor solutions, and quadrant 4 projects have solutions looking for goals. Examples and references for further reading.

Typology: Slides

2011/2012

Uploaded on 08/09/2012

parthivi
parthivi 🇮🇳

4.1

(8)

85 documents

1 / 3

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Managing Software Projects effectively
Software development, much like manufacturing is
drastically changing. In order to stay on top, project
managers need to accept and adapt to change. This
chapter provides focus areas for PMs concerned about:
risks, cost, complexity, business climate and team
competency.
When I think of the project-management landscape, I
think of it at a higher level of abstraction than the seven
variables discussed earlier. In keeping with my penchant
for the simple and intuitive, I visualize it as a simple two
dimensional grid like the one shown in Figure below.
The first dimension relates to the goal of the project. It has two values. The goal is either
clearly specified (therefore completely known) or not clearly specified (therefore not completely
known).
The second dimension relates to the solution or how you expect to reach the goal. That also
has two values. The solution is either clearly specified (therefore completely known) or not
clearly specified (therefore not completely known). If we intersect these two dimensions as
shown in the figure, we have defined a four-category classification of projects. It is important to
note that the boundary between clear and not-clear is a conceptual boundary. It is not
quantitatively defined, but is only conceptually defined. This classification is simple, but it is
inclusive of every project that ever was or ever will be. That is, every project must fall into one
and only one of these four quadrants:
Goal
Not Clear
Quadrant 4
R & D projects,
Agile, XP
Quadrant 3
R & D projects
Agile, XP
Clear
Quadrant 1
Linear
Incremental
Quadrant 2
Iterative
Adaptive
Clear Not Clear
Solution
docsity.com
pf3

Partial preview of the text

Download Classification of Software Projects based on Goal and Solution Clarity and more Slides Software Engineering in PDF only on Docsity!

Managing Software Projects effectively

Software development, much like manufacturing is drastically changing. In order to stay on top, project managers need to accept and adapt to change. This chapter provides focus areas for PMs concerned about: risks, cost, complexity, business climate and team competency.

When I think of the project-management landscape, I think of it at a higher level of abstraction than the seven variables discussed earlier. In keeping with my penchant for the simple and intuitive, I visualize it as a simple two dimensional grid like the one shown in Figure below.

The first dimension relates to the goal of the project. It has two values. The goal is either clearly specified (therefore completely known) or not clearly specified (therefore not completely known).

The second dimension relates to the solution or how you expect to reach the goal. That also has two values. The solution is either clearly specified (therefore completely known) or not clearly specified (therefore not completely known). If we intersect these two dimensions as shown in the figure, we have defined a four-category classification of projects. It is important to note that the boundary between clear and not-clear is a conceptual boundary. It is not quantitatively defined, but is only conceptually defined. This classification is simple, but it is inclusive of every project that ever was or ever will be. That is, every project must fall into one and only one of these four quadrants:

Goal

Not Clear

Quadrant 4 R & D projects, Agile, XP

Quadrant 3 R & D projects Agile, XP

Clear

Quadrant 1 Linear Incremental

Quadrant 2 Iterative Adaptive

Clear Not Clear

Solution

Quadrant 1: Goal and Solution Are Clearly Specified

The projects in this quadrant are those for which the goal and the solution are clearly defined. These will be simple projects that have been repeated a number of times in the past. There will be well-developed templates for all, or significant parts, of these projects. Because these projects are very familiar to the organization, the requirements will be known as well. Having complete requirements means that the solution will be clearly defined and the complete work breakdown structure (WBS) can be generated.

Quadrant 2: Goal Is Clearly Specified but Solution Is Not

Next in order of increasing uncertainty are projects in the quadrant 2. The range of projects will be from those where the goal is clearly defined and most of the solution is known (perhaps with the exception of choosing how to render some features) to those where very little of the solution is known, and it must be discovered as part of the model chosen for managing the project. Because some of the solution is unknown, the risk associated with these projects is much higher than the risk associated with projects in the quadrant 1. The successful completion of such projects will be critical to the organization. The business value must therefore be high enough to warrant taking on these higher-risk projects.

Quadrant 3: Goal and Solution Are Not Clearly Specified

Next in the order of increasing uncertainty are projects in the quadrant 3. For these projects, neither the goal nor the solution is clearly known; they must be concurrently learned and discovered as part of executing the project. These are usually R&D projects for which the risk of failure is very high. For these projects, the best-fit model must embrace a great deal of uncertainty and include investigative cycles that are designed to converge on a goal and a solution to support that goal. Even when that may be done successfully, there remains the question of business value. Does the solution to the now clearly defined goal offer sufficient business value to be useful to the organization? A good example of this situation is the project that eventually led 3M to the Post-it Note product. The glue produced from the original project did not deliver a product that had business value as originally defined, and sat on the shelf for about seven years until someone found an application with business value.

Quadrant 4: Goal Is Not Clearly Specified but the Solution Is

Projects in this quadrant may seem like nonsense projects at first glance. Are there meaningful projects that consist of a solution looking for a problem? In fact there are. Wal-Mart's initial investigation of the newly introduced RFID technology provides a good example. The question Wal-Mart was asked in this project was: "Can you find an application (the project goal) of RFID technology (the solution) that has business value?" This sounds like a quadrant# 4 project, but with the sequence reversed. That is why I call these projects Emertxe projects. If you haven't already observed, Emertxe is Extreme spelled backwards. Both the quadrants 3 and 4 are heavily populated by R&D projects. The quadrant 4 projects are projects looking for a solution to a