By Steve Kelman
In my recent conversation with Mark Schwartz, CIO of Citizenship and Immigration Services, about transitioning the federal government to agile development, we also spoke about some issues for agile contracting. It was an interesting conversation, with what I would call some good news and two challenges.
Mark is an advocate of using a multiple-award task order contact framework for contracting for agile development modules, with competition among a small group of contract holders for each module. He agrees with the view that technical developments involving the underlying architecture for these projects makes it more possible than before to do individual agile development modules as “bolt ons” to the architecture, which undermines the traditional approach that says that you need one contractor for these projects because of the difficulty of integration. He believes that the government should itself often be responsible for developing the architecture and for any integration issues, though when I said this might better be left in the hands of an architecture/integration contractor most of the time, he wasn’t dogmatic on the point.
This approach reflects in my view a real possibility for getting the government a better deal by keeping a small group of vendors in real-time competition for elements of an agile development. This is also an approach that many contracting professionals in government are likely instinctively to identify with, so implementing it is mainly an educational challenge for contracting and IT folks, not a cultural challenge.
Another issue he raised is more complex. Because requirements in agile are meant to change, and to be changed easily, Mark didn’t like the idea of putting any kinds of requirements in the task orders for agile projects, or of making the change order process complex in any way. He also wanted the task orders to be priced on a time and materials basis. Both, particularly the first, go against common views among contracting professionals – and to some extent of the oversight community – about having performance metrics and making sure a contract establishes what results a contractor is responsible to produce, so as to improve the likelihood that the contractor performs well.
Mark’s solution to this ties in with the ongoing competition for small task orders he envisions in the multiple-award model. The government should extensively use past performance in making future task order awards as a substitute for upfront performance or other requirements.
The problem then becomes how the government knows whether the vendor’s performance has been good or not absent performance requirements in the original task order. Mark argues that the government team will be observing the vendors as they are working on these short “sprints” and can see whether they are wasting time, or compare vendors in terms of production of usable code.
Well, maybe. But what if the vendors are off-site with no government people present? Or what if the sprints differ in how tough they are, so comparisons become more difficult? I also wonder if, when what is being developed in each “sprint” is fairly small, it shouldn’t be easier to express performance requirements and whether there should need to be so many changes – indeed, isn’t one of the aims with agile to reduce changes by reducing the scope of a project?
I’m not a techie and am raising questions rather than giving answers. I think what we really need is a dialogue among pro-agile IT people and contracting professionals about some of the ways we might deal with these issues. Good contracting people, as they should, want performance, and that’s why they tend to want requirements – at least performance requirements. Pro-agile IT folks want the same thing. Is there a way to give performance requirements for an agile module?
It’s time for a collegial dialogue on these issues. I would love to hear from blog readers about suggested approaches we could/should be trying – and I bet those working on these issues from both the IT and contracting sides would love to hear thoughts as well.
Posted on Sep 20, 2012 at 7:03 PM13 comments
Every year for the last decade – this is the tenth anniversary – the Partnership for Public Service has given annual awards for outstanding, results-oriented achievements by career civil servants. The award is officially called the “Service to America Medal,” unofficially known as the “Sammies.”
The nickname isn't just a play on the acronym of the formal name or a reference to the Oscars. It also invokes the name of Samuel J. Heyman, the deceased original founder and benefactor of the Partnership for Public Service.
Heyman, in whose honor the awards are given, had an amazing story to tell: a billionaire real estate developer and businessman, he always said his best job ever was as a junior attorney right out of law school for the Department of Justice. He left that job because his father had died, and Heyman took over the family business.
Later in his own too-short life, Heyman decided to give back by founding the Partnership, a non-profit devoted to attracting a new generation of young people to government service and to improving the quality of government management so as to create organizations for which these young people will want to work. (Full disclosure: I was recently selected as a participant in SAGE, a Partnership advisory board of former government officials who work to share ideas and give advice/mentorship on government management.)
The Partnership held its award dinner in Washington a few nights ago. These attract a star-studded cast and help make the Sammies at least tied for the most prestigious award given federal officials.
For the first time in several years, a career civil servant contracting professional -- Elliott Branch, currently the Deputy Assistant Secretary for Acquisition and Procurement of the Navy -- won a Sammie. I was thrilled to learn this, because Elliott is one of a handful of long-time, still-in-government outstanding career contracting professionals out there.
The thrust of what he received the award for was also interesting and sends an important signal: saving the government money through smart contracting. In this budget environment, this traditional element of the contracting culture needs to come (back?) into its own. The award notes the savings he achieved on the Littoral combat ship contract. In the original strategy, the ships were too expensive. Branch oversaw an effort (as I understand it from the supporting material provided) to save money by separating ship construction from support electronics development, allowing a focused head-to-head competition on the ship itself that brought the price down considerably.
Branch has also pushed multiyear contracting, a win-win for the government and the contractor where the government commits (subject to annual appropriations and payment of termination liabilities if future construction is not funded) to a purchase program over several years, allowing the contractor to lower their prices because of the greater certainty about the level of demand that they will get.
In general, Branch is an advocate of having contracting people use negotiation skills, skills that both have a strong potential to help the government (and which contractor representatives are clearly trained in) but that also make the contracting professional’s job more personally and professionally satisfying.
In a video interview in connection with his award, Branch listed several skills a good contracting professional should have, including intellectual curiosity, the ability to think critically, being results-oriented and imagination. Without putting too fine a point on it, he did not include Federal Acquisition Regulation expertise in his list. We need to continue to spread the message that contracting folks of course must know something about the regs, but if that is all they know -- or all they see their jobs as involving -– they are not only never going to win an award but (I guess more importantly) never going to make a difference in creating a better-performing government.
Posted on Sep 18, 2012 at 7:03 PM1 comments
At a recent Kennedy School executive education program, I was lucky to have a chance to meet and talk with Mark Schwartz, CIO at the Homeland Security Department's Bureau of Citizenship and Immigration Services.
Mark has a great background, coming to government for the first time after a fascinating career in private-sector IT. He studied computer science at Yale, he went to film school, dropped out, and worked first at a film production company, then in software consulting, then lived abroad for five years. After all this, he went back to school to get an MBA at Wharton, and then became CIO of a company called Intrax Cultural Exchange, which sets up different kinds of exchange programs, including
au pair jobs for foreigners working in US families.
“Then,” he says, “I got this idea that it would be interesting to work for government. My organization brought 60,000 people a year to come to the US. Citizenship and Immigration Services receives seven million applications a year to come. DHS seemed to have a lot of problems – I thought maybe I could help.”
And here's something that many will regard as amazing: He applied for the CIO job on USAJobs – and eventually got it (although six months passed before the agency acknowledged his application).
Since coming to CIS, Mark’s major challenge has been to take charge of the agency’s major IT transformation effort to digitize agency benefit application processes (including for visas). The project had been going on for several years, burned through hundreds of millions of dollars, and not yet produced any capabilities – in other words, a prototypical IT program in trouble.
With his private-sector experience, Mark has chosen to see if he can turn this program around through agile software development methods – under which software is developed in very small increments by small teams, rather than having complex and detailed requirements that take years to develop, and often never get developed, with the aim of getting incremental capabilities out much faster.
To Schwartz, the potential advantages of agile were fairly clear. When the software being developed is complicated, requirements changes (inevitable in large numbers in any major project) themselves become complicated because they involve rewriting more already-developed software. When problems are discovered during an old-fashioned “gate review” after a lot of work has been done, they similarly involve huge amounts of rework of already-developed code. The long lead time before any capability actually exists delays and complicates user feedback that is so essential for a new system.
I asked Schwartz what the problems he perceived in introducing agile into government and his approaches for dealing with them. One issue, he said, was that project overseers like to see well-developed requirements, which are not available early on for an agile project. His approach has been to present high-level system capabilities rather than more detailed requirements (which, it might be added, often significantly change anyway).
A similar problem involves the way the test and evaluation/independent verification and validation community do product testing at gateway reviews, in ways that are often time-consuming and contrary to the agile spirit of getting capabilities out fast. His approach has been to involve the testers in small tests while the software is being developed, rather than waiting for a formal gate review.
What’s his most difficult challenge? Agile involves development by small teams that are empowered to make decisions and even tradeoffs to move things forward fast. In government, with many stakeholders with different interests, and often less ability to have a common metric (such as return on investment) to judge tradeoffs, it is difficult to give as much authority to a small team as an agile effort in the private sector would typically have. He doesn’t feel he has solved this problem, but is toying with the idea of getting teams empowered to make tentative decisions, that are then – like elements of a new agile release in general – submitted to reaction from users, realizing that the smaller increments mean less rework costs if something doesn't go over well.
In May the new approach bore modest fruit as CIS debuted an
online visa account form. Pretty modest when you think about it for a second – my reaction was “didn’t they have this already?” – but at least that the effort seems to be turning around. Better late than never, and hopefully there will be lessons learned here for expanding the role of agile development in the government.
Posted on Sep 12, 2012 at 7:03 PM12 comments