Communicate priorities

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 protected]

Featured

  • People
    Federal CIO Suzette Kent

    Federal CIO Kent to exit in July

    During her tenure, Suzette Kent pushed on policies including Trusted Internet Connection, identity management and the creation of the Chief Data Officers Council

  • Defense
    Essye Miller, Director at Defense Information Management, speaks during the Breaking the Gender Barrier panel at the Air Space, Cyber Conference in National Harbor, Md., Sept. 19, 2017. (U.S. Air Force photo/Staff Sgt. Chad Trujillo)

    Essye Miller: The exit interview

    Essye Miller, DOD's outgoing principal deputy CIO, talks about COVID, the state of the tech workforce and the hard conversations DOD has to have to prepare personnel for the future.

Stay Connected

FCW INSIDER

Sign up for our newsletter.

I agree to this site's Privacy Policy.