Everyone has priorities to contend with, as those who did their taxes on the last possible day can attest. Federal agencies have priorities with respect to which systems have the top claim on funding. Agency managers also have priorities, which involve organizational and personal issues, as well as priorities for support and development of their major systems.
Understanding and communicating priorities is an essential element of reducing risk in a software development project. A late delivery can be more damaging than dropping some minor but hard-to-develop features, for example. But on another proj-ect, the features might be worth waiting for.
There's an old saying: "You can have it good, fast or cheap — pick any two." The idea, of course, is that it is very difficult to build products such as software rapidly and inexpensively that are also of high quality.
Jim Highsmith, author of "Adaptive Software Development," has an interesting technique for exploring the tradeoffs among schedule, cost, quality and features. Highsmith suggests that a customer ask the development team to excel in one of those categories. The team can then achieve — which means meeting standards — in a second category, and the customer should then agree to accept some compromises in the remaining two.
Put another way, of the four categories, the customer can set one as Priority 1, another as Priority 2 and the other two as Priority 3, to be managed to an acceptable conclusion.
How does this play out in practice? Consider an agency manager who's made a commitment to have a management information system "out the door" by the end of the year. The system has to have a number of features. There is plenty of money to build the system, and everybody recognizes that the system may have a few kinks as it "shakes down."
In this situation, the manager might say that the priorities fall out like this:
Priority 1 — Schedule. Priority 2 — Features. Priority 3 — Cost and quality. Understanding these tradeoffs, the development team will make darned sure the system comes up on schedule with the required features.
Contrast this with development of a medical application for, say, the military hospital system, where the tradeoffs might look like this:
Priority 1 — Quality. Priority 2 — Features. Priority 3 — Cost and schedule. In this case, the developers must take extraordinary care not to introduce bugs into the software, and it's acceptable if it takes more time and money to achieve that goal.
All too often, developers have hundreds of requirements to meet and fail to understand the fundamental priorities of the project. On your next project, think about discussing a project profile matrix with the team — to be sure the developers really understand what's important.
Bragg is an independent consultant and systems architect with extensive experience in the federal market. He welcomes your questions and topic suggestions at email@example.com.